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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Apr 15, 2009 at 11:15:48PM +0200, Niels Möller wrote:
> 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.

Ah, clever.  I'm OK with that as an option.  I'd like the option to have
unencrypted packet lengths (meaning the first block of encryption starts
at byte #4 (zero-based numbering) of the packet.

But, actually, I think I was wrong about PKCS#11, it does seem to allow
online decryption with AEAD modes.

Nico
--