A new ECC curve has been introduced in a recent paper by Daniel J. Bernstein and Chitchanok Chuengsatiansup and Tanja Lange.
While not claimed to be as fast as Curve25519, Curve41417 should provide a much higher security margin, and be fast enough for most applications.
This discussion has been archived.
No new comments can be posted.
Curve41417: New ECC Curve Bumps Speed/Security Baseline
|
Log In/Create an Account
| Top
| 5 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: -1, Troll) by Anonymous Coward on Thursday July 10 2014, @10:23AM
Is DJB still sleeping with his students?
(Score: 0, Insightful) by Anonymous Coward on Thursday July 10 2014, @02:16PM
What if he is? How is that related to his authority as a cryptographer? Why not sleep with your students, if the involved people want to? What's your fucking problem? How is another person's personal life your business?
This is soylentnews, not Fox, you can't discredit people's work with pathetic ad hominems; go tell your boss.
(Score: 4, Informative) by WizardFusion on Thursday July 10 2014, @10:54AM
For those (like me) that have no idea what the summary is going on about...
(Score: 3, Informative) by dbot on Thursday July 10 2014, @06:26PM
Still getting the hang of this articles thing.
When used in Elliptic curve Diffie–Hellman (ECDH) [wikipedia.org], Curve41417 can be used to establish a shared secret over an insecure channel.
Like Curve25519, Curve41417 is resistant to side channel attacks based on cache timing.
Curve25519 has a security strength of 2^128, while being over twice as fast as comparable NIST curves.
Curve41417 has a security strength of 2^200, while still being faster than the fastest NIST curves in OpenSSL (which has a security level of 2^80).
Compared to RSA, to achieve the security level [wikipedia.org] of Curve25519, you'd need a 3072-bit key.
Here's a chart showing an anecdotal speed comparison [imperialviolet.org] of Curve25519 vs DSA-2048.
TLDR; Faster, more secure, public-key crypto primitives published.
(Score: 1, Insightful) by Anonymous Coward on Friday July 11 2014, @04:16AM
"sometimes cryptographic protocols are not as secure as the underlying cryptographic primitives. Often there is a security proof putting a bound on the gap, but usually the security proofs are not "tight". In particular, many ECC protocols are not guaranteed to provide 2^128 security using 256-bit curves, even assuming the standard security conjectures for ECDLP on those curves. Achieving a 2^128 guarantee requires taking larger curves. We thank an anonymous referee for pointing out this argument."
There is no citation for this, and I don't see any explanation. Does anyone know where what kind of issues this is referring to? It seems like the kind of thing I should be aware of as a user of cryptography, but I haven't heard of this before. This isn't just things like side channel timing attacks is it?