Hacker News Reader

Comment by matthewdgreen | Hacker News Reader

The problem is that RSA is also used for most certificates, including signing certificates. This attack also implicates digital signatures. While we've made good progress shifting towards DH/ECDH ciphersuites -- and TLS v1.3 will eliminate RSA entirely -- we have essentially no deployment of DSA/ECDSA certificates. It's all RSA. So "getting rid of RSA" sounds good, but won't happen in TLS/SSL anytime soon.

Moreover, if we can't get rid of export ciphersuites after twenty years, what is the probability that we'll manage to get rid of RSA in just a few? I'm not that optimistic.

There would be very little problem with RSA in TLS if people had moved to modern schemes like OAEP and RSA-PSS. The problem is that we didn't, and we're stuck with obsolete crap. Moving away from obsolete crap isn't the solution, it's the definition of the problem.

View on HN

Moving away from obsolete crap isn't the solution, it's the definition of the problem.

One could argue that the CA/Browser forum has achieved some success with moving away from SHA-1. As a spectator, I don't understand why this process is not repeated for similar obsolete primitives or standards.

I read an blog post by a guy with a long experience with this. What happens is large players demand that there be a 'reasonable' deadline for compliance. And then half the companies involved sit on their hands for two and a half years and then demand an extension. And then another and next thing you know you're still using RSA fifteen years after people knew they needed to stop using it.

Only solution I can think of is to create some sort of license where once the sunset deadline is established, the license to use it expires hard on the deadline.

That's very interesting, do you happen to have a link for the blog post?

Probably this https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc...

Thanks that would be the one. I get this feeling that encryption protocols and standards often end up and all sorts of dank corners of the web infrastructure and finding and updating all of these is really messy task. And I suspect service providers and their customers haven't been really good at keeping track of everything.

Fascinating. I still feel I'm missing something basic here: If Microsoft, Google and Mozilla announce they're not going to accept any particular crypto primitive two years from now, and this time there won't be any exceptions, CAs and websites just have to abide, don't they?

Then a bunch of big companies announce they'll use another browser to be able to keep using it

Another browser beside Chrome, Firefox and IE? OK, so Symantec announces that they will only use Opera. Even then, they have to deal with their customers, website operators who need a certificate trusted by the big 3 browsers, leaving. In fact, now that Let's Encrypt certificates are free, it seems like this is the Symantec CA's worst nightmare.

Not CA:s, but clients like banks

The browsers say what they accept, the server says what it provides and something in the intersecting set will be used.

If (as a random example that didn't annoy me at all for 2 years) a website also needs to support SmartTV devices which only accept obsolete certificates then your server has to either break them or not.

RSA OAEP and PSS is just as unlikely to win the Internet as ECDH and curve signatures. But if you had to pick one to win, you'd pick curves.

What are the arguments against RSA OAEP?

Public key encryption transforms are one of the biggest foot-guns in cryptography. OAEP is at least not prima facie broken, but using it still exposes you to the the design risks of building with public key encryption.

(There are attacks against OAEP, but they're less common and not intrinsic to the design the way PKCS1v15's are).

Even if RSA does go away, and it will, public-key encryption primitives won't. The post-quantum craze is mostly made up of encryption and signature primitives, so we have that to look forward to. Even the lattice-based key agreement we have is basically fancy KEM, which leads to things like [1].

My impression is that RSA never really got the "djb treatment". The people designing OAEP and friends were mostly theorists concerned with security reductions, not implementation issues. I think an idiot-proof RSA scheme could be devised, but it is now way too late for that.

[1] https://eprint.iacr.org/2016/085

Why argue about which battle to fight, and try to do both? Get widespread support for ECDSA; get RSA implementations up to date with modern padding schemes. We don't need to pick and choose which modern crypto to use; use modern crypto everywhere.

Obviously upgrading old clients is hard, but that's going to be a problem regardless. So in new standards that need RSA (e.g. something where the private key needs to be able to encrypt and sign), push for OEAP. If they don't need RSA, push for modern curves.

Because even if you use OAEP, RSA is more error-prone --- particularly at a design level --- than curve cryptosystems and, for most applications, doesn't allow you to express anything you couldn't express better with curves.

Reply on news.ycombinator.com