OpenSSH just introduced a new protocol, chacha20-poly1305@openssh.com, which combines the two algorithms from DJB: ChaCha20 and Poly1305-AES. It was inspired by a similar proposal for TLS, which seems to have actively been backed by Google in the recent months.

But most SSH installations are inherently different from TLS.

What does this protocol mean for SSH? Is it just "a high-performance cipher to replace RC4 since it is pretty close to broken now", to quote the developer, or is it also a great choice to use as the default protocol on, say, new x86 installations, in cases where the crypto use by ssh isn't visibly know to be a bottleneck? How would this protocol compare to the default crypto that's been in ssh for the past several releases, e.g. ECDSA 256 or RSA 2048?

  • 3
    You can't compare it to ECDSA or RSA. Those are asymmetric schemes. It can replace RC4 or AES encryption. Asymmetric schemes are used for the handshake, symmetric for the actual data. – CodesInChaos Dec 11 '13 at 8:45
  • To put what CodesInChaos said into simpler terms: this is not an alternative algorithm for your private/public key pairs. Those are used for identification only. SSH does not use this new protocol for identification, but rather encryption. (Slight oversimplification, but hopefully you get the idea.) – Zenexer Sep 14 '15 at 3:35
  • If you're looking for an alternative to ECDSA or RSA, the new(ish) addition to OpenSSH, along with ChaCha20 and Poly1305, is Curve25519. You can use this with the ssh[d] config option KexAlgorithms curve25519-sha256, and with ssh-keygen -t ed25519. – ruief Mar 15 '18 at 21:26

Two things that it means to me are:

  • it's a stream cipher, therefore not parallelizable. Although it's a stream cipher, it has a randomly accessible output stream (PDF), so it can be parallelized (unlike RC4, and stream ciphers in general). Poly1305 is also parallelizable

    SSH already has a set of counter mode block ciphers which are parallelizable (RFC4344 Section 4) though they don't get you a performance gain out of the box. ChaCha20 (20 rounds) is a little faster than RC4, comparing cycles per byte, and is faster than AES256.

  • it's an extra algorithm in the SSH negotiation

The second point needs some elaboration: there have been a number of extra key-exchange (EC), MAC (SHA-2) algorithms added recently, and now another cipher. This increase causes problems with older (including embedded/devices) SSH server implementations. In SSH the various algorithms are spelled out, rather than having short, fixed identifiers like TLS. The workaround is to chop the list down with explicit Ciphers, MACs and/or KexAlgorithms in your ssh config. There's also the potential for protocol enforcing firewalls or IPSs to misfire.

I believe one protocol difference between TLS and SSH is that the authentication, key-exchange, cipher and MAC are identified and negotiated independently, with TLS each publickey-kex-cipher-mac set is one of a defined suite. Poly1305 adds authentication, so ChaCha20-Poly1305 is (effectively) an authenticating stream cipher, no separate MAC is required by SSH for it, the benefit of this is explained in David Miller's article linked to in the question.

  • You're contradicting yourself. You said that CTR mode is parallelizable, but stream ciphers are not. While many streamciphers cannot be parallelized, some can. A blockcipher in CTR mode is a stream cipher and thus a counter example. ChaCha is essentially a hash function in CTR mode. It is parallelizable, and fast implementations take advantage of that. For example Krovetz's implementation works on 3 blocks in parallel. – CodesInChaos Dec 11 '13 at 13:39
  • @CodesInChaos You're right, thanks for the explanation. I dug a little deeper. – mr.spuratic Dec 11 '13 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.