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

[Adam Barth <[e-mail]>]

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.  How many bytes do you
think you'd have to examine before finding the string "Willy Tarreau"
?

Kind regards,
Adam