Re: ChaCha20-Poly1305 for SSH

[[e-mail] (Niels Möller )]

Stefan Bühler <[e-mail]> writes:

> 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 :)

I think Simon's intention was percisely to document what openssh does.

I hope you've also seen draft-nisse-secsh-aead-00. I'm replying looking
for ways to improve that and move forward. 

> A large part of the discussion spun off discussing a whish list for a
> new binary packet protocol; [...] and I somehow
> doubt it will happen soon.

Agreed.

> - 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.

I'm not following you here. And I'm not sure what you mean by "original poly1305".
Poly1305-AES as defined in http://cr.yp.to/mac/poly1305-20050329.pdf?
Or the salsa20-poly1305 described in
http://cr.yp.to/highspeed/naclcrypto-20090310.pdf, which I think is what
chacha-poly1305 evolved from? I don't think either uses an 8-byte nonce.

> - Whether to use the Poly1305 data construction from RFC7539:
>
>   At first I thought the Poly1305 usage in
>   "[e-mail]" is vulnerable to some length
>   modifications; but then I remembered that Poly1305 uses an explicit
>   termination in the padding.

As a crypto library author, I'd really prefer if there were a single
definition of chacha-poly1305 used in all applications. But that's maybe
not a very compelling argument for ssh protocol design. There may also
be reasons of ietf politics to stick to ietf's definition.

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

I'm also unaware of any difference in security.

> - 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.

My quite strong opinion is that we shouldn't force others to choose
between encrypted packet lengths, and using chacha-poly1305. And when
writing a specification which mentions this topic, I'd like to recommend
that other AEAD ciphers also encrypt the packet lengths, and give some
clear guidance on how to do it properly.

> - 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.

I agree it's a nice idea. I didn't go that way in my draft, because (i)
the optimization is minor, a single chacha_core operation and very small
state, and (2) because it's very algorithm specific, it doesn't
generalize to other AEAD ciphers. I'd be happy to change, if there is
support for this idea.

Also note that it's straightforward to this based on a pure
RFC5116-style interface to chacha-poly1305, which doesn't output the
additional bytes of the first block: simply run chacha20 one more time
to get the bytes used for length encryption. No less efficient than
using a separate chacha instance, like openssh is doing.

> - 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.

I'm afraid some tweaks to the padding requirements are needed even if
you only think of chacha-poly1305, the original padding rules don't make
much sense when the length isn't encrypted in the same way as the rest
of the payload.

And I think it's desirable to have AEAD ciphers in ssh do things the
same way. It's a bit annoying, because the details aren't terribly
important, but it has to be nailed down, and I have difficulty finding a
way that isn't a bit ugly in one way or the other.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.