Hacker News Reader

Comment by SheinhardtWigCo | Hacker News Reader

This post ignores the fact that most users of RSA do not have to worry about these low-level implementation issues because they are using mature and well-vetted implementations.

Also, this part in particular displays an alarming lack of nuance:

> if you come to us with a codebase that uses RSA, you will be paying for the hour of time required for us to explain why you should stop using it.

View on HN

The point of the article is that mature and well-vetted libraries have repeatedly been shown to have vulnerabilities in their RSA implementations. See [1] for just one recent example, but there have been many.

[1]: https://www.cryptologie.net/article/461/the-9-lives-of-bleic...

So the solution to a proven algo plus mature implementation with some issues is to... switch to a green algo with a green implementation?

Switch to other proven and mature algorithms eg libsodium, Tink, etc. RSA has not been the only game in town for a long time.

The point is that the alternatives aren't "green" and their implementations are mature, arguably even better understood than RSA and its implementations.

There are many other algorithms that are just as proven but don't feature many of the traps contained in RSA. The main issue with RSA is that depending on implementation and context-sensitive parameter selection (i.e. you actually have to think about them and can't just always use the same) you get wildly different results. Other algorithms, like ECC, also have parameters, but they aren't context-sensitive, so always choosing the same one is fine for developers and only security researchers have to think of new and better parameters. The Question really is how brittle do you expect/accept your encryption algorithm to be: RSA is very brittle in very unexpected ways, while e.g. ECC is only brittle if you choose a bad curve (but you can simply always select the same safe one) and people also know that.

ECC also depends on good RNG for computing signatures. RSA needs it only at key creation time.

This is not necessarily true - deterministic EC signatures are now recommended, eg EdDSA or [1] for ECDSA. (To prevent some side-channel attacks you might want to reintroduce some randomness).

On the other hand, it’s now recommended to use PSS padding with RSA, which requires a random value for each signature.

[1]: https://tools.ietf.org/html/rfc6979

It's not enough to have a well-vetted implementation. You also have to use RSA safely, and there are pitfalls to using it right that ECC algorithms don't have.

So, sure, use RSA certs for your TLS connections, and I guess, fine, use RSA SSH keys,

But don't add RSA to new designs where it doesn't have to be there.

What,s the proposed alternative with at least 20 years maturity?

ECDH and ECC signing systems (simpler answer, and the one everyone means when we talk about this stuff: libsodium). The "20 years maturity" thing is funny, because it's a line from 10-15 years ago that has now aged out. In reality, it was always a shorthand for "don't adopt systems you read about on sci.crypt", which, obviously, modern curves aren't.

>10-15 years ago

Was there a publicly available RSA implementation (even a commercial one) that was 20 years old 15 years ago?

It,s not a ,,line,, it,s a general standard I apply to any software I build on.

The author's experience seems to be contrary to what you are saying about users and/or implementations. I don't know who to believe, but I'm not going to automatically believe you.

> alarming lack of nuance

What's the nuance you see that they don't?

The fact that many systems have no control over all parties to make such a change.

Reply on news.ycombinator.com