Hacker News Reader

Comment by armchairhacker | Hacker News Reader

“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.

View on HN

Maybe 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.

What 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.

The 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'.

Two of the images in the article is https://i0.wp.com/blog.trailofbits.com/wp-content/uploads/20...

And

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.

The 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.

I 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.

This 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.

Reply on news.ycombinator.com