9

Generally speaking, there are (at least) three reasons to put a KDF in between an DH shared secret and the bulk encryption. Improved re-usability. If you don't post-process the shared secret with a KDF there's no way to give the sender and the recipient different keys for each direction or to split up authentication and encryption keys. An additional bonus ...


7

Unfortunately, there is no specification for XChaCha20. But several implementations provide a HChaCha20 function, built the same way as HSalsa20. XChaCha20 can be built with HChaCha20 + ChaCha20, and the security proof is similar to the one for XSalsa20. The Libsodium documentation has a section on HChaCha20, which includes a code snippet to build ...


6

Maybe. But your scheme hasn't been vetted by the community for its impact. Better to use XSalsa20 or the related XChaCha20 as recommended by Bernstein himself: http://cr.yp.to/snuffle/xsalsa-20110204.pdf In my opinion it was a fairly major faux pas that DJB originally chose short 64-bit nonces for Salsa20 and ChaCha20, especially given all the nonce-misuse ...


6

As a comment points out, it’s most probably a mistake/error in the docs. If you look at “What is the PRG period of stream ciphers such as RC4 or Salsa20?”, you’ll find an answer which explicitly points out the limits of Salsa20 (quote) …Salsa20 used as a stream cipher, it uses a 64-bit block counter and 64-bytes blocks, limiting its capacity to $2^{73}$ ...


5

Can one extend the ChaCha and Salsa20 nonces by XORing the extra nonce bits with the key? One can, but one probably should not. Security against related-key attacks is not claimed for either (Salsa20 security pdf): The standard solutions to all the standard cryptographic problems—encryption, authentication, etc.—are protocols that do not allow related-...


4

In general you should avoid changing the cipher for no particular reason. It is unlikely that simply increasing the number of rounds will significantly change the security of the cipher. Although attacks are generally against a limited number of rounds, the following is stated for Salsa20 (source: Wikipedia): As of 2015, there are no published attacks on ...


2

(To clarify the answer in general about why small bounds and why not init/update/finalize streaming, for anyone who doesn't want to bother following the whole discussion about Go in particular on GitHub...) The cryptography does not impose a meaningful limit: XSalsa20 produces up to $2^{64}$ 64-byte blocks, or $2^{70}$ bytes, of output per key per nonce. ...


2

This can be a secure construction, if by MAC you mean universal hash family, like Poly1305. Call this hash family $H_r$ and the short pseudorandom function family $F_k$. Rough justification for why this is secure: The function $m \mapsto F_k(H_r(m))$ is a long-input, short-output PRF. A good PRF makes a good MAC. A good PRF has birthday-bounded collision ...


2

Poly1305 itself has the requirement that its keys can only ever be used to generate a tag for a single message. That means that when Poly1305-AES (or another Poly1305-based authenticated encryption algorithm) is used as intended, the Poly1305 authentication key will be different for each message even if a key is reused. However, the various Poly1305-based ...


1

crypto_box_easy() doesn't generate a random nonce. But as documented, using a random nonce is safe, and can be done using randombytes_buf(nonce, sizeof nonce);. It's still the application's responsibility to include that nonce in the payload. Alternatively, the more recent secretstream API automatically creates and attaches a nonce, and can encrypt a ...


1

Yes this is "OK". Please correct me if I'm wrong there. You are correct. It's effectively ratcheting the original key. However there may be a more elegant solution such as using static keys for auth and ephemeral keys for key agreement (i.e. use Ephemeral-Ephemeral Diffie-Hellman for each new message).


Only top voted, non community-wiki answers of a minimum length are eligible