<div dir="ltr">On Thu, Jul 25, 2013 at 12:05 PM, Andy Isaacson <span dir="ltr"><<a href="mailto:adi@hexapodia.org" target="_blank">adi@hexapodia.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Jul 25, 2013 at 04:41:43AM -0700, Owen Barton wrote:<br>
> > > If a government<br>
> > > secretly aquired the SSL private keys for a site, and the site<br>
> > > continued using them, then no convergence notary would know any<br>
> > > cause not to vouch for the key.<br>
> ><br>
> > What helps here is perfect forward secrecy.<br>
><br>
> Could you describe how PFS helps here - the article didnt mesh with my<br>
> understanding here?<br>
><br>
> My understanding was that PFS was primarily a defense against<br>
> (non-real-time) cryptographic attacks on stored traffic - if PFS is not<br>
> used the attacker could decrypt much more traffic with the same compute<br>
> power, since the same session key is used for much more data, wheras with<br>
> PFS the session is tiny, meaning that the attacker only gets a tiny bit of<br>
> data for the same level of juice.<br>
<br>
</div>That's not an accurate simplification of how ECDHE key exchange works<br>
under the eavesdropper+compelled-key-disclosure threat model.<br>
<br>
non-PFS:<br>
<br>
Under standard RSA key exchange in TLS, the "session key" is encrypted<br>
under a public/private keypair and sent over the link.<br>
<br>
PFS:<br>
<br>
Under ECDHE key exchange in TLS, the two sides compute a shared secret<br>
which is never sent over the link. ¬†This is forward secure because once<br>
the session key is deleted, there is not enough information to<br>
reconstruct the session key, even given the private key.<br>
<br>
Under RSA (non-"PFS"), a recording of the encrypted session can be<br>
decrypted by the private key by recovering the session key.<br>
<br>
Given the private key of a non-PFS session, decrypting a recording is<br>
the same amount of work as participating in the encrypted session.<br>
(Almost no work.)<br>
<br>
Given the private key of a PFS session, decrypting the recording is the<br>
same amount of work as brute-forcing the AES session key. ¬†(An enormous<br>
amount of work, far beyond the expected ability of Bluffdale still.)<br>
<br>
<br>
<br>
However, if the wiretapper has the private key ahead of time and<br>
performs an active MITM, the wiretapper can obviously perform a<br>
decrypt-reencrypt hop and interpose on both PFS and non-PFS sessions.<br>
This is much more expensive (in terms of operational costs, man-hours,<br>
and risk of catastrophic disclosure of the captured private keys).<br></blockquote><div><br></div><div>Thanks for the great explanation Andy!</div><div>I think the main thing I hadn't fully understood that the session key was recoverable under RSA.</div>

<div><br></div><div>- Owen</div></div></div></div>