Re: AEAD in ssh

[denis bider <ietf-ssh3%denisbider.com@localhost>]

I've recently been implementing AES-GCM, and it has so far involved considerable architectural changes. The Bitvise SSH implementation abstracts cryptography into a pluggable crypto provider. Previously, the API to the crypto provider was low-level, and the SSH implementation made the calls to encrypt, decrypt, and calculate MAC. In order to implement AEAD, this had to be turned on its head, so that the interface to the crypto provider is now fairly high-level. The crypto provider must now have awareness of the SSH packet format. To keep the same interface for AEAD and traditional ciphers, I had to move the job of encrypting and decrypting a packet from the SSH implementation into the crypto provider. (The alternative would be to have two interfaces.)

My point is that implementing AEAD may likely require restructuring as it is. I'm not sure this is a reason to dismiss the idea of encrypting the length of the next packet as part of the previous packet.

A good reason to set it aside, I think, is that we have a solution that's architecturally simpler than this. I think lengths in AEAD should just be encrypted with the same underlying block cipher in CTR mode. No AEAD instance required.

Niels Möller <nisse%lysator.liu.se@localhost> , 2/23/2016 6:41 PM:

Bryan Ford <brynosaurus%gmail.com@localhost> writes:

> I can understand that position. However, one potentially
> counter-balancing consideration is that the introduction of new
> AEAD-based ciphersuites inherently introduces a new,
> wire-protocol-incompatible “record format” anyway that needs to be
> negotiated.

I agree, but at least it's only a different per-packet transformation.
Having to guess future packet sizes or emit extra packets is much more
than a new record format. I don't think it's a good tradeoff, too much
new complexity for little benefit.

My understanding is that cleartext length fields are believed to be
secure, in that the only thing leaked are message boundaries. And hiding
them using a separate stream cipher is a simple way to stop that leak
(and the benefit of doing that is under debate). In particular, the even
simpler alternative, to apply the AEAD to the 4-byte length field,
including authentication, seems like overkill.

I think simplicity is essential for making progress here, if we go for a
design of ssh version 3, discussion will never end.

> Deferring useful record format changes until the next major protocol
> version,

I don't expect any need for a new major version of the ssh protocol for
the next one or two decades. It's not too painful to add aead support
(and all other additions of new algorithms have been smooth, as far as I
can tell).

Regards,
/Niels

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