Re: [hybi] AES-128-CTR not much safer, but not fast either

[Willy Tarreau <[e-mail]>]

On Sun, Jan 09, 2011 at 11:16:01PM -0800, Adam Barth wrote:
> On Sun, Jan 9, 2011 at 11:08 PM, Willy Tarreau <[e-mail]> wrote:
> > On Sun, Jan 09, 2011 at 11:02:47PM -0800, Adam Barth wrote:
> >> On Sun, Jan 9, 2011 at 10:58 PM, Willy Tarreau <[e-mail]> wrote:
> >> > On Sun, Jan 09, 2011 at 10:44:19PM -0800, Adam Barth wrote:
> >> >> Or we could just use AES-128-CTR like everyone else in the known
> >> >> universe and not worry about whether we've shaved exactly the right
> >> >> number of hairs off our home-brew pseudo crypto.
> >> >
> >> > Adam, I just explained that AES-128-CTR as you proposed it does not
> >> > address the points that were raised which made it appear here.
> >> >
> >> > In fact the real problem we really want to solve is make the CR/LF
> >> > bytes disappear from the stream. Those bytes are still present with
> >> > AES-128-CTR.
> >>
> >> Fortunately, we don't need to make the CR/LF bytes disappear from the
> >> stream.  What we need to do is prevent the attacker from choosing a
> >> string that can be used to attack an intermediary.  Using AES-128-CTR
> >> makes it so the attacker is forced to choose a pseudo-random sequence
> >> of bytes.  I claim that it is infeasible to attack an intermediary in
> >> this way using a pseudo-random sequence of bytes.
> >
> > For short a string lengths accepted by Apache (4 bytes), it *is* feasible
> > by making the client send an important amount of bytes as I have shown.
> > If we agree that we don't need to protect against that very unlikely issue,
> > then the simpler XOR masking is enough because the initial pseudo-random
> > makes it equally hard for the attacker to guess what the stream will look
> > like.
> 
> I stand by my claim that it is infeasible to attack an intermediary in
> this way using a pseudo-random sequence of bytes.
> 
> Your "attack" of finding the string "GET\n" after 1608425803 bytes
> (yes, that's 1.6 gigabytes) is meaningless.

Precisely, and it is as much meaningless as finding it after the same
amount of bytes using a simple XOR method with a 32-bit key. That was
the point I wanted to make, because at one point it was speculated
in the 32-bit vs HMAC that it was a concern.

So now we can move on to simpler algorithms and stop cripling the
protocol.

Thanks,
Willy