Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How RSA Works: TLS Foundations

fly.io

Post reply on HN
Print view View original

11–20 of 38 posts

Re: How RSA Works: TLS Foundations

#11

Post by matahwoosh »

kss238 wrote: post #2

Can someone explain this section some more >Considering that we need a distinct key for each individual, that exchanging keys with each person would be a significant computational burden, and that there are more cryptographic functions needed than simply exchanging keys, new methods arose. Isn't this exactly what RSA does, exchanging a private symmetric key with asymmetric crypto? The next paragraph makes it seem lik…

you can also use RSA for actual encryption (like PGP) or for signing/verifying. ECDHE is better for key exchange, and ECDSA is better for signing/verifying. Check out goodroot's link!

Re: How RSA Works: TLS Foundations

#12

Post by manigandham »

AngeloAnolin wrote: post #3

Noticed that this page worked on Chrome, but not on FF. On FF (57.0.2) Windows 7, the message is as below: Error 1010 Ray ID: 3cc3b2b85d0b9300 • 2017-12-12 21:15:17 UTC Access denied What happened? The owner of this website (fly-io.ghost.io) has banned your access based on your browser's signature (3cc3b2b85d0b9300-ua48). Not sure if the author or website owner had a beef with FF.

Try it without the "?twitter" querystring which looks to be cached: https://fly.io/articles/how-rsa-works-tls-foundations/

Re: How RSA Works: TLS Foundations

#13

Post by blattimwind »

matahwoosh wrote: post #11
kss238 wrote: post #2

Can someone explain this section some more >Considering that we need a distinct key for each individual, that exchanging keys with each person would be a significant computational burden, and that there are more cryptographic functions needed than simply exchanging keys, new methods arose. Isn't this exactly what RSA does, exchanging a private symmetric key with asymmetric crypto? The next paragraph makes it seem lik…

you can also use RSA for actual encryption (like PGP) or for signing/verifying. ECDHE is better for key exchange, and ECDSA is better for signing/verifying. Check out goodroot's link!

RSA encryption has been shown time and time again to be a really bad idea, to the point that it was removed from TLS 1.3 early on.

Re: How RSA Works: TLS Foundations

#14

Post by matahwoosh »

blattimwind wrote: post #13
matahwoosh wrote: post #11

Earlier quoted context omitted.

you can also use RSA for actual encryption (like PGP) or for signing/verifying. ECDHE is better for key exchange, and ECDSA is better for signing/verifying. Check out goodroot's link!

RSA encryption has been shown time and time again to be a really bad idea, to the point that it was removed from TLS 1.3 early on.

what encryption are you talking about? IIRC, RSA has only been used for key exchange or authentication (sign/verify) in SSL/TLS. Even in the old days up to SSL 3.0, RC4 or (3)DES was used for actual (symmetrical) encryption.

Re: How RSA Works: TLS Foundations

#15

Post by mabbo »

I find the description of the RSA math pretty confusing. And I'm saying that with a minor in math and a CS degree specializing in security; I've don't this before, just not in a while.

For example:

>In order to generate e, we'll need to find a random prime number that has a greatest common divisor (GCD) of 1 in relation to ϕ(n).

How can a prime number have any divisor that isn't 1, let alone a gcd? Either that's mistaken, or it's unnecessary to state.

There's also no explanation of what purpose the totient value is. The author simply states it's needed, but not what value it provides.

In short, it feels like it's written for people who already know the answers, not for people trying to learn.

Re: How RSA Works: TLS Foundations

#16

Post by tptacek »

matahwoosh wrote: post #14
blattimwind wrote: post #13

Earlier quoted context omitted.

RSA encryption has been shown time and time again to be a really bad idea, to the point that it was removed from TLS 1.3 early on.

what encryption are you talking about? IIRC, RSA has only been used for key exchange or authentication (sign/verify) in SSL/TLS. Even in the old days up to SSL 3.0, RC4 or (3)DES was used for actual (symmetrical) encryption.

RSA is a bad idea in key exchanges as well.

Re: How RSA Works: TLS Foundations

#17

Post by bogomipz »

goodroot wrote: post #8
kss238 wrote: post #2

Can someone explain this section some more >Considering that we need a distinct key for each individual, that exchanging keys with each person would be a significant computational burden, and that there are more cryptographic functions needed than simply exchanging keys, new methods arose. Isn't this exactly what RSA does, exchanging a private symmetric key with asymmetric crypto? The next paragraph makes it seem lik…

Most excellent question, kss238. The next part in the series, which breaks apart the different parts of a TLS ciphersuite, was just published: http://fly.io/articles/how-ciphersuites-work/ It should answer your question, in similar spirits to that of this article. Thank you for reading and I wish you well.

What is the rest of the context of the Golang code snippet in that that link?

Re: How RSA Works: TLS Foundations

#18

Post by matahwoosh »

tptacek wrote: post #16
matahwoosh wrote: post #14

Earlier quoted context omitted.

what encryption are you talking about? IIRC, RSA has only been used for key exchange or authentication (sign/verify) in SSL/TLS. Even in the old days up to SSL 3.0, RC4 or (3)DES was used for actual (symmetrical) encryption.

RSA is a bad idea in key exchanges as well.

tptacek: I think this sub-thread has been mainly to explain what RSA could be used for, not that it would be a good idea. On the side note, I have been positively surprised to see how many devices support ECDHE key exchange.

Also, do you have a good resource that explains the drawbacks of RSA key exchange in more details?

Re: How RSA Works: TLS Foundations

#19

Post by wolf550e »

matahwoosh wrote: post #14
blattimwind wrote: post #13

Earlier quoted context omitted.

RSA encryption has been shown time and time again to be a really bad idea, to the point that it was removed from TLS 1.3 early on.

what encryption are you talking about? IIRC, RSA has only been used for key exchange or authentication (sign/verify) in SSL/TLS. Even in the old days up to SSL 3.0, RC4 or (3)DES was used for actual (symmetrical) encryption.

SSL and TLS before 1.3 had a key exchange mode that used RSA encryption, without any DH, DHE, ECDHE, etc [1]. The client would generate a secret, encrypt it to the server's public key (from the certificate) and send that to the server. The server would decrypt it, compute shared secret key and continue.

Being able to decrypt was used to prove server has the private key for the certificate, instead of signature.

RSA was was thus used for both key agreement and authentication.

This of course has the problem of all recorded traffic can be decrypted after you get your hands on the certificate's private key, maybe after the certificate has expired and admins think the key is worthless.

This was known to be a bad idea and was removed from TLS 1.3. Some banks complained, they were told to escrow using ECDHE instead if they had to make the traffic decryptable by someone with a key for some reason.

1 - https://tools.ietf.org/html/rfc5246#section-8.1.1

Re: How RSA Works: TLS Foundations

#20

Post by matahwoosh »

bogomipz wrote: post #17
goodroot wrote: post #8

Earlier quoted context omitted.

Most excellent question, kss238. The next part in the series, which breaks apart the different parts of a TLS ciphersuite, was just published: http://fly.io/articles/how-ciphersuites-work/ It should answer your question, in similar spirits to that of this article. Thank you for reading and I wish you well.

What is the rest of the context of the Golang code snippet in that that link?

It's most likely to be Fly-specific, but you could replicate this behavior with passing appropriate to tls.Config#GetCertificate (https://golang.org/pkg/crypto/tls/#Config). You could then have something like that :

  GetCertificate: func(helloInfo *tls.ClientHelloInfo) (*tls.Certificate, error) {
  	return myGetCertificateImplementation(checkClientSupportForECDSA(helloInfo))
  }
You would see what curves/ciphersuites are supported by the client and check that against what you'd be supporting (if you use LE than that's more than likely going to be ECDSA with P-256). You would then return ECDSA cert (if one exist) for supporting clients and fallback to RSA certs. :boom: :D
Post reply on HN