Cost

Posted Nov 7, 2013 12:53 UTC (Thu) by meuh (guest, #22042)
Parent article: Let's talk about perfect forward secrecy

One cost which is sometime forgotten is entropy needed to generate all the ephemeral random keys.
When enabling PFS, one need a good HWRNG or a fast CSPRNG.
See LCE: Don't play dice with random numbers article for example.

Entropy and DH kex protection

Posted Nov 21, 2013 14:14 UTC (Thu) by mirabilos (subscriber, #84359) [Link]

This is an actual problem:

For PFS, both sides must, independently of each other, generate good random nonces. Reusing one side’s half loses all secrecy.

TLS doesn’t protect the DH key exchange with the existing certificate(s) – the server usually has got an RSA key, the client sometimes has, yet these are used only for the auth phase.

I’d rather have a non-PFS session (maybe with an ephemeral key that lives, oh, say a day) first, in which the client send the server, and the server the client, some random bytes which the receiving side MAY add into their entropy pool, *then* they do DH kex, and only then the non-PFS session is changed to PFS.

Another option is to use a sign-only RSA certificate on the TLS server side. But I don’t think an off-the-shelf CA is going to issue one to me without major money, and I fear implementation problems because this is so rarely used – mostly due to the cost of having to generate an ephemeral RSA encryption key per session.

Really, the either-or in SSLv3/TLSv1 smells like the NSA already had its fingers in there.