Hacker News Reader

Comment by mrmckizzle | Hacker News Reader

I'm no expert in cryptography, but don't most versions of TLS/HTTPS use RSA for encryption? Which in turn uses the private/public key methodology to prevent such attacks?

View on HN

Even in the 90s, SSL (and PGP) used hybrid encryption. The data is encrypted (and authenticated) using symmetric primitives and the symmetric keys are exchanged or established using asymmetric cryptography. Asymmetric cryptography is also used to authenticate the counter party.

RSA encryption was popular for SSL/TLS but because it does provide forward secrecy it was deprecated. These days RSA is only used in digital signatures (which are not encryption) while key exchange is done using Diffie Hellman (specifically ECDHE).

CBC mode cipher suites used to add up to 8 bytes of padding (for deprecated 3DES) and up to 16 bytes of padding for AES, but the mac-then-encrypt TLS construction turned out to be very hard to implement correctly, so TLS 1.3 only allows modes based on CTR (AES GCM, CCM and ChaCha20-Poly1305) so not even minimal padding is done.

> RSA encryption was popular for SSL/TLS but because it does provide forward secrecy it was deprecated.

s/does/doesn't/ there.

"These days RSA is only used in digital signatures (which are not encryption)"

AFAIK digital signatures are created by encrypting the hash of the plaintext (be it content ofthe certificate or a message or whatnot). But yeah, RSA isn't really used for key exchanges due to it lacking forward secrecy. There are exceptions to this unfortunately, such as Apple's iMessage which is decades behind in cryptographic innovation.

Please don't repeat terrible 90s pedagogy about RSA. Even in RSA, the padding for signatures and for encryption is different (for very important reasons). The fact that RSA encryption and RSA signatures share code (but are not identical) is just a quirk of RSA that instead of making the thing simpler to explain made it harder to explain well - people think this generalizes and try to understand where is the encryption in Ed25519 or whatever and are very confused.

If you want to point out the difference between "public key operation" (encrypt, verify) and "private key operation" (decrypt, sign), use those terms. That makes sense and the distinction is important.

People end up with basically misinformation in their heads and other people on stackoverflow (and IRL) spend lots of time trying to sort them out. You just made the problem a little worse. Please don't do that.

Here is an actual cryptographer explaining: https://security.stackexchange.com/a/87373/70830

No AFAIK. The actual traffic is encrypted using a block cipher. Asymmetric crypto is only there to verify each peer's identity and establish a common secret for the symmetric cipher.

This is right - asymmetric crypto is awesome but just not anywhere near as fast as something like AES for chewing through chunks of data. So some anonymous asymmetric crypto (Diffie-Hellman or similar) is used to set up an encrypted channel, i.e set up a shared AES key, and then RSA is used to verify that the entity on the other end actually holds the private key for that subdomain. After that it’s AES pretty much all the way.

Yup that’s basically how it works. Usually when PFS is involved the keys are session based as opposed to using the same keypair for every session. This mitigates passive monitoring and future private key compromise/legal pressure permitting historic decryption of sniffed TLS sessions.

They use a form of key exchange (using RSA, Diffie-Hellman etc) to transfer the (symmetric) key used by the symmetric block cipher. So typically ECDHE and AES-256-GCM for e.g. so the symmetric key is wrapped.

Reply on news.ycombinator.com