On Fri, Apr 25, 2014 at 12:00:40PM +0200, Lukas Tribus wrote: > Hi Igor, > > > > Looks fantastic, could haproxy support this? > > > > http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html > > This doesn't depend on HAProxy, but on OpenSSL. > > If you compile the 1.0.2-aead branch of OpenSSL git and link haproxy > against it, you will have this (but you will use an experimental > branch of openssl). > > For production use I strongly advise against doing this and wait for > OpenSSL to merged this branch to a stable branch (probably when 1.0.2 > gets released).
Also, given the numbers, the most important is not the CPU on the terminal but what it costs on the server side : the algorithm focuses on devices that don't have AES hardware acceleration (which I'd call low-end devices), and in the tests, these devices still get 200-300 Mbps of AES, which is much beyond what their connectivity allows. What this means is that until we reach such speeds, the algorithm is not a limiting factor on these machines. But if it becomes a limiting factor for the servers dealing with tens of hundreds of these devices in parallel, then the choice goes for the fastest *server-side* algorithm which will allow *all* users to benefit from it at the same time. That does not mean it's not interesting, but that this should be considered with all angles at the same time. Regards, Willy
