4 ms·
> 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 =
by 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[deleted]
- Retr0id 5y agoIt's not just the randomness requirement, but also the requirement that k (the "random" nonce) remains secret. Without a sufficiently constant-time implementation, you leak information about k through timing sidechannels - and with clever tricks like lattice reduction you can recover the key with surprisingly little information.
- deleted 5y ago[deleted]
- tptacek 5y agoHow old does something have to be before it stops being "the new hotness"?
- jchw 5y agoYeah, but that’s the thing that makes this kind of dumb; the original article actually did list the other benefits of ECC, along with the no-questions recommendation to use Curve25519, and I trust cryptographers who say that it is easier to verify the correctness of a Curve25519 implementation than an RSA implementation. The “easier to verify correctness” part very much matters to me even if I’m not writing the code.