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

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> If the packet length decrypted to something < max packet length and
> there's no syslog/disconnect leak then the attacker recovers 16 -
> block size bits of the password.

Hmm.  Thank you.

Even that much, though, depends on the server disconnecting as soon as
it discovers the wrong MAC, and thereby leaking the decrypted length to
within the cipher's block size, doesn't it?

Also, ISTM the attacker recovers more than 16 bits; if the attacker
knows the packet size as revealed by disconnect timing (which this
seems to be entirely predicated upon), that reveals the exact packet
length field (since the length includes all padding, and thus knowledge
of the number of cryptosystem blocks in the packet gives the exact
packet_length value).  Combined with the attacker's presumed knowledge
of the previous ciphertext block in CBC mode, this reveals a full 32
bits of data from the block of interest.  Is this analysis wrong?

I also note it works only on data at the beginnings of blocks - this is
useless to an attacker who wants something beyond the first four bytes
of a cryptosystem block.

Fortunately, it's fairly easy to frustrate.  The first technique that
comes to mind is one I sketched upthread, which the receiver can
implement: react to bad packet lengths or invalid MACs by reading data
out to the maximum valid packet length before disconnecting.  The
second is something the sender can implement: rather than pausing
transmission at packet boundaries, always pad with an IGNORE packet -
and write only part of (the encrypted version of) it.  This makes it
harder for the attacker to find the length field in the data stream.
(This one provides only a few more bits of protection, since the
attacker can just guess at how much of the IGNORE packet the sender is
holding queued, but every additional bit of difficulty is another
factor of two less practicality.  And when the line is idle is when you
least mind inserting largeish amounts of pad data.)

And, of course, not using CBC ciphers breaks it totally.

/~\ 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