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:

> There has been a security vulnerability that resulted from information
> leaks that take place when the encrypted packet length is decrypted and
> checked before the MAC is verified.  The leak was enormously compounded
> by sending the decrypted packet length in a DISCONNECT packet, but also
> by syslog()ing the decrypted packet length as well.

Thanks. Do you have a pointer to more details?

> I've not looked at how PKCS#11 deals with AEAD, but I'm pretty sure that
> it does not have any support for encrypted pacaket lengths.

I think it would be valuable if you could check that. Other APIs and toolkits
mentioned in the discussion seem to support it. The
specification, 
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf,
says the following as the first item in the feature list (page 2):

  * The GCM functions are "online" in the sense that the lengths of
    the confidential data and the additional, non-confidential data
    are not required in advance; instead, the lengths can be
    calculated as the data arrives and is processed.
    
I'd expect that implementations allow processing the first block as
soon it it has arrived. (Yes, I realize the above sentence is not
normative in any way, and it might be interpreted differently, but at
least I think it's clear that block-by-block (or even byte-by-byte)
operations are considered reasonable).

(And the last time convenient use of some existing programming API had
a clear and visible impact on the design of the ssh protocols, we got
the "dss_signature_blob" (RFC 4253, section 6.6)...).

Regards,
/Niels