Am 09.09.2013 18:12, schrieb Paul Wouters:
On Mon, 9 Sep 2013, Reindl Harald wrote:
I don't get it, either
google "dhe versus ecdhe performance"
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
Let’s focus on the server part. Enabling DHE-RSA-AES128-SHA cipher suite hinders the performance of TLS handshakes by a factor of 3. Using ECDHE-RSA-AES128-SHA instead only adds an overhead of 27%. However, if we use the 64bit optimized version, the cost is only 15%
is that enough to understand why nobody on this world is using DHE and so your "Current Fedora supports perfect forward secrecy just fine" is *far* away from the reality?
Not for me. I thought TLS was latency bound. The above "factor 3" does not state whether TLS client/server were in the same LAN (or even VMs on the same host).
it does not matter, the world measures CPU load here
For the client, clearly CPU is not the limiting factor
if you stay on topic you realize that this does not matter you can't do PFS to *any* major website these days
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.
*you* are talking clusters here
it does not help much support forward secrecy in a way *nobody* else on this planet is supporting it and so you repsonse below is uneducated - period
Ignoring the obvious legal (and now potential backdoor) problems with ECC is also not very educated
we are speaking about the real world, not about therory
*you can't* do PFS to *any* relevant target because nobody offers negotiation with DHE - so stay on topic and as long nothing is *proven* ignore it while it *is* proven that PFS doe snot work with Redhat/Fedora systems to the rest of the world
-
Reindl Harald