On Mon, Sep 9, 2013 at 9:12 AM, Paul Wouters <paul@xxxxxxxxx> wrote: > For the client, clearly CPU is not the limiting factor. For regular TLS > servers, this should also not matter. For fully loaded TLS servers or > TLS accelerators, the factor 3 on the CPU load will matter, but we're > talking clusters of machines here. Dropping in a few extra machines > shouldn't be that hard to give your patent-encumbered endusers PFS. The difference between DHE and ECDH in TLS is a difference of supporting supporting about 3,000 connections per second and supporting something like 800 connections per second (somewhat vague numbers, opeenssl speed won't bench DH apparently, it's somewhat slower than RSA encrypt due to the exponentiation by large secret values). And this is comparing apples and oranges 256bit ECDSA (conjectured security involving a best attack 2^128) against DH-1024 (only 80 bit conjectured security). Comparing with DH-1024 is sort of silly because people do not consider 80 bit security adequate anymore. The comparison with 3072 bit DH is down to more like 200 connections per second. But again, and sorry to reiterate but it seems to be have been missed: ~No one actually supports the old DHE PFE, and offering it breaks some clients. So regardless of the speed concerns, a choice to not support ECDH is a choice to not have PFS at all, at least on public facing webservers. > Ignoring the obvious legal (and now potential backdoor) problems with > ECC is also not very educated. I am certainly not ignoring legal concerns. While there are some patented EC cryptographic techniques, the basic infrastructure including ECDH over prime fields was first published back in 1984 and is not patentable. The IETF has published an extensive RFC covering the foundations of ECC which carefully shows to-old-to-be-patentable direct citations: http://tools.ietf.org/html/rfc6090 If Redhat is aware of a specific patent concern here, they're keeping it secret from the public. The continued claims that there are legal issues here behind basic support really don't make a lot of sense, especially considering the functionality in RHEL. (I would also note that the support in RHEL somewhat oddly support _only_ the parameters from the NSA, which doesn't quite play into the expressed concern about backdoors) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
