SCRYPTSALSA208SHA256_BYTES_MAX and Scrypt.Lazy#cryptoPwHashScryptSalsa208Sha256()

[jcihocki]

In the Lazy interface method for Scrypt cryptoPwHashScryptSalsa208Sha256 (see link) you hardcode your output hash buffer to have size SCRYPTSALSA208SHA256_BYTES_MAX, or 16. I noticed that if you pass in a longer buffer (32 bytes) using the native interface directly, libsodium doesn't throw an error, and you do get a seemingly deterministic 32 byte result that starts with the same 16 bytes as the result of the lazy method. So I'm curious if this is the right application of SCRYPTSALSA208SHA256_BYTES_MAX, and if so, what sort of trouble might I get in if I use this method with a buffer longer than SCRYPTSALSA208SHA256_BYTES_MAX ?

lazysodium-java/src/main/java/com/goterl/lazycode/lazysodium/LazySodiumJava.java

Line 79 in 6621320

byte[] hash = new byte[longToInt(Scrypt.SCRYPTSALSA208SHA256_BYTES_MAX)];

[jcihocki]

Relevant libsodium constant definition:

#define crypto_pwhash_scryptsalsa208sha256_BYTES_MAX \
    SODIUM_MIN(SODIUM_SIZE_MAX, 0x1fffffffe0ULL)
SODIUM_EXPORT
size_t crypto_pwhash_scryptsalsa208sha256_bytes_max(void);

So, seems like the Java constant doesn't match libsodium, and such a large number would not be a sane default for the lazy method.

[gurpreet-]

This is a valid point actually. I took the easy way out and just left it as the minimum bytes i.e made SCRYPTSALSA208SHA256_BYTES_MAX == SCRYPTSALSA208SHA256_PASSWD_MIN. In theory it could be anything up to Constants.SIZE_MAX.

I'm going to change it so that the developer has to supply a size. This makes it non-lazy 😢 but I think in this case it's warranted.

[gurpreet-]

Fixed in release 4.3.0.