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

[Willy Tarreau <[e-mail]>]

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.

And if the risk suddenly becomes acceptable, then we can fallback
to much simpler masking algorithm which share the same risks for
that matter.

> Adam

Willy
> 
> 
> On Sun, Jan 9, 2011 at 10:36 PM, Willy Tarreau <[e-mail]> wrote:
> > On Mon, Jan 10, 2011 at 10:21:16AM +0800, Thomson, Martin wrote:
> >> On 2011-01-10 at 11:09:08, Willy Tarreau wrote:
> >> > willy@pcw:~/c$ time ./aes-128-ctr-get
> >> > Found the 'GET\n' pattern on the wire after 1608425803 bytes
> >>
> >> You might also find the collected works of Shakespeare in the byte stream had you waited a little longer.
> >
> > I know, that's just a matter of defining "a little longer", as none of us
> > will live long enough for that.
> >
> >>  I'm not sure what you are hoping to prove by searching.
> >
> > What I'm just showing is that we have the following points :
> >  1) it was reported by an experiment that some caching intermediaries
> >     were waiting for an HTTP request after the HTTP handshake was over
> >
> >  2) it was speculated that some lazy intermediaries might possibly skip
> >     over whatever they did not understand to resync on an HTTP request
> >     they understand and execute it, hence the need for masking the
> >     stream or payload. Please note that no such intermediary has even
> >     been remotely detected, and that several people here who have
> >     already been involved with server code expressed that making them
> >     capable of doing so would be much more difficult than doing the
> >     right thing and would not even respect the principle of laziness.
> >
> >  3) it has been suggested that a simple 32-bit XOR was not enough and
> >     that stronger cryptography was needed, because after a certain
> >     number of attempts, the server might get the client to send a
> >     request that such an intermediary can parse.
> >
> >  4) it was reported that at least one intermediary (Apache) accepts
> >     an HTTP/0.9 request as simple as "GET\n".
> >
> >  5) it was shown that whatever algorithm we used to address the third
> >     point was not enough to cover the second point for the supposedly
> >     lazy intermediaries from #2 acting like Apache.
> >
> > So now, we have a choice :
> >  - either we agree that #2 above is not that much of a risk such that
> >    we don't need #3 to address it ;
> >
> >  - or we agree that #2 is still much of a concern, but as #4 is real,
> >    then #3 is not a valid solution, as was proven with #5, and we
> >    must use another one.
> >
> > But right now we're just complicating the protocol and removing some
> > possibilities of later extensions without addressing the reason why
> > we did that in the first place.
> >
> > Thanks,
> > Willy
> >
> > _______________________________________________
> > hybi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hybi
> >