Fedora/Redhat and perfect forward secrecy

Gregory Maxwell gmaxwell at gmail.com
Mon Sep 9 17:49:58 UTC 2013

On Mon, Sep 9, 2013 at 9:12 AM, Paul Wouters <paul at nohats.ca> 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

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

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:

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)

More information about the devel mailing list