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.
High level libsodium secretbox (symmetric) and crypto_box (asymmetric) APIs are really well made and worth following as an approach even if you reimplement it. XChaCha20 vs XSalsa20 doesn't really matter. Worth caring about it with 8 rounds but 20 is extreme overkill regardless.
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
Show replies