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

[Adam Barth <[e-mail]>]

On Sun, Jan 9, 2011 at 4:09 PM, Willy Tarreau <[e-mail]> wrote:
> I have reused Maciej's code for AES-128-CTR to make it emit a constant
> stream and look there for a supposedly processable request (which is
> valid since Apache processes it and transcodes it if it finds it at
> the beginning of the stream).
>
> willy@pcw:~/c$ time ./aes-128-ctr-get
> Found the 'GET\n' pattern on the wire after 1608425803 bytes
>
> real    0m20.761s
> user    0m20.761s
> sys     0m0.000s
>
> It requires the client to send more data, but here we're only
> at 1.6 GB, roughly just 1000 times more than with the basic XOR
> method.
>
> However, it's limited to 640 Mbps only. It means that using this
> as a mandatory masking method will not even allow me to use a
> memcache at gigabit speeds on my local network :-(

Then you shouldn't use WebSockets to talk to memcache on your local
network.  WebSockets is not the solution to every problem.  For the
important uses cases, 640 Mbps with today's CPUs is vastly more than
enough.

> Once again, I'm not saying that I'd believe that any intermediary
> would seek a request that far. Neither do I believe it would seek
> one after one megabyte nor after any non CRLF byte BTW.
>
> But we're proposing this method because other ones are not deemed
> sure enough. However, it does not either cover the issues which
> caused the other methods to be proposed.
>
> So now either we should conclude that using AES to prevent a request
> from popping up is acceptable because the risks are low, so it must
> be possible to disable it for some use cases, or we conclude that
> it's not usable and the only masking solution consists in never
> putting a CR/LF on the wire.

The masking is not optional.  If your use case doesn't work with
masking, please a different protocol.

Kind regards,
Adam