11 ms·
Seriously, Stop Using RSA (2019)
- armchairhacker 5y ago“RSA is bad because developers often don’t implement it correctly, leading to vulnerabilities. Instead, use ECC, which can also be implemented incorrectly, but developers tend to do this less.” The article raises some good points, but it really explains why you shouldn’t use your own RSA or an unaudited third-party library. A good RSA implementation which has been audited by security experts and doesn’t take shortcuts for performance would alleviate the OP’s concerns.
- rakoo 5y agoWhat is important is more a library where the easiest thing to do is correct, and making it really hard to make mistakes. Make the encrypt/decrypt function the only public api, with as few args as possible. Manage IVs under the hood so the user can't accidentally reuse them. That's the approach taken by NaCl, and arguably the only one worth considering.
- pvg 5y agoThe article doesn't say what your paraphrase says, though, and even less of what your next sentence says. The various RSA implementations with serious problems it brings up weren't all 'own RSA or unaudited third party library'.
- prophesi 5y agoTwo of the images in the article is https://i0.wp.com/blog.trailofbits.com/wp-content/uploads/2019/07/image13-1.png?resize=500%2C485&ssl=1 https://i0.wp.com/blog.trailofbits.com/wp-content/uploads/20... And https://i0.wp.com/blog.trailofbits.com/wp-content/uploads/2019/07/image14.jpg?resize=523%2C500&ssl=1 https://i0.wp.com/blog.trailofbits.com/wp-content/uploads/20... So it sounds like the main pain-point is improper implementation. Though the padding oracle attack is convincing to use something else, as it's necessary to pad yet still opens up to a different attack vector.
- pvg 5y agoThe article mentions various RSA implementations that have had problems. The other thing is, since they do audits and are telling you to avoid RSA, the advice obviously isn't 'a properly audited RSA is fine'. "it's actually ok to use RSA" is not a reasonable conclusion to draw from this piece.
- prophesi 5y agoI think the crux of the argument is summed up here: > Developers could theoretically build an ECC implementation with terrible parameters and fail to check for things like invalid curve points, but they tend to not do this. So, it's just about trusting developers to implement a different algorithm properly.
- jandrese 5y agoMaybe the article should say "use the security library that has the best developer documentation, as that gives the best chances of it working correctly." I'm not sure why, but documentation on crypto libraries tends to be noticeably worse than the documentation for any other library, pretty much assuming that the coder has already written their PhD thesis on implementing a cryptographically secure system and doesn't need the documentation to explain what anything is. And thus you have an endless stream of products that screw up setting the IV, because there was literally no guidance anywhere in the library about how you should handle it. Even big companies are made up of individual people and not everybody has the time to take graduate level courses on every single thing they're building before they build it. Having the library audited for correctness is of no help when the majority of problems arise from just using it wrong because the documentation was incomplete, vague, or even outright wrong/out of date.
- deleted 5y ago[deleted]
- NateLawson 5y agoThis article is a good list of implementation flaws with RSA, both in parameter selection and protocols. However, I disagree with the recommendation to use ECIES. It has a separate MAC and encryption algorithm approach which is better served by AEAD algorithms these days.
- frostburg 5y agoThis is all true, but reads funny to me because I've implemented an intentionally vulnerable version of RSA and still had issues getting timing attacks to work on modern hardware (due to lack of sophistication in my approach, I think).
- spicybright 5y agoThat actually sounds like a very enlightening exercise! How did you go about doing this? Did you just follow an RSA spec from somewhere?
- frostburg 5y agoI mostly followed lecture notes on the subject and a few papers on issues like prime checking.
- EarlKing 5y ago
- spicybright 5y agoUnless you're really good at auditing code, why wouldn't you want to use something stronger? Memory managed languages are generally preferred for a lot of software because it's much harder to introduce memory leaks accidentally vs in something like C. Yes, C is fine, but if your goal is no memory leaks, you could be doing a lot better. I don't get why anyone would die on this hill over something as important as encryption. It's like using skeleton keys for your house door, because why would you be careless enough to not know when an intruder walks in?
- erdos4d 5y ago> and the NSA doesn't like you using it. This is the best endorsement a crypto algorithm could have honestly.
- upofadown 5y agoHere is a nice discussion of what happens when you don't validate your elliptic curve parameters properly: * https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-elliptic-curve-cryptography-validation/ https://research.nccgroup.com/2021/11/18/an-illustrated-guid... The highlight here is that in some cases, failure to properly validate gets an attacker the secret key material. Note all the conditional bits. Different curves have different properties and different issues. There are a bunch of different curves in common use while RSA pretty much always uses the same value for the parameter these days (RSA literally has just one parameter. The exponent.).
- gotaquestion 5y agoWhy would someone create their own parameters for deployment and not strictly research? There are plenty curves studied by academic experts out there that aren't even NIST.
- Banana699 5y agoThe article discusses this, the difference is that ECC parameters can be chosen before library-development time by expert cryptographers, all the developers have to do when actually developing the library is to generate random bits. The obviously complex mathematics of EC intimidate the non-experts away from trying to roll their own implementation and push them towards the most trusted expert implementation, while the false superficial simplicity of RSA seduce non-experts into greenspunning own implementations or using a greenspunned implementation without too much thought. >RSA literally has just one parameter. The exponent. How so? the 2 most important parameters are p and q, which have so many caveats and constraints on them that you lose track of them by the midpoint of the article, and you have to generate them privately so you can't offload this to non-affiliated cryptographers.
- upofadown 5y ago>The obviously complex mathematics of EC intimidate the non-experts away from trying to roll their own implementation and push them towards the most trusted expert implementation... My experience is that programmers are not so easily intimidated. If anything, complexity is an attractant...
- gleenn 5y agoIs there any new concern that Curve25519 has been backdoored by the NSA? It looks like P-256 did a long time ago, and reading the Wikipedia article doesn't give that impression, wanted to check though.
- JCBird1012 5y agoA backdoor in Curve25519 hasn’t really been a concern, because unlike P-256, the parameters for the curve didn’t come from NIST. Curve25519 is a djb (https://en.wikipedia.org/wiki/Daniel_J._Bernstein https://en.wikipedia.org/wiki/Daniel_J._Bernstein) special. So unless djb was secretly working with the NSA and willing to risk his reputation to backdoor a highly scrutinized elliptic curve, the risk is low.
- sudosysgen 5y agoThe issue is that RSA isn't backdorable, while elliptic curves are. Even if we trust the author, it's better not to trust anyone.
- a1369209993 5y agoMore importantly (because that's definitely something the NSA would try to do), curve25519 has fewer degrees of freedom to hide a backdoor in than P-256; 2^255-19 is the largest uint255 that's prime, and the other parameters (mostly the coefficent A=486662) were chosen by a similar "first value that satisified the security requirements" process - there's a paper by DJB explaining the parameter selection rationale around somewhere[0], although they could definitely stand to be more conspicuous about it. 0: The value of A is (poorly) explained in passing in https://cr.yp.to/ecdh/curve25519-20060209.pdf https://cr.yp.to/ecdh/curve25519-20060209.pdf under heading "Why this curve?", but that doesn't explain any details for someone who's not a cryptographer.
- marcosdumay 5y agoI believe that the thing is more that DJB created that huge paper about how to create a curve so that everybody can know it's not backdoored, with advice that appears to be almost unanimous, and created Curve25519 by following it. It's not a matter of trusting him, instead, it's a matter of using the algorithm that requires less trust of them all (including RSA).
- YATA0 5y ago
- spicybright 5y agoNot sure what the joke is here.
- YATA0 5y agoThere is no joke? Stop implementing your own crypto. Vault has transit encryption out of the box, among other things. "The transit secrets engine handles cryptographic functions on data in-transit. Vault doesn't store the data sent to the secrets engine. It can also be viewed as "cryptography as a service" or "encryption as a service". The transit secrets engine can also sign and verify data; generate hashes and HMACs of data; and act as a source of random bytes."[0] [0] https://www.vaultproject.io/docs/secrets/transit https://www.vaultproject.io/docs/secrets/transit
- spicybright 5y agoOh. I thought it was because there are at least a dozen ways to securely encrypt/decrypt data, most of which are audited. Skimming their site they seem to offer some sort of encryption + service hosting? I don't see how this is much different than any of the other options out there. And not really an equivalent to using RSA as it looks to be tied to their hosting. I also tend to not trust for profit companies with things like this (esp. if it's closed source or I can't know what the servers actually run). Has this service been audited? Has it withstood against the US court system like veracrypt has multiple times? Do their founders have any history that goes against good data security? Your post sounds like an ad if I'm being honest.
- YATA0 5y ago> I thought it was because there are at least a dozen ways to securely encrypt/decrypt data, most of which are audited. Any yet people still implement on top of and leverage those lower-level libraries poorly. >Skimming their site they seem to offer some sort of encryption + service hosting? I believe they have a hosted SaaS solution now, but Vault is FOSS: https://github.com/hashicorp/vault https://github.com/hashicorp/vault >I don't see how this is much different than any of the other options out there. Vault manages your application-level encryption so you don't have to. That's a lot different than most of the options out there. >And not really an equivalent to using RSA as it looks to be tied to their hosting. It's not tied to their hosting. Spin it up on some VMs or a kubernetes cluster. >I also tend to not trust for profit companies with things like this (esp. if it's closed source or I can't know what the servers actually run). It's open source and HashiCorp... That's like saying you don't trust Linux with things like this because of RedHat. >Has this service been audited? Yes. >Has it withstood against the US court system like veracrypt has multiple times? Yes. >Do their founders have any history that goes against good data security? How do you not know who HashiCorp is? >Your post sounds like an ad if I'm being honest. Nope, just a happy user.
- cammikebrown 5y agoDoes OpenPGP use RSA?
- upofadown 5y agoYou get RSA by default with GnuPG. Since the signature method embodies your PGP identity you want to pick the method with the widest implementation. RSA is supported by TLS 1.3 for roughly the same reason. There are add on standards for various curves available for PGP should you want to mess around with them. GnuPG implements them all. Other implementations do not. Note that the encryption issues associated with an offline compatible system such as OpenPGP are different than online connected systems like TLS. The article was mostly talking about the sort of issues that crop up with an online connected system.
- sivizius 5y agoRSA is bad, because developers do not implement it as specified and ECC is good, because most developers will not implement it themself, because they do not understand ECC and therefor use libraries? IMHO a huge advantage of RSA over ECC is it is easy to explain. After you have explained the different kinds of elliptic curves and their pitfalls, you have to explain the integrated encryption scheme to actually use it for encryption. But ok, you want hybrid encryption with RSA too, but in theory, you do not have to.
- not2b 5y agoThe article's argument is that because RSA is easy to explain, developers are more likely to roll their own and do it wrong. But that's mainly an argument against "roll your own", for those who aren't expert or aren't willing to take the time to learn all the pitfalls.
- danenania 5y agoEnvKey[1] moved from OpenPGP (RSA) to NaCl[2] for its v2, which recently launched. It’s causing a difficult migration for our v1 users. Moving to a new encryption scheme is not fun for a product with client-side end-to-end encryption. But within a year or so of releasing the v1, it seemed like the writing was on the wall for OpenPGP and RSA. I didn't want to go down with a dying standard. NaCl is so much better. In spite of the migration headaches that will likely cost us some users, I'm very happy I made this decision. It's so much faster, lighter, and more intuitive. It’s legitimately fun to work with, which I never thought I’d say about an encryption library after cutting my teeth on OpenPGP. 1 - https://github.com/envkey/envkey https://github.com/envkey/envkey 2 - https://nacl.cr.yp.to https://nacl.cr.yp.to
- jossclimb 5y agoWhat was your reason for developing the project in typescript? Looks like an interesting choice for a CLI / key mgmt system.
- danenania 5y agoIt has a thick UI layer in React (which I wouldn’t want to write in anything else), and it’s crucial to be able to share types and functions across the whole stack, as it’s designed in a way where a lot is shared. That’s the main reason.
- marcus_cemes 5y agoI'm not familiar with NaCl, websites that don't seem to have been updated in 7 years (version states 2016?) make me a little suspicious about the future viability of said projects. Perhaps it's not something that needs to be updated very frequently, but my knee-jerk reaction is that it looks abandoned, especially considering that they have an "upcomming features" section. What made you choose it? Could PGP/GPG with ed25519 keys not have been sufficient? What makes NaCL "fun to work with"? For me, fun to work with would be Age [1] or Ring [2] with a elegant and well designed API. I'm also aware that the older something is, the more likely it has undergone peer review and security audits, unlike new Rust crypto libraries. [1]: https://github.com/FiloSottile/age https://github.com/FiloSottile/age [2]: https://github.com/briansmith/ring https://github.com/briansmith/ring
- stevenjgarner 5y ago'"Seriously, Stop Using RSA" for Dummies' please! e.g. for a fullstacker who spins up the latest Ubuntu LTS then generates a pair of 4,096-bit RSA keys using default openssh-server set over a high-number TCP port, what should they be doing that is different?
- Chyzwar 5y agoed25519 can be generated as easily as RSA (ssh-keygen -t ed25519). Resulted keys are faster, shorter and possibly more secure than RSA.
- doublepg23 5y agoI attempted to switch to ed25519 OpenSSH keys in 2017 and support was pretty dreadful. Ended going back to rsa4096 just for compatibility :(
- throwaway81523 5y agoArticle is from 2016. It is a good article, but why does it say OAEP is notoriously difficult to implement? OAEP seemed very natural to me, and I "invented" it myself (long after it was well known to others, of course), i.e. the ideas in it weren't complicated. Am I missing something dumb? I do remember hearing that Victor Shoup found some kind of bug in the security proof, but it wasn't something of practical concern.
- gweinberg 5y ago1) Post needs a "2019". 2) Best comment inside was from Philip Zimmermann: "I agree. This is why I switched to El Gamal as the default algorithm for PGP version 5 in the late 1990s."
- deleted 5y ago[deleted]
- kuharich 5y agoPast comments: https://news.ycombinator.com/item?id=20381779 https://news.ycombinator.com/item?id=20381779
- jchook 5y agoSounds like the author would agree it's fine to use RSA, so long as you use an audited library with a well-designed API that makes it easy to do the right thing, and hard to do the wrong thing. This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA? I love libsodium and tend to choose it, but ECC seems far more mysterious to me than RSA. Curve25519 is much newer, has more parameters, and could potentially have a backdoor (like it's precursor, P-256). It also has much smaller, fixed-size keys. RSA by comparison is elegant and simple to understand, with only one parameter. It's been in wide use since the 1970s. You can choose the key size.
- adgjlsfhk1 5y agoComparing key size isn't really meaningful here because the main reason for moving away from RSA is that it needs way bigger keys to achieve the same security.
- d22 5y agoKeep in mind how much stress you would be putting on only having one implementation. In practice sooner or later someone would write another and using a needlessly complex encryption scheme can lead it to having bugs.
- 112233 5y agoOnly key size. And public exponent. And padding algorithm. And prime generation algorithm. Remember what happened with Infineon’s on-device generated keys?
- duskwuff 5y ago> This makes me wonder, if we have an RSA library as good as libsodium, is ECC really a better choice than RSA? Yes, absolutely. Compare the key generation process, for example: RSA: generate two large prime numbers around half the size of your key, then make sure they aren't too close to each other, or share one of the primes with another RSA key someone else generated, or have certain mathematical relations to each other, or... ECC (specifically Curve25519): take 32 bytes of random data, set and clear a couple bits. Boom, done. Performing operations with ECC keys is also significantly faster, and constant-time implementations are much easier to develop and verify.
- deleted 5y ago[deleted]
- kupopuffs 5y agoARe there even any valid reasons for implementing your own ?
- aborsy 5y agoThere is a menu of ECC algorithms out there. We have seen some of them were backdoored, and there are probably more of those. If you aren’t sure which ones are safe, it might be better to use RSA from a standard source (OpenSSL, PGP, SSH etc). Users don’t implement algorithms, and don’t cares if they are hard to program.
- hinkley 5y agoLet this be a lesson to whoever comes next: cute and distinct names for your cryptographic algorithm make it easy to distance yourself from people who create similar algorithms that turn out not to be secure. RSA is fundamentally a trick of modular arithmetic, but it's not called that, so if someone else fucks up their modular arithmetic, it doesn't immediately bring shame and doubt upon RSA. Meanwhile the ECC community is using an algorithm that is basically 'Curve' plus a five digit number. If this name isn't already being openly mocked, it will be at some point in the future. Normal people don't have lists of 'good' and 'bad' numbers in their heads. If Curve#### is found to be bad, then they'll think Curve##### is the one everyone is talking about.
- cantrevealname 5y agoThere's an extremely interesting rebuttal that appears as a comment in the original article. I'm going to quote it below for the benefit of HN readers. /QUOTE Bob, February 28, 2020 at 12:15 KEEP USING RSA! This article is misleading to make it appear that RSA is not secure, but only the only evidence presented is improper implementation. Properly implemented RSA has been proven secure and unbreakable by the NSA with case studies such as Snowden, Lavabit, dark markets, and ECC is much harder to properly implement than RSA. The NSA has been pushing ECC because their quantum chips can break it easily. D-Wave, Google, Alibaba, and others already have quantum chips. The disinformation agents claim that “quantum computers don’t exist” which is true because nobody uses a computer to break crypto, they use specialized custom chips. All ECC (X25519-P521) will be broken by private sector quantum chips before RSA-2048 due to the physical limitations of stabilizing qubits. The people making false claims against RSA are either being paid or they are useful idiots. /END-QUOTE
- willis936 5y agoSounds like tinfoil hat. Afaict RSA is simpler to crack with quantum computers than ECC.
- deadbeeves 5y agoNo, the discrete logarithm problem and the prime factoring problem are very similar and are both solved by Shor's algorithm. I suspect they might actually be equivalent, in a weird way.
- nwallin 5y ago> Afaict RSA is simpler to crack with quantum computers than ECC. RSA requires 2n qubits to crack, ECC requires 6n. Since the normal RSA key is 2048 bits, and the normal ECC key is 256 bits, RSA requires a 4096 qubit quantum computer, and ECC requires a 1536 qubit quantum computer. If you use 4096 bit RSA and 512 bit ECC keys, this becomes 8192 qubits and 3072 qubits respectively. I'm not aware of any ECC curves larger than 512 bits. Ultimately, both are broken in a post-quantum world. However, in the interim-quantum world, where quantum computers exist but are noisy and unreliable, RSA is safer.
- motohagiography 5y agoJust to say, understanding the complexity of the topic they are discussing, this is one of the finest pieces of writing I have ever read. If you can express this issue clearly, you can express anything clearly, imo.
- retrocryptid 5y agomeh. dude seems to be conflating "don't use RSA" with "don't roll your own crypto." If we are to believe Scott Vanstone, ECC has security proofs that RSA doesn't. And I found Scott was a pretty trustworthy guy. So the OP has a point. It's probably easier to mess up RSA then ECC. But it's not easy to not mess up ECC, so maybe the title should have been "for the love of god, don't roll your own crypto." Maybe look at NTRU. It's supposedly quantum resistant, so that's a plus. But for the love of god maybe don't roll your own. I contributed to two and a half commercial implementations of RSA and I still got Bob Baldwin to review my code. Bob was hip-deep in crypto research and knew how to avoid even obscure bugs. I miss Scott and Bob. Also... I'm using the term "Crypto" to mean "Cryptography" and not a solution in search of a problem crypto-currency. Still. Don't roll yer own crypto.
- nullc 5y agoSomeone still had to write it and those people make mistakes too. Don't roll your own can run dangerously close to abstinence only as a solution for teen pregnancy. Certainly there are cases where "don't reinvent the wheel" is useful advice, but there are a great many where it isn't.
- _8j50 5y agoIsn't RSA the best assymmetric crypto system for when you do need that? I mean, I get it for signatures, key exchange and data encryption it should be avoided but what else is there for symmetric key encryption such as how S/MIME uses it for example. I always thought RSA+OAEP with >= 4096 bits was an acceptable way to encrypt symmetric key material for transport. I only know of PGP as the alternative which isn't well supported in many environments (especially commercial).
- loeg 5y agoNo. You can encrypt symmetric keys with literally any other asymmetric crypto system, such as ECC, as mentioned in the article.
- _8j50 5y agoWhere does it say that? I only saw this: > Encryption needs to be done using a protocol called ECIES which combines an elliptic curve key exchange with a symmetric encryption algorithm. kex+symmetric encryption is not the same as actually encrypting the symmetric key for transport. In situations where you need the recipient to decrypt it with only their private key and the symmetric key must be anything other than (EC)DH derived key, this does not work
- MrStonedOne 5y ago
- iofiiiiiiiii 5y agoI have a vague understanding that it is not so easy to encrypt data with ECC as it is with RSA. Is that true? This is one reason I still use RSA. What is the right way to use an ECC public key to encrypt data so only the holder of the private key can decrypt it? (Without any fancy key exchange - just fire and forget, email style)