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

[Willy Tarreau <[e-mail]>]

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.

Regards,
Willy