Re: ChaCha20-Poly1305 for SSH

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

Simon Josefsson <simon%josefsson.org@localhost> writes:

> We could also describe a new SSH encryption algorithm that is based on
> the RFC 7539 construct.  Still using ChaCha20-Poly1305, of course, but
> it would work differently.
>
> As far as I understand, the critical technical difference between these
> approaches is whether encrypting the length field is useful or not.

It also uses a different formatting of the poly1305 input, which aligns
the poly1305 blocks with the chacha blocks. Which should be beneficial
in particular for hardware implementations.

> I'm told that encryption the field is of limited use because traffic
> analysis would see the packet lengths anyway.

I don't think that analysis is correct. (See below).

Nevertheless, I think it makes sense to use the rfc 7539 construction.

So my suggestion is to go with rfc 7539, and in addition, encrypt the
length field by something lietk

   encrypt_length(key, nonce, length)
         counter = 0
         block = chacha20_block(key,counter,nonce)
         return block[32..35] ^ length
         end

using the same key and nonce as input as with poly1305_key_gen in RFC
7539. (It's then possible, but not at all necessary, to generate the
poly1305 key and encrypt the length key using a single call to
chacha20_block. In contrast to chacha20-poly1305%openssh.com@localhost, which,
iirc, uses a separate chacha key just for encrypting the lengths).

Care is needed to specify the negotiation of aead algorithms, and
the details of what goes into the associated data.

> Does anyone see a strong need for encrypting the length field?

Yes. I think it's valuable defence-in-depth to hide packet lengths and
message boundaries. Note that in the ssh protocol, the boundaries of the
TCP segments need not match the SSH message boundaries at all. It's not
too difficult to arrange that most or all segment boundaries are in the
middle of an ssh message, using SSH_MSG_IGNORE packets when needed.

I won't argue that it is easy to make traffic analysis impossible, but I
believe it's still valuable to make traffic analysis harder.

Best regards,
/Niels

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