Re: ChaCha20-Poly1305 for SSH

[nisse%lysator.liu.se@localhost (Niels Möller)]

Stefan Bühler <ietf-ssh%stbuehler.de@localhost> writes:

> On Thu, 21 Apr 2016 21:15:55 +0200
> nisse%lysator.liu.se@localhost (Niels Möller) wrote:

>> 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"),

That's not my intention. I want it to be general enough to guide
specification of other aead schemes, but otherwise keep changes close to
minimal.

(To really do minimal changes to the ssh protocol, one shouldn't do aead
at all, but specify chacha as a cipher, and some mac based on poly1305,
and use the old way of applying the mac to the plain text).

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

To me, 64 bits sounds like a very reasonable size for both the counter
and the nonce. I haven't quite understood why RFC 5116 mandates
("SHOULD") a 12-byte nonce, or its separation into "fixed" and "counter"
part. 

For ssh, it doesn't matter, a 32-bit block counter is large enough, by a
large margin.

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

If we go with the 5116-style AEAD, I guess it would make some sense to
describe the distinct-nonce hack using the "fixed |
counter"-terminology, with a fixed part being different for length field
and the data. But then why not do it the same way for chacha-poly1305?

The reason why I ended up proposing the shift-by-one-bit construction
was that I think a reasonable AEAD API will have an auto-increment
function, incrementing the nonce by one for each message processed. With
the shift-by-one bit, the sequence in which nonces are used is simply
incrementing, with even ones for length encryption and odd ones for
data. With any other formatting, one would need two set_nonce calls per
message, or two separate state structs. So that seemed convenient to me,
but I guess I'm biased by how my crypto library works.

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

Noted (I think some one else expressed a similar opinion). But precesily
what is padded changes, with aead, it has to be the data exluding the
length field. And I take it chacha should be viewed as a stream cipher
and hence pad to 8 bytes, not pad to 64 bytes?

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

My preference would be

1. Do something close to openssh.

2. Specify use of chacha and poly1305 as separate cipher and mac.

3. Wait for ssh version 3, which isn't likely to happen.

Regards,
/Niels

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