Re: [hybi] AES-128-CTR not much safer, but not fast either
Willy Tarreau <w@1wt.eu> Mon, 10 January 2011 00:41 UTC
Return-Path: <w@1wt.eu>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8399B3A6860 for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 16:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.082
X-Spam-Level:
X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPiIXXu2+Ar1 for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 16:41:34 -0800 (PST)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 41EED3A6833 for <hybi@ietf.org>; Sun, 9 Jan 2011 16:41:34 -0800 (PST)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p0A0hhVl010576; Mon, 10 Jan 2011 01:43:43 +0100
Date: Mon, 10 Jan 2011 01:43:43 +0100
From: Willy Tarreau <w@1wt.eu>
To: Adam Barth <ietf@adambarth.com>
Message-ID: <20110110004343.GF5743@1wt.eu>
References: <20110110000908.GD5743@1wt.eu> <AANLkTik5BDTB-T8wbyXJF8iseSryfHgOATLDNc6HUz7k@mail.gmail.com> <20110110002533.GE5743@1wt.eu> <AANLkTimFc52=zm245VNhZ0pymOSmyT4NnSxXxrsAEjgD@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AANLkTimFc52=zm245VNhZ0pymOSmyT4NnSxXxrsAEjgD@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] AES-128-CTR not much safer, but not fast either
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2011 00:41:35 -0000
On Sun, Jan 09, 2011 at 04:31:33PM -0800, Adam Barth wrote: > On Sun, Jan 9, 2011 at 4:25 PM, Willy Tarreau <w@1wt.eu> 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 <w@1wt.eu> 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. Adam, it's not a matter of surviving or not, it's a matter of spending *all* the CPU cycles of a machine for something which is proven inefficient against the use case it was introduced for in the first place. The reason it is inefficient is not because of they crypto part, but precisely because the use case is wrong ("a caching intermediary might seek a request anywhere in the stream and for as long as possible"). It is possible that you planned to cover other vulnerabilities with this, but since you posted a complete paper without any argument for each new point, it's very hard to spot the reasons. We can just discover something is here, there is no *why* to that. Under these conditions, you can certainly expect that some people will bother why we'd suddenly decide that the protocol will work that way despite the costs when there is no explanation at all. Regards, Willy
- Re: [hybi] AES-128-CTR not much safer, but not fa… Thomson, Martin
- [hybi] AES-128-CTR not much safer, but not fast e… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Adam Barth
- Re: [hybi] AES-128-CTR not much safer, but not fa… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Adam Barth
- Re: [hybi] AES-128-CTR not much safer, but not fa… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Adam Barth
- Re: [hybi] AES-128-CTR not much safer, but not fa… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Adam Barth
- Re: [hybi] AES-128-CTR not much safer, but not fa… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Adam Barth
- Re: [hybi] AES-128-CTR not much safer, but not fa… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Adam Barth
- Re: [hybi] AES-128-CTR not much safer, but not fa… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Scott Ferguson
- Re: [hybi] AES-128-CTR not much safer, but not fa… Bruce Atherton
- Re: [hybi] AES-128-CTR not much safer, but not fa… Yuta Kitamura
- Re: [hybi] AES-128-CTR not much safer, but not fa… Willy Tarreau
- Re: [hybi] AES-128-CTR not much safer, but not fa… Cedric Vivier