Use ChaCha20Poly1305 instead of Salsa20Poly1305 for SecretConnection?

[tarcieri]

The "SecretConnection" STS protocol presently uses "crypto_secretbox" a.k.a. XSalsa20 + Poly1305 for symmetric encryption.

The underlying Salsa20 cipher is part of the "Snuffle" lineage of ARX-based stream ciphers designed by Dan Bernstein and is synonymous with "Snuffle 2005". Though this cipher is notable both for being the main stream cipher provided by NaCl, and for being (in reduced round form) the core cryptographic primitive of scrypt (hence the "s"), it has seen little adoption otherwise. This is, I believe, because it has been obsoleted by ChaCha20.

The only transport encryption protocol I can think of based on Salsa20 is Dan Bernstein's own CurveCP, which never approached anything resembling a production ready state and had both a broken decongestion algorithm and has a number of other issues. There are additionally a number of design and security issues in CurveCP, some of which have common themes with the current state of "SecureConnection" (largely owing to the limitations of "crypto_secretbox" as a primitive), but that is probably a topic for a different thread.

Aside from djb's own vaporware, most well-designed, modern, and production-ready transport encryption protocols, namely TLS 1.3, Noise, and the Noise-based WireGuard VPN protocol, have opted for ChaCha20, the newest member of the Snuffle family. ChaCha20 is a tweaked version of Salsa20 which improves both diffusion (every word is updated twice per per quarter-round instead of once as in Salsa20) and at the same time manages to use one fewer register. The IETF version of ChaCha20 included some further improvements to accelerate software implementations on modern CPU architectures.

From my perspective Salsa20 is effectively obsolete, and anyone building anything new should be using ChaCha20 as it's simultaneously faster and more secure in that it provides better diffusion. However to break it down in a slightly more even handed manner:

Salsa20

Pros:

• Older, and therefore better studied
• Received considerable analysis before its inclusion in the eSTREAM II portfolio
• "If it ain't broke, don't fix it"

Cons:

• Obsoleted by ChaCha20
• Limited library support
• Worse diffusion
• Generally slower, but also a lack of optimized implementations as ChaCha is both more amenable to them and has a wider ecosystem, so no one bothers microoptimizing Salsa20

ChaCha20

Pros:

• The cipher of choice for new transport encryption protocols: one of two mandatory-to-implement ciphers for TLS 1.3 (with "SHOULD" label), as well as the Noise protocol and vicariously the newly popular WireGuard VPN software
• Relatively common in cryptography libraries with optimized implementations available for many architectures
• Better diffusion and therefore better security
• Uses fewer registers and more amenable to performance-oriented implementations
• "The New Hotness": generally nobody uses Salsa20 anymore unless they're using NaCl crypto_box. All of the forward momentum, especially in the transport encryption space, is around ChaCha20
• Drop-in replacement for (X)Salsa20: "why not?"

Cons:

• Has generally received less analysis than Salsa20, although there have been numerous recent papers 1 2 3 and as one of TLS 1.3's mandatory-to-implement ciphers will be more likely to receive ongoing analysis
• As far as I know, there are no other cons.

P.S.: the "X" in XSalsa20 refers to using HSalsa20, a Salsa20-based PRF, to derive an encryption key from input key material and a 24-byte nonce, a technique which is both theoretically applicable to ChaCha20 and readily available in many libraries, most notably libsodium. Where it is not available as a first-class primitive, it can be trivially implemented in terms of ChaCha20 and HChaCha20.

[zmanian]

Basically put all the secret connection crypto improvements on me

[zmanian]

So I took a fresh look at this issue and started
@tarcieri is correct that implementing xchacha20 is nearly trivial if you have an hchacha20 implementation and several ones with compatible licenses exist.

Switching to 12byte nonces was fairly invasive and I don't really want to do that.

So my plan is to wrap, the x/crypto/chacha20poly1035 implementation in the standard library in go-crypto with xchacha20poly1025 as interface that supports 24 byte nonces.

[ValarDragon]

Closing in favor of #2039