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

[Adam Barth <[e-mail]>]

On Sun, Jan 9, 2011 at 11:52 PM, Willy Tarreau <[e-mail]> wrote:
> 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.

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