Re: ChaCha20-Poly1305 for SSH

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

Hi Niels,

thanks for your feedback!

On Thu, 21 Apr 2016 21:15:55 +0200
[e-mail] (Niels Möller) wrote:

> Stefan Bühler <[e-mail]> writes:
> [...] 
> 
> I hope you've also seen draft-nisse-secsh-aead-00. I'm replying
> looking for ways to improve that and move forward. 

My feeling is that this document already is the "protocol rethink" (and
not just a "small algorithm family"), because:
- a "protocol rethink" would only allow AEAD anyway
- when core packet handling is changed it should be done right in the
  first place

So let me repeat my idea for a new protocol here: I'd separate the
cryptographic message framing from the SSH message framing.

That way one could really use "any" standard AEAD interface without the
need to specify how the packet length is encrypted with each single
AEAD, simpler nonce generation, ...

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

Oh my... sorry. I meant Chacha20 of course; DJBs original definition
uses a little-endian 64-bit block-counter and a 64-bit nonce (often the
packet counter). RFC7539 moves the trailing 4 bytes from the block
counter (which are almost always zero - no packet is that big) and
prepends them to the nonce in the interface (but does the same thing
internally) to get the "standard" 12-byte nonce interface.

(This also applies to how the Salsa20 streaming function in
naclcrypto-20090310.pdf is applied. Chacha20 copies the definition of
the 16-byte input from Salsa20.)

Also see how I didn't need to change the Chacha20 nonce or
implementation for the openssh patch.

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

Yes, I'd prefer that too. But is the preference important enough to
modify an already existing protocol?

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

Sounds good to me.

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

I also consider this optional in my "variant" proposal; I'd be also
fine with the current openssh implementation simply using a second key.

When encrypting the packet length is still required (see my comments
regarding "protocol rethink" above) I think using different nonces in a
generic AEAD specification is a good idea (although I don't think the
shift by one bit is a good idea. I'd rather shift by 32-bits, requiring
a >= 8-byte nonce instead of >= 5-byte).

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

Agreed.

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

Sorry :) I considered the EtM padding handling as done in openssh a
"standard"; I meant I'd rather avoid further changes in context of a
single algorithm: I'd keep the "at least four bytes" and "pad to
multiple of min(8, blocksize)" requirements (which results in a
minimum packet size of 12 bytes instead of 16 with MtE).

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

I agree that a better AEAD integration is needed, and that it should
be done in a consistent way.

The question remains: push "chacha20-poly1305" being identical or close
to the openssh one or wait for a generic AEAD / "protocol rethink"?

Cheers,
Stefan