Fedora/Redhat and perfect forward secrecy

Reindl Harald h.reindl at thelounge.net
Mon Sep 9 11:00:59 UTC 2013

Am 09.09.2013 12:55, schrieb Florian Weimer:
> On 09/09/2013 11:58 AM, Andrew Haley wrote:
>> On 09/07/2013 12:52 AM, Gregory Maxwell wrote:
>>> Regardless, I think that argument would be an ignorant one:
>>> Approximately no one runs non-ECDH PFS on the web: it's insanely slow
>>> and it breaks clients.
>> Hmm.  Isn't non-ECDH PFS just straight integer (mod N) Diffie-Hellman?
> Yes, it is.
>> And that's what is insanely slow?
> I don't get it, either

google "dhe versus ecdhe performance"

>> 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?

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

-------- Original-Nachricht --------
Betreff: Re: Fedora/Redhat and perfect forward secrecy
Datum: Mon, 26 Aug 2013 11:07:29 +0200
Von: Florian Weimer <fweimer at redhat.com>
An: Development discussions related to Fedora <devel at lists.fedoraproject.org>
Kopie (CC): Reindl Harald <h.reindl at thelounge.net>, Mailing-List fedora-users <users at lists.fedoraproject.org>

On 08/24/2013 11:38 AM, Reindl Harald wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=319901
> looks like Redhat based systems are the only remaining
> which does not support EECDHE which is a shame these
> days in context of PRISM and more and more Ciphers
> are going to be unuseable (BEAST/CRIME weakness)

Current Fedora supports perfect forward secrecy just fine.  It's just
that web server operators routinely refuse to offer it.  (The situation
is different with mail servers.)  Operational benefits look rather
marginal to me.  It may discourage interested parties from requesting
server private keys, but even that isn't assured.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130909/f2a94579/attachment.sig>

More information about the devel mailing list