[Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)

[Phillip Hallam-Baker]

On Wed, Sep 11, 2013 at 2:40 PM, Bill Stewart <bill.stewart at pobox.com>wrote:

> At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote:
>
>> Perfect Forward Secrecy is not perfect. In fact it is no better than
>> regular public key. The only difference is that if the public key system is
>> cracked then with PFS the attacker has to break every single key exchange
>> and not just the keys in the certificates and if you use an RSA outer with
>> an ECC inner then you double the cryptanalytic cost of the attack (theory
>> as well as computation).
>>
>
> I wouldn't mind if it had been called Pretty Good Forward Secrecy instead,
> but it really is a lot better than regular public key.
>

My point was that the name is misleading and causes people to look for more
than is there. It took me a long time to work out how PFS worked till I
suddenly realized that it does not deliver what is advertised.



> The main difference is that cracking PFS requires breaking every single
> key exchange before the attack using cryptanalysis, while cracking the RSA
> or ECC outer layer can be done by compromising the stored private key,
> which is far easier to do using subpoenas or malware or rubber hoses than
> cryptanalysis.
>

That is my point precisely.

Though the way you put it, I have to ask if PFS deserves higher priority
than Certificate Transparency. As in something we can deploy in weeks
rather than years.

I have no problem with Certificate Transparency. What I do have trouble
with is Ben L.'s notion of Certificate Transparency and Automatic Audit in
the End Client which I imposes a lot more in the way of costs than just
transparency and moreover he wants to push out the costs to the CAs so he
can hyper-tune the performance of his browser.


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130911/3cc55bab/attachment.html>