It doesn't need to tell you anything new about prime number factorization because practical RSA cryptosystems get broken with far more boring bugs than prime number factorization. RSA padding bugs aren't really "coding errors": RSA padding is just as critical to RSA security as the hardness of number factoring.

Furthermore, they don't just tell you to use some random curve thing: they tell you to use a specific implementation with knobs twiddled for security. You could work hard to maybe get everything right, or you can just do this thing and everything will be set for safety for you.

So, to be Devil's Advocate, does libsodium also provide an RSA implementation?

There is no place to use RSA instead of Diffie-Hellman. DH provides forward secrecy, and the ECC variants are much faster and use shorter keys for equivalent security. They are harder to implement in a wrong way.

No. Why would it?

If you only use RSA to sign and not encrypt, then you lose the padding oracle attach and you're left with... a ton of other issues still. But the Bleichenbacher family of attacks is really devastating, so I'd tolerate some RSA digital signature usage. But please, stop using RSA key transport!!

This comment reminds me of a rant I listened to once about implementing bsddb. It went, basically: Everything you need to know to correctly, reliably, use bsddb is somewhere in their documentation. But the chances you have of correctly using the library, without reading, understanding, and remembering every line of that documentation, is basically 0.

Which I guess explains why RedHat had corruption issues with their package database for, what, a few years before they figured it out? If RedHat needs a few years to get it right for a core component of their core product, who can be expected to?

This RSA discussion makes me wonder if it is in the same boat.

Yes, these are implementation specific problems. I think the article wasn't saying "just use ECC instead", it was saying "use ECC instead because it has a widely recognized and standardized implementation path that's proven secure, in contrast to RSA."

The biggest issue he describes is that, when implementing RSA, most of the parameter choices are necessarily private to the developer, meaning the dev is expected to supply good parameters on her own, when "good" means in terms of heavy math that no non-cryptographer can be expected to know. It's not just key size--there's a bunch of bad choices a dev can make, many of which are hard to recognize as bad choices.

Secondarily, many of those bad choices are driven by implementing RSA in constrained environments, where they're a tradeoff to achieve performance goals--so known-good techniques or algorithms are actually rejected.

ECC, by contrast, is almost all public parameters, so the security community can provide (and already has) known-good parameters that are provably secure, and a dev can simply choose a known-good configuration for their implementation to go with a well-regarded library like libsodium.

Are you also saying that an ECC public key necessarily provides those details that may remain private with RSA?

Not op, but that is partially the case. The idea is that in RSA, many of the parameters lie with key-generation. Both in how the private exponent is chosen, and how the primes that form the modulus are chosen. Unless the implementation is totally borked, those choices aren't visible from the key.

Meanwhile with ECC the main choice is which curve to use. This is visible in the public key. Hence, you can just check whether it is a curve that is generally accepted. For picking your private key, you only need a single integer chosen uniformly from a specific range. Whilst that is not totally trivial to do up to cryptographic standards, it is a lot easier than e.g. 'pick a pair of primes at random that meets these requirements.'

The argument is that the interface is too complicated for non-experts to parameterize securely.

Consider the libsodium example: https://libsodium.gitbook.io/doc/public-key_cryptography/aut.... The crypto implementation parameters are handled under the hood.

My takeaway from this article is that the problems are indeed implementation-specific, but that whilst the cryptographically-secure values represent a small subset of the possible values, it's still too large a selection to provide a generalised list of what values are suitable for purposes. They do admit that RSA can be implemented securely in theory, but that the range of possible implementations is so vast that it's incredibly difficult to know if the parameters chosen are vulnerable without a maths degree and some very deep analysis.

On the other hand, those of us who write code that uses crypto are generally beaten about the head with 'NEVER ROLL YOUR OWN CRYPTO' and use library implementations right from the start. These are libraries that I assume are indeed written by people with maths degrees and have done careful analysis of the outputs. I know for a fact that I wouldn't trust any encryption I could write myself in an hour.

The biggest obstacle I find with ECC is that it's relatively easy to judge security by RSA (assuming correct implementation) but it's surprisingly difficult to compare the two; if I want RSA-2048, what key size am I supposed to use. ECC was also heavily promoted as offering 'RSA-equivalent security' while using less CPU, which made it particularly suitable for mobile/embedded systems, without necessarily implying it was an improvement over RSA.

> I know for a fact that I wouldn't trust any encryption I could write myself in an hour.

That's what I would trust the most. Not that such a thing actually exists (Chacha20 is one of the closest), but if I can implement it quickly in an hour, and it is vetted by the community, then peer reviewed implementation like Libsodium are much more likely to be correct.

> The biggest obstacle I find with ECC is that it's relatively easy to judge security by RSA (assuming correct implementation) but it's surprisingly difficult to compare the two;

Then don't. Compare them with hashes instead. Oversimplifying things a bit, breaking a curve of a given size is about as hard as finding a collision of a hash of a similar size. So, Curve25519, which uses about 255 bits, is about as secure as Blake2b/256, or HMAC-SHA256. That is, about 128 bits of security.

Note however that this is more secure (without quantum crypto) than 128-bit ciphers like AES-128, because hash collisions and elliptic curves aren't as vulnerable to multi key attacks, and success rates drop faster when you try to be lucky with less computational resources than you should have used.

> these are all implementation specific problems

And ECC isn't always implemented (or even standardized) securely (https://cr.yp.to/newelliptic/nistecc-20160106.pdf) either.

Since 2013, not 2005.