3 ms·
I’m a bit miffed after just a couple paragraphs. My reading of the original article was that the issue of people feeling tempted to implement RSA was just exace
by jchw 5y ago
I’m a bit miffed after just a couple paragraphs. My reading of the original article was that the issue of people feeling tempted to implement RSA was just exacerbating the problem of how difficult it is to implement RSA securely.
I am not a cryptographer. I’d be rather cautious about implementing my own cryptography at all, less with my own code implementing the primitives. That said, Trail of Bits makes a compelling argument, that, in my reading, RSA is harder to get right in subtle ways, whereas ECC is just hard to grok period. A bad RSA implementation leads to weak cryptography, but a bad ECC implementation often leads to something that doesn’t work at all.
This, alongside other benefits of ECC like smaller key sizes for similar cryptographic security, faster and simpler key generation, more idiot-tolerant properties, etc. makes ECC an obvious choice even disregarding if you can implement RSA. It’s just that people like to choose RSA because they feel like they understand it, but the truth is they only understand the surface-level basics. (To be fair, me too. Though I feel I also can grok some surface-level basics of some ECC-based algorithms, too.)
Feel free to flame me for not reading the article entirely; I definitely earned it. But that opener made me not want to, sorry.
- throwaway81523 5y agoECC is also easy to mess up, especially the NIST curves. Plenty of subtle stuff to get wrong.
- deleted 5y ago[deleted]
- tptacek 5y agoCurve25519 is significantly harder to mess up than RSA. You can go either way on the NIST curves vs. RSA, but at an architectural level there's simply less that goes around with the model of ECC than with RSA, which directly exposes an easy-to-use (and treacherously easy to fuck up) encryption transform. I wouldn't implement with the NIST curves at all, but if you asked me to pick between them and RSA, I'd still take P-256 over RSA.
- jchw 5y agoThat was acknowledged and accounted for in the original article. But given that we have curves that we believe are safe, I’m not sure this is an issue, at least any more so than relying on known-good ranges for parameters in any cryptosystem…
- nwallin 5y ago> A bad RSA implementation leads to weak cryptography, but a bad ECC implementation often leads to something that doesn’t work at all. Bad RSA implementation => weak cryptography. We agree on that. Bad ECC implementation => doesn't work. We agree on that. Working ECC implementation => strong cryptography. We do not agree on that. I think that there are many subtle ways to make a weak ECC implementation. At the end of the day, I am never going to roll my own crypto implementation. (Well, actually, I already have, but it was for "hey how does this work. oh it works like this. neat!" and promptly deleted the code afterwards) I'm always going to use libsodium or nss or openssl or gnupg or or or. So the fact that RSA is harder to implement correctly than ECC is... well that kinda doesn't matter to me. Implementing it correctly isn't my job. All I need to do is include someone elses' library. And I can be about as sure that libsodium or openssl has implemented the proper precautions to make RSA secure. So the fact that RSA is hard -- well, it's kinda irrelevant. FWIW, I tend to default to ECC, because ECC is the new hotness, and that appeals to me for entirely superficial reasons. I'm just saying that if you're going to say that RSA is bad, you should have the right reasons for saying so.
- Retr0id 5y agoECDSA in particular is very easy to fuck up (which Sony famously did - although there are plenty of examples of more subtle sidechannel attacks in, for example, the OpenSSL CVE history). Although, that's more of a criticism of ECDSA than it is of ECC as a whole.
- marcan_42 5y agoECDSA is easy to fuck up due to needing a "random" number for signatures (among other things, but that's the one Sony did and many others have since). Thankfully, we've figured out an easy fix for that: just hash the private key and the message, and use that instead of the randomness. That's in the spec for ed25519, so unless you're completely ignoring chunks of the spec (which would be unlikely to work for an algorithm like this, and wouldn't pass test vectors) you're probably fine on that front if you use it, even if you're reimplementing it.
- deleted 5y ago