4 ms·

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

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.

nmadden 6y ago
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-bleichenbachers-cat-new-cache-attacks-on-tls-implementations/ https://www.cryptologie.net/article/461/the-9-lives-of-bleic...
- forgotmypw17 6y ago
  So the solution to a proven algo plus mature implementation with some issues is to... switch to a green algo with a green implementation?
  - nmadden 6y ago
    Switch to other proven and mature algorithms eg libsodium, Tink, etc. RSA has not been the only game in town for a long time.
  - lmns 6y ago
    The point is that the alternatives aren't "green" and their implementations are mature, arguably even better understood than RSA and its implementations.
  - mattalex 6y ago
    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.
    - rini17 6y ago
      ECC also depends on good RNG for computing signatures. RSA needs it only at key creation time.
      - nmadden 6y ago
        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 https://tools.ietf.org/html/rfc6979
TwoBit 6y ago
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.
neolog 6y ago
> alarming lack of nuance What's the nuance you see that they don't?
- kortilla 6y ago
  The fact that many systems have no control over all parties to make such a change.
tptacek 6y ago
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.
- forgotmypw17 6y ago
  What,s the proposed alternative with at least 20 years maturity?
  - tptacek 6y ago
    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.
    - swiley 6y ago
      >10-15 years ago Was there a publicly available RSA implementation (even a commercial one) that was 20 years old 15 years ago?
    - forgotmypw17 6y ago
      It,s not a ,,line,, it,s a general standard I apply to any software I build on.

nmadden 6y ago

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-bleichenbachers-cat-new-cache-attacks-on-tls-implementations/ https://www.cryptologie.net/article/461/the-9-lives-of-bleic...

forgotmypw17 6y ago
So the solution to a proven algo plus mature implementation with some issues is to... switch to a green algo with a green implementation?
- nmadden 6y ago
  Switch to other proven and mature algorithms eg libsodium, Tink, etc. RSA has not been the only game in town for a long time.
- lmns 6y ago
  The point is that the alternatives aren't "green" and their implementations are mature, arguably even better understood than RSA and its implementations.
- mattalex 6y ago
  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.
  - rini17 6y ago
    ECC also depends on good RNG for computing signatures. RSA needs it only at key creation time.
    - nmadden 6y ago
      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 https://tools.ietf.org/html/rfc6979

TwoBit 6y ago

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.

neolog 6y ago

> alarming lack of nuance What's the nuance you see that they don't?

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

tptacek 6y ago

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.

forgotmypw17 6y ago
What,s the proposed alternative with at least 20 years maturity?
- tptacek 6y ago
  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.
  - swiley 6y ago
    >10-15 years ago Was there a publicly available RSA implementation (even a commercial one) that was 20 years old 15 years ago?
  - forgotmypw17 6y ago
    It,s not a ,,line,, it,s a general standard I apply to any software I build on.