XChaCha20-BLAKE2b design clarification

[samuel-lucas6]

Please could you clarify why you've opted for deriving a subnonce and why you've put the nonce in the message of the authentication tag calculation when it's used to derive the authentication key.

I have an implementation that doesn't derive a subnonce and includes the nonce in the authentication key calculation but not in the tag message.

[paragonie-security]

PHP only exposes XSalsa20 and XChaCha20 for unauthenticated stream ciphers. I couldn't get naked ChaCha20; only the AEAD mode.

https://github.com/paragonie/paseto/blob/22fb2ef43452b52e355cbb508685ac917acdfa0e/src/Protocol/Version4.php#L405-L409

Even though XChaCha uses 192-bit (24 byte) nonces, we wanted a consistent experience with V3 and V4, especially with key derivation salts.

• v3.local uses a 32-byte random value
• v4.local should also use a 32-byte random value

[samuel-lucas6]

I see. Thank you for replying; big fan of your work. So it's possible to extend the HKDF standard security definition to BLAKE2b, and the nonce is in the tag as an added precaution?

I wish this combo was in libsodium given the commitment situation. That would perhaps help establish a standard implementation as well. I'm tempted to open a discussion, but it would start clogging up the number of AEADs in the library, so I'm not sure Frank would be too keen.

[samuel-lucas6]

I have started writing an Internet Draft that discusses Encrypt-then-MAC for committing AEAD, including ChaCha20(IETF)-then-BLAKE2b if you're interested.