On Thu, Jul 25, 2013 at 04:41:43AM -0700, Owen Barton wrote: > > > If a government > > > secretly aquired the SSL private keys for a site, and the site > > > continued using them, then no convergence notary would know any > > > cause not to vouch for the key. > > > > What helps here is perfect forward secrecy. > > Could you describe how PFS helps here - the article didnt mesh with my > understanding here? > > My understanding was that PFS was primarily a defense against > (non-real-time) cryptographic attacks on stored traffic - if PFS is not > used the attacker could decrypt much more traffic with the same compute > power, since the same session key is used for much more data, wheras with > PFS the session is tiny, meaning that the attacker only gets a tiny bit of > data for the same level of juice.
That's not an accurate simplification of how ECDHE key exchange works under the eavesdropper+compelled-key-disclosure threat model. non-PFS: Under standard RSA key exchange in TLS, the "session key" is encrypted under a public/private keypair and sent over the link. PFS: Under ECDHE key exchange in TLS, the two sides compute a shared secret which is never sent over the link. This is forward secure because once the session key is deleted, there is not enough information to reconstruct the session key, even given the private key. Under RSA (non-"PFS"), a recording of the encrypted session can be decrypted by the private key by recovering the session key. Given the private key of a non-PFS session, decrypting a recording is the same amount of work as participating in the encrypted session. (Almost no work.) Given the private key of a PFS session, decrypting the recording is the same amount of work as brute-forcing the AES session key. (An enormous amount of work, far beyond the expected ability of Bluffdale still.) However, if the wiretapper has the private key ahead of time and performs an active MITM, the wiretapper can obviously perform a decrypt-reencrypt hop and interpose on both PFS and non-PFS sessions. This is much more expensive (in terms of operational costs, man-hours, and risk of catastrophic disclosure of the captured private keys). -andy -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
