FWIW, RSA is well known to be difficult to get right because you have to select the primes very carefully, and must take explicit steps to avoid padding oracle attacks[1], and perhaps it's better to avoid it entirely.
FWIW I wrote one of the papers re RSA padding oracle attacks, and I disagree with quite a few bits in this blogpost.
Yeah, there are pitfalls in RSA, but so are there in elliptic curve algorithms. I'm not sure if I'd say RSA has more pitfalls than ECDSA. Ed25519 is better, but so is RSA-OAEP/PSS over PKCS #1.5, where many of the common RSA pitfalls are. Most of the RSA pitfalls are in RSA encryption, which is irrelevant if you only use signatures.
You don't have to select primes very carefully. You can select random numbers, check if they are of the right size and prime, and you're good. What some people tend to do is to select primes in a "smart" way, which this post rightfully points out is problematic (see ROCA). But they also reference the batchgcd issue, which is not really an RSA issue. It is ultimately a bad RNG issue, and the very same issue also caused ECDSA implementations to break (with the same catastrophic "you reveal your private key" result).
Ultimately, I think the big problem here is encryption. A footgun ECC constructions don't have is direct public key encryption; idiomatically, ECC "encryption" is a DH key establishment and then a block/bulk cipher doing the encryption, where RSA exposes a direct encryption transform that people idiomatically use.
It's just also the case that RSA in popular use is virtually never OAEP or PSS, and that this isn't a problem you have with ECC constructions, even if you're not using the most misuse-resistant of them.
It's also kind of a dead letter at this point. The ship has sailed: new designs all use curves, and have for something like a decade now.
(I didn't write a paper on this, but I do believe myself to be the proprietor of the Internet's single largest collection of Bleichenbacher padding oracle exploits, in every conceivable language, so there's my bona fides.)
I'd say encryption and PKCS#1v1.5. The latter is just hard enough to implement safely that it's quite likely to be vulnerable, but not so obviously bad as to be considered definitively broken & set for removal. PKCS#1v1.5 support might not be a deliberate backdoor, but allowing it in a new protocol today would be suspicious.
We went to curves largely due to the flaws of PKCS#1v1.5, not so much due to RSA itself being bad (though the false sense of simplicity it has is certainly dangerous). RSASSA-PSS verification is fast, so while the keys & signatures are big there's still some reason to use it for constrained devices.
Well, sure, but the alternatives are more complex and harder to get right. You can literally just pick two random numbers of the right magnitude, find the closest primes, and be good for RSA.
No, the alternatives are less complex, and easier to get right.
Further: the article you linked to describes the attack we are talking about right now on this thread, a fully remote fault attack that harvested keys off random SSH servers on the Internet, as "a completely theoretical hardware attack". (Narrator: it was not; further, this is that "completely theoretical" attack in its most difficult setting.)
This is still wrong! Leaving aside that hardware faults are themselves implementation pitfalls for RSA, the fundamental failure here is a software implementation flaw. You really need to understand these attacks before you supply guidance about them.
Yeah, there are pitfalls in RSA, but so are there in elliptic curve algorithms. I'm not sure if I'd say RSA has more pitfalls than ECDSA. Ed25519 is better, but so is RSA-OAEP/PSS over PKCS #1.5, where many of the common RSA pitfalls are. Most of the RSA pitfalls are in RSA encryption, which is irrelevant if you only use signatures.
You don't have to select primes very carefully. You can select random numbers, check if they are of the right size and prime, and you're good. What some people tend to do is to select primes in a "smart" way, which this post rightfully points out is problematic (see ROCA). But they also reference the batchgcd issue, which is not really an RSA issue. It is ultimately a bad RNG issue, and the very same issue also caused ECDSA implementations to break (with the same catastrophic "you reveal your private key" result).