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

[Willy Tarreau <[e-mail]>]

On Sun, Jan 09, 2011 at 04:20:25PM -0800, Adam Barth wrote:
> 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.

But a frontal switch which has to process the frames in an internet
infrastructure will require a crypto card to handle the non-secure
version of websocket. Clearly that does not make much sense !

The same machine has no problem handling 10 Gbps of HTTP traffic.
640 Mbps of WS traffic for multi-megabytes frames is a very low
performance in my opinion for a 3 GHz processor ! Any server is
able to cope with that bandwidth for large frames.

Regards,
Willy