Re: ChaCha20-Poly1305 for SSH

On Wed, 20 Apr 2016, Stefan Bühler wrote:

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

It would be helpful if you said what in the documentation was
insufficient so we can improve it.

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

It's already happened: chacha20-poly1305 is supported by several
SSH implementations and uses a similar packet construction to
RFC5647 AES-GCM (with the exception of encryting the packet length).
There's also the -etm MACs in OpenSSH as Niels observes.

> 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

I chose to use an independently-keyed instance of chacha20 for
length field encryption to be completely sure there could be
no possible decryption oracle between them. This was a deliberately
conservative choice that was fortunately cheap since chacha20 is so
fast.

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

I agree that if we are redoing the chacha20-poly1305 mode then it
should match the parameter lengths used in other IETF protocols.

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

Like I said, it would be great if you let us know what in particular
was deficient in the documentation so we can fix it.

With regards to the future of the chacha20-poly1305, I'm hoping
to interest a researcher in looking into length-hiding as a
traffic-analysis countermeasure in the SSH protocol. The "Peek-a-boo"
paper considers fingerprinting websites in the web attack model, which
is very different to and in many ways more demanding than SSH's attack
model. It would be good to have more definitive research that targets
the SSH protocol and thread model passwords, keystroke timings, etc)
and make a decision based on that.

With that out of the way, and if it yields a recommendation to
pursue length-hiding then it's probably worth revisiting the exact
construction. E.g. your proposal to use the remaining bytes from
the first block, but I wasn't aware of [1] when I designed this mode.

-d

[1] http://www.iacr.org/archive/eurocrypt2012/72370677/72370677.pdf