Compression side channel

[Ben Laurie]

Hadmut Danisch wrote:
> 
> On Sat, Sep 08, 2001 at 10:45:14PM -0400, John Kelsey wrote:
> >
> > where the encryption preserves length (e.g., RC4 encryption).  Suppose
> > someone is sending a secret S in these messages, and the attacker gets
> > to choose some prefix or suffix to send, e.g.
> >
> > X[0] = S+suffix[0]
> > X[1] = S+suffix[1]
> > ...
> 
> Good point. The mistake seems to be mixing a (non-compressible)
> secret and a (compressible, possibly attacker-chosen) message in one
> compression run.  It seems to be a good idea to compress every
> logical part of the plaintext separately (and to compress only
> things which are compressible).

Of course you may well not have that luxury. I've been contemplating
where this attack could realistically be mounted, and it seems to me
that HTTPS is a good example where it could well be possible.

Imagine a system where the admin of the system can view users' account
details. If more than one is displayed on the same page, the attacker
could modify their own details in order to reveal the details of others.
I'm sure this must be extremely common. There are bound to be other
examples - once you've had this idea, a really obvious one is any kind
of shopping basket admin system.

Its far too late to fix HTTPS to solve this problem. Luckily almost
no-one uses compression in SSL - and perhaps they shouldn't.

Also, of course, if you compress each logical part separately, you will
normally get no compression - compression tends to fare badly on short
inputs, especially adaptive compression.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com