4 ms·
The problem is that RSA is also used for most certificates, including signing certificates. This attack also implicates digital signatures. While we've made goo
by matthewdgreen 11y ago
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.
- tptacek 11y agoRSA 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.
- davidamarquis 11y agoWhat are the arguments against RSA OAEP?
- tptacek 11y agoPublic 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).
- deleted 11y ago[deleted]
- pbsd 11y agoEven 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 https://eprint.iacr.org/2016/085
- dadrian 11y agoWhy 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.
- tptacek 11y agoBecause 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.
- Nimi 11y agoMoving 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.
- Gibbon1 11y agoI 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.
- Nimi 11y agoThat's very interesting, do you happen to have a link for the blog post?
- Natanael_L 11y agoProbably this https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc9bb089#.626z71jce https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc...
- Gibbon1 11y agoThanks 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.
- 11y ago