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 ?

https://github.com/terl/lazysodium-java/blob/6621320a581d12eef5127a89f108bcd2159b9e0e/src/main/java/com/goterl/lazycode/lazysodium/LazySodiumJava.java#L79

[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.