[upofadown]

>All data transmitted without forward secrecy on most web sites is compromised.

Forward secrecy does not protect against broken cryptography, so this is more about what methods were used and how much an new technique like this affects them.

[lokedhs]

True, but it does protect against broken RSA. Because RSA is a not used to encrypt the actual data. That's probably using AES.

[upofadown]

If you break RSA then you get the AES session key. You don't have to break the AES.

[tialaramex]

Nope. Whilst that's how TLS_RSA_WITH_AES_128_CBC_SHA works, this not how Forward Secrecy enabled suites like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 work. Most sites (and certainly any sites that think they're "secure") thus are not affected in this way.

In TLS 1.3 all suites (such as TLS_AES_128_GCM_SHA256) have forward secrecy so it isn't even explicitly called out.

In these modern modes (and in other modern protocols like SSH) the two peers agree random ephemeral keys (these days with Elliptic Curve Diffie Hellman) and long term private keys are only used to sign things to prove who you're talking to over the resulting securely encrypted connection.

So if you break RSA you can forge those signatures but you can't decrypt messages sent to and from the legitimate owner of the keys, those were, as your parent explained, secured with AES and not RSA. You would need to perform a live active attack, a MitM to interpose between the real server and its clients so as to decrypt all messages in transit.

[jojobas]

The point of forward secrecy is that past key are not recoverable from future communications. You need to store the whole communication history to have any chance.

[upofadown]

Unless you break the encryption. Then you get the past keys.

Forward secrecy only protects against the exposure of private key material. It does not protect against broken cryptography as it depends on the cryptography to keep old messages private. That's because it works by forgetting the session keys. If you can derive those session keys again then it is of no value.

[jojobas]

Nope. A session key is normally not created by one party and sent to another, it's generated by something like Diffie-Hellman in which the long-living RSA keys are only used for authenticity verification. Diffie-Hellman requires discrete logarithms rather than factorization (and then there are more modern methods).

[gowld]

You always have to obtain the communication you want to decrypt; that's not the interesting part of the problem.

The interesting part is using a weakness in one part to help decrypt a different part.