Suggestion to optional nonce protection

[brycx]

$size = CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES; $random = random_bytes($size); $nonce = sodium_crypto_generichash($payload, $random, $size);

I think it would be good to concretize this a bit to make it clearer, by specifically stating the algorithm this example uses (BLAKE2b IIRC). Also, what if sodium_crypto_generichash changes at some point? If we specifically state the algorithm tied to hashing for the nonce, we can tie that to the version and change it in the far future if need be. The last part is not too important, I'm more into specifying it to make it clear what algorithm is considered secure. In case a user might try to use something else, if libsodium is not accessible to them.

[tuupola]

I am not sure if it is necessary to mandate which hashing algorithm to use. How nonce is generated is internal to the each implementation. Implementations can use different techniques to generate the nonce. Important thing is not to use same nonce for two or more different messages.

That said it is probably a good idea to suggest which hashing functions are considered secure. I am bit out of my league here. What would be good suggestions? Output should be arbitrary or 192 bits.

Would it be enough to suggest general families such as BLAKE2, BLAKE3, Keccak. Or should it be more specific such as BLAKE2b, BLAKE2s, SHA-3etc?

[brycx]

After looking around a bit I found https://github.com/paragonie/paseto/issues/103. According to this issue, the current way both Branca (I assume it was inspired by PASETO?) and PASETO attempt to protect against bad RNGs is not optimal.

Apart from the above, I think we should just stick with BLAKE2. It's older and therefore, probably more libraries support it, compared to BLAKE3. Generalising to BLAKE2 lets users choose between b/s according to their architecture. Functions that are used here should also be PRFs that can correctly take into account the use of the secret key. And I'm not familiar enough with the specifics thereof, or the SHA-3 standardisations, to make any attempts at recommendations here.

[tuupola]

For some reason I never got a notification of your reply. Thus the late answer.

I can't find my notes but it was either taken from Paseto or we both took it from the same article or white paper. I remember reading several of them a while ago. I will add the suggestion of using BLAKE2 to the spec. Good thing is the suggestion can be changed later without breaking BC.

[tuupola]

When I think more about it, spec should only state the nonce should be "be cryptographically secure random bytes" and not how the nonce should be generated. I will just remove the optional nonce protection part.