Hello, There has been lately an attempt to avoid the NIST's curves due to suspicions about their generation. One of them are the brainpool curves at: http://tools.ietf.org/html/rfc5639 which seem to be sponsored by the German BSI. Having them in nettle would be a good thing (the same authors are working on standardizing these curves in TLS and PKIX).
regards, Nikos
On 09/30/2013 08:46 AM, Nikos Mavrogiannopoulos wrote:
There has been lately an attempt to avoid the NIST's curves due to suspicions about their generation. One of them are the brainpool curves at: http://tools.ietf.org/html/rfc5639 which seem to be sponsored by the German BSI. Having them in nettle would be a good thing (the same authors are working on standardizing these curves in TLS and PKIX).
Similarly, an implementation of Curve25519 [0] would probably also be useful to have in the library, as it is also under active discussion in several contexts.
--dkg
On 10/16/2013 11:03 PM, Daniel Kahn Gillmor wrote:
On 09/30/2013 08:46 AM, Nikos Mavrogiannopoulos wrote:
There has been lately an attempt to avoid the NIST's curves due to suspicions about their generation. One of them are the brainpool curves at: http://tools.ietf.org/html/rfc5639 which seem to be sponsored by the German BSI. Having them in nettle would be a good thing (the same authors are working on standardizing these curves in TLS and PKIX).
Similarly, an implementation of Curve25519 [0] would probably also be useful to have in the library, as it is also under active discussion in several contexts.
[reviving old thread]
It seems it is being pushed forward and openssh even uses it by default now. There are implementations like [0] that nettle could take advantage to use that curve, but what I'm worried about is that the current interfaces to use this curve provide no agility. If any issue is found replacing it isn't straightforward.
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
It seems it is being pushed forward and openssh even uses it by default now. There are implementations like [0] that nettle could take advantage to use that curve, but what I'm worried about is that the current interfaces to use this curve provide no agility.
I think you're more familier with its uses than I am. I'm thinking that it would be nice to have a
struct ecc_curve nettle_curve25519;
with the same operations (ecc_point_mul, etc), but maybe a very different implementation underneath.
Is that enough? It's not clear to me how people do signatures with curve25519, if that's plain ecdsa over a new curve, or something more or less different?
Will people also want djb's curve25519 function, defined with octet strings as input and output?
Are there any authoritative testvectors?
And about the "safe" curves listed at http://safecurves.cr.yp.to/, anything beyond curve25519 which is being deployed? M-383, Curve41417, M-511 or E-521?
Regards, /Niels
On Fri, Jan 31, 2014 at 8:16 AM, Niels Möller nisse@lysator.liu.se wrote:
I think you're more familier with its uses than I am. I'm thinking that it would be nice to have a struct ecc_curve nettle_curve25519; with the same operations (ecc_point_mul, etc), but maybe a very different implementation underneath.
That sounds very good.
Is that enough? It's not clear to me how people do signatures with curve25519, if that's plain ecdsa over a new curve, or something more or less different?
No signatures. It is only used for ECDH.
Will people also want djb's curve25519 function, defined with octet strings as input and output?
I don't know. I am mostly interested for: https://tools.ietf.org/html/draft-josefsson-tls-curve25519-04
which includes a test vector.
And about the "safe" curves listed at http://safecurves.cr.yp.to/, anything beyond curve25519 which is being deployed? M-383, Curve41417, M-511 or E-521?
There is some discussion in CFRG which will probably end-up in a draft but I don't really follow up.
regards, Nikos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aloha!
Nikos Mavrogiannopoulos wrote:
And about the "safe" curves listed at http://safecurves.cr.yp.to/, anything beyond curve25519 which is being deployed? M-383, Curve41417, M-511 or E-521?
There is some discussion in CFRG which will probably end-up in a draft but I don't really follow up.
I would say that "some" is a bit of an understatement. There are tons of discussions going on at the moment ranging from things like naming schemes of curves but also a lot of discussions related to implementations, patents, what curves are to be considered safe and why etc.
Right now it is hard to say what the results will be, but that there will be new curves used in IETF RFCs and protocols specified by IETF is probably not a wild guess.
Getting Curve25519 into nettle is a good start though.
BTW: There is a very interesting paper out from MSR that describes a survey of EC being used in practice.
http://eprint.iacr.org/2013/734
"In this paper, we perform a review of elliptic curve cryptography (ECC), as it is used in practice today, in order to reveal unique mistakes and vulnerabilities that arise in implementations of ECC. We study four popular protocols that make use of this type of public-key cryptography: Bitcoin, secure shell (SSH), transport layer security (TLS), and the Austrian e-ID card. We are pleased to observe that about 1 in 10 systems support ECC across the TLS and SSH protocols. However, we find that despite the high stakes of money, access and resources protected by ECC, implementations suffer from vulnerabilities similar to those that plague previous cryptographic systems."
- -- Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ========================================================================
You wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
It seems it is being pushed forward and openssh even uses it by default now. There are implementations like [0] that nettle could take advantage to use that curve, but what I'm worried about is that the current interfaces to use this curve provide no agility.
I think you're more familier with its uses than I am. I'm thinking that it would be nice to have a
struct ecc_curve nettle_curve25519;
with the same operations (ecc_point_mul, etc), but maybe a very different implementation underneath.
If that is implementable, and sufficient to do ECDH, I think this would be nice. Is there any generic (EC)DH interface in nettle? Maybe having one would be useful, although maybe the EC math operations in different curves is sufficient.
Is that enough? It's not clear to me how people do signatures with curve25519, if that's plain ecdsa over a new curve, or something more or less different?
There are multiple options, see Ed25519 for a new signing system EdDSA. It has some nicer properties than ECDSA but it is also a bit hardcoded to that curve. http://ed25519.cr.yp.to/
I don't think it makes sense to add anything about signing in nettle for new curves until there are practical use cases. Things are changing quickly in this space.
/Simon
Simon Josefsson simon@josefsson.org writes:
Is there any generic (EC)DH interface in nettle?
I think the three functions ecc_scalar_random, ecc_point_mul_g and ecc_point_mul are what's needed. And I added ecc_bit_size a few days ago.
This doesn't do encoding and decoding of points for ANSI x9.62 (or any other related standard), though.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Daniel Kahn Gillmor -
Joachim Strömbergson -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se -
Simon Josefsson