Crypto Twitter, what's a good way to generate nonces if random is disallowed (chance of collision) and you don't want to leak information about order (which sequential would)?
Conversation
Replying to
I'd say if there's a chance of collision you should make it larger if possible.
1
1
Replying to
It's chacha20 so 64 or 96 bits. That's only 48 bit safety which doesn't cut it (thus the mandate in standard not to use random w/o collision check).
1
XSalsa20 / XChaCha20 have a 192-bit nonce and a separate dedicated 64-bit counter so you can simply generate the nonce with a CSPRNG.
libsodium uses X25519 + XSalsa20 + Poly1305 for their high-level authenticated encryption. It'd presumably use XChaCha20 now that it's defined.
1
2
If you have to use ChaCha20, you can use your key to derive a subkey for each message with a KDF. It's essentially what XChaCha20 does for you though. Might as well use it.
2
1
Hmm. The key is the product of ECDH but I guess I could pass along an additional large random nonce that's hashed with that key to produce a subkey.
1
Of course it's possible to just use new ECDH ephemeral secret for each message, but since all messages are produced together, there's no security benefit to doing so, and high computational cost for large number of small messages.
1
You might as well just use a cryptographic hash to derive a unique key for each use from the key and a nonce. It's a common approach and is pretty much the best practice for using ChaCha20.
2
It's too bad datatracker.ietf.org/doc/html/draft isn't what was standardized in the first place. It seems silly to use such an overkill number of rounds (ChaCha12 still pretty much has a higher security margin than AES256) but they didn't want to pay small cost of supporting random nonces.