IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



>>> The leak was enormously compounded by sending the decrypted packet
>>> length in a DISCONNECT packet,
>> !!  It's hardly the fault of the protocol if implementations
>> gratuitously leak cribs for attacking the crypto!
> Even without the DISCONNECT and syslogging you still leak quite a bit
> IFF the packet length decodes to something less than max packet.

How?  If my response to an invalid packet length is to read the right
amount of data for a max-length packet and disconnect, and my response
to an invalid MAC is to read as much as necessary to pad to the amount
I would have read if the packet length were max-length and then
disconnect, I don't see how I'm leaking anything - unless you happen to
get the MAC right too, which reduces attack success probability
substantially.  (Admittedly, this does not describe the behaviour of
any implementation, as far as I know.)

Or, I suppose, unless you're doing precision timing attacks to
determine how much I'm feeding to my MAC computation before going into
read-and-discard mode.  To defeat that I'd probably have to decrypt the
extra garbage (and, ideally, feed it into whatever hashing the MAC
algorithm in question does).

> Yes, it's unlikely for an active attacker to cause that, since max
> packet will usually be on the order of 2^16 but the truly max packet
> length is on the order of 2^32, but surely you see the point.

Presumnably, the 2^-18, 2^-16, or 2^-14 probability of an attack being
successful I've seen cited is due to that: it works only when the
decrypted length has enough zero high-order bits that the attacker can
tell it from random garbage.  But I've been staring at CBC and haven't
been able to see how knowing that is useful to the attacker - except as
a partial crib for attacking the bulk crypto, which is not what the
descriptions sound like.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B



Home | Main Index | Thread Index | Old Index