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

[Adam Barth <[e-mail]>]

On Sun, Jan 9, 2011 at 4:25 PM, Willy Tarreau <[e-mail]> wrote:
> 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.

Somehow, we will survive.

Kind regards,
Adam