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

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

On Wed, Apr 15, 2009 at 05:51:24AM -0700, James Blaisdell wrote:
> I can live with cleartext length field or encrypted length field.  I
> have implemented AES-GCM as the draft stands now, so I know it's
> technically possible.  It has been suggested that some AES-GCM
> implementations must process the message as a single block of data ---
> a black box.  I don't know what hardware offload (proprietary?) that
> is unable to process AES-GCM in a chunk manner; Cavium can process in
> chunks.  I suppose at some point in the future an AEAD-* method will
> not be able to process the message in chunks, but this draft is for
> AEAD-AES-GCM.  Are we trying to future proof something that may never
> happen?  Even so, I would imagine it could dealt with at that time ---
> there will be an inconsistency now or future.  

It is entirely reasonable to construct AEAD APIs that require that the
caller provide the correct length up front.  Were it not for this
particular document that's exactly how I'd do it.

IN FACT, that's EXACTLY how PKCS#11 handles AEAD.  See:

http://mirror.switch.ch/ftp/doc/standard/pkcs/pkcs-11/v2-30/pkcs-11v2-20a5d1.pdf

"Set the message/data length ulDataLen in the parameter block. This
length should not include the length of the MAC that is appended to the
cipher text."

> I do agree sending the length field in the clear will cause some
> headaches at a lowest level, since a new in/out method will need to be
> written and tested.  However, I don't see the issues around NEWKEY
> some have suggested, but perhaps that implementation specific.  The
> encrypted length field has been a pain in the past, especially for
> async implementations like mine, but I have lived with it fine for
> last few years.  

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

> The only issue I have any energy around are suggestions for fallback
> approaches or no-MAC; similar approaches have been suggested for
> SSH-ECDSA.  These approaches create a great deal of work and break the
> current protocol model.  

Agreed, but no such suggestions are on the table.