3 ms·

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 j

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

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