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

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

On Thu, Apr 16, 2009 at 04:15:33PM +1200, Peter Gutmann wrote:
> Nicolas Williams <Nicolas.Williams%sun.com@localhost> writes:
> 
> >I don't recall where the attack is described.
> 
> It's in a conference paper that hasn't been published yet, to appear at the
> IEEE Oakland conference in... May, I think.
> 
> [Pause]
> 
> Yup, see http://oakland09.cs.virginia.edu/papers.html.

Thanks.

> >Briefly: an active attacker replaces what he/she knows to be an encrypted
> >packet length with bytes that he/she knows correspond to an encrypted
> >password, then after that sends the remainder of the packet (possibly
> >garbage) one byte/block at a time.
> 
> It's interesting to note here that there have been a number of attacks (of
> which this is the latest) on encrypted lengths, but none on plaintext lengths
> as used by TLS.  In other words the "more secure" option used by SSH is
> actually less secure than the "less secure" option of not encrypting, the
> cause being the unnecessary complexity of processing that this introduces (see
> my earlier posts in this thread, and I still owe people some replies for one
> or two of those, sorry).

Well, sortof.  TLS says it does not protect against traffic analysis,
therefore we consider traffic analysis attacks out of scope -- there are
no traffic analysis attacks against TLS by definition.  That's not
exactly a fair comparison.

That said, I think encrypted packet lengths are more trouble than
they're worth and don't actually suffice for protection against traffic
analysis, which makes you wonder what the heck was ever the point.

For example, say I'm prompted for a password, echo-off, in a pty
session, and my client sends keystrokes one at a time.  Well, any
eavesdropper can notice that pattern and determine the length of my
password.  The server can detect this and defeat this by adding IGNORE
messages to emulate echo-on, and the client can add random padding or
else gather more keystrokes before sending them -- but all of this is
not-crypto and if it's needed it's needed because encrypting the packet
length was insufficient.

Nico
--