No; ECC is better. But as an implementor, if you're hoping to DIY, you're even worse off with ECC than with RSA; there are more parameters and validations steps you can get wrong with ECC that will result in a flawed implementation.
The security of these hardware devices is not tied to the RSA algorithm per se. The devices might not be more resilient against these attacks simply by using ECC instead of RSA.
Either way: don't implement RSA or ECC yourself. Use something like PGP/GPG.
OATH is the competing open standard to SecurID, as far as I know, and there's plenty of code that supports it. It's also what the Gmail 2FA and Google Authenticator are based on (so you can use any OATH client to authenticate to Gmail).
Tin-foil-hat reason: it has been shown that there exist a set of numbers with a particular relationship to the elliptic curve numbers, and that it is possible that whoever generated the elliptic curve numbers may also have generated the other set of numbers, which basically form a skeleton key to ECC.
That's a problem with the Dual EC PRNG, one of four PRNGs in NIST SP 800-90, not a "skeleton key to ECC" generally.
Given the horrible performance of that PRNG, I wonder if anyone implements it, securely I would hope (with random point generation rather than using the "recommended" possibly insecure points).
Not for RSA. It's highly unlikely that anyone has hidden a backdoor in the set of primes.
They'd have to solve the RSA problem, which is believed to be difficult.
When you do require a "magic constant" in a cryptographic algorithm, it is common to show good faith by deriving it in a way that would make it difficult to embed a backdoor. For instance ascii text, digits of pi, or the lowest AES encrypted number that fulfils certain criteria.
Edit: these is also called "nothing up my sleeve numbers".
When you do require a "magic constant" in a cryptographic algorithm, it is common to show good faith by deriving it in a way that would make it difficult to embed a backdoor. For instance ascii text, digits of pi, or the lowest AES encrypted number that fulfils certain criteria.
The initialization constant in SipHash is awesome: "somepseudorandomlychosenbytes".
Right, but that would be a backdoor in that particular implementation. If you implement RSA yourself, you're safe from backdoors. (With the usual caveats about compilers, operating system and hardware.)
The insidious thing about cryptographic backdoors is that they're embedded in the specification itself. Any conforming implementation will be vulnerable.
Right. I mentioned it because any discussion of why something isn't used should mention why it wasn't used. "It's ok to use this" is more compelling if it explains why the observed reality differs. :)
