Hacker News Reader

Comment by jesseryoung | Hacker News Reader

Note: I am not a cryptographer nor a security developer but I am fascinated by security and crypto.

I was all onboard with this articles premise, that good crypto is hard to understand and RSA requires you to make choices about crypto that can easily you screw things up.

Then I read the "So what should you use instead?" section: > "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."

Is this not exactly the authors complaint about RSA? Granted there's fewer places to screw up, but still, you're required to specify a parameter that most developers typically don't understand the ramifications of.

View on HN

The article also tells you to use libsodium, which makes safe cryptographic choices.

(It's absolutely true that ECC can be as much of a footgun, e.g. non-random-k ECDSA is worse than RSA PKCSv15. But the real takeaway is to use something that's already set for security, like libsodium.)

Well, yes, but that's why we have ed25519 and such. ECDSA is a footgun.

From my understanding and maybe I'm wrong here, he means that they tend to not roll their own ECC implementations.

From the video, one of his major complaints is that people learn RSA in their first year of university, understand the math, then roll their own. How hard can it be, its modulo and exponents. People don't tend to do this with ECC. They just pick a library.

You are right in saying that the same roll your own problems that occur with RSA would occur with ECC.

This article doesn't mention openssl or ssh-keygen. Are the standard commands we see in most articles for creating keys via these two popular tools compromised in any way?

I never roll my own encryption, and most developers don't (unless they're just playing with stuff and learning how to understand it; and not use it in production). I stick to standard tools and libraries like Legion of the Bouncy Castle and pypi RSA.

I wish this article covered the way most developers interact with RSA libraries and showing us those specific problems.

Some keygen is busted, but openssl RSA (as well as ssh-keygen) are probably fine. Part of the problem there is "probably": turns out RSA keygen is a lot harder than ECC keygen. (Since ROCA broke a bunch of RSA keygen, our confidence in e.g. openssl's keygen is increased.)

Using standard tools like PyPI RSA, however, does not necessarily save you. Not only will openssl's RSA happily generate a bad key for you if you ask it nicely, Because it's pure Python, there's a good chance it's vulnerable to side channel attacks. Also, it uses PKCSv15 padding for encryption, and is therefore definitely vulnerable to the Bleichenbacher attack mentioned in the article, for example.

Just use libsodium's box.

If you're on Python and you for some weird reason absolutely have to use RSA, make sure to use RSA-OAEP and the pyca/cryptography library: https://cryptography.io/en/latest/hazmat/primitives/asymmetr...

sybrenstuvel/python-rsa/ is PKCSv1.5 which like lvh said, is not secure.

RSA is fundamentally less secure than Diffie-Hellman as it lacks forward secrecy. So even a perfect implementation is still less secure.

I read that "developers" to mean those people who develop the algorithms also. For example Bernstein et al, who made ed25519 and its implementation.

Reply on news.ycombinator.com