Re: applying AES-GCM to secure shell: proposed "tweak"

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

Nicolas Williams <Nicolas.Williams%sun.com@localhost> writes:

> Encrypted packet length will cause more headaches if it means changing
> AEAD APIs.  If we really, really want encrypted packet lengths then
> let's use Niels' proposal of using a separate and separately keyed
> non-AEAD cipher to encrypt the packet length and then use the AEAD
> cipher to encrypt the rest of the packet.  (Niels' proposal has to
> involve padding the packet length if the non-AEAD cipher used to encrypt
> the packet length is not a counter mode or stream cipher.)

Actually, I'm suggested that we encrypt the first *block*, not just
the length field, with an independent cipher. The full block is then
authenticated as additional data to AEAD. In the case of AES-GCM,
there's a natural block size, and a reasonable choice for this cipher
is AES-CTR. This way, there's nothing special to the padding.

What's actually done to the data is very similar to what you'd do if
you applied AES-GCM to the entire message including length field, and
extracted length field first when decrypting. (It would be nice in
some ways, but less general, if the details could be defined so that
the result is *identical*).

Encrypting only the length field (or length + padding) would cause
more complexity and more overhead, I think.

Regards,
/Niels