Re: ChaCha20-Poly1305 for SSH

Hi,

some time ago I tried implementing ssh-chacha20-poly1305@openssh on my
own and was rather disappointed by the state of the documentation in
openssh (in the end the source code told me what I needed to know).

Seeing draft-josefsson-ssh-chacha20-poly1305-openssh-00 I hoped there
would be some improvement... but well, it is just a copy of the openssh
file :)

So I started to work on it, and also read some of the following
discussion on ietf-ssh.

A large part of the discussion spun off discussing a whish list for a
new binary packet protocol; changing the binary packet protocol probably
requires rewriting core logic in many SSH implementations, so this
should be done very carefully and not just for one cipher, and I somehow
doubt it will happen soon.

So I propose defining "chacha20-poly1305" as either the existing
"[email protected]" or as a slightly modified variant:

- using AEAD_CHACHA20_POLY1305 from RFC7539
- encrypt the packet length with otherwise discarded bytes from the
  first Chacha20 block, i.e. only a single Chacha20 instance
- pad the nonce to 12 bytes with zeroes on the left side, so one can
  simply reuse the original Poly1305 implementation with a 8-byte nonce.
- openssh patch:
  https://github.com/rus-cert/openssh-portable/tree/feature-chacha20-poly1305

The "full" documents can be found here:
https://github.com/rus-cert/ssh-chacha20-poly1305-drafts

It would be nice to get some feedback on whether there is interest in
getting "chacha20-poly1305" out before a protocol redesign and which
variant to go for.

If there is no interest in getting an RFC for this maybe at least the
openssh devs are interested in fixing their documentation :)

---

As far as I could see the following questions were raised in the context
of the original draft announcement and some later AEAD discussions. My
comments on them should explain why I think the openssh variant is
basically ok, and why I wouldn't pull more changes into a modified
version than I did above.

- Whether to use the Poly1305 data construction from RFC7539:

  At first I thought the Poly1305 usage in
  "[email protected]" is vulnerable to some length
  modifications; but then I remembered that Poly1305 uses an explicit
  termination in the padding.

  As the length of the AAD is fixed I see no security gain changing to
  the method described in RFC7539.

- Whether it is necesary to encrypt the packet length field:

  Some voiced a strong preference for this as a requirement to prevent
  traffic analysis.

  It was pointed out the encrypted could lead to some extra attack
  surface (or has done so in other protocols in the past), but I think
  it is safe in the context of Chacha20. I see nothing an attacker could
  gain here compared to not encrypting the length.

- Encrypting the packet length using otherwise discarded bytes from the
  Chacha20 block used for the Poly1305 key:

  It is a nice idea which can be used to optimize both performance and
  memory usage.

- Binary packet protocol rethink:

  This is certainly worth exploring, but I don't think this needs to be
  completed before "chacha20-poly1305" becomes official.

  I think a new family of algorithms could be started with a different
  binary packet protocol, or even a new SSH protocol version.

  (My idea for a new protocol: separate encryption framing and inner
  message framing. No need to hide the outer packet length anymore.)

- Changing padding requirements, authentication of the encrypted length:

  I see no need to change this in the context of a single algorithm.
  Belongs into a more generic protocol redesign.

Cheers,
Stefan