Support for Curve25519 Key Exchange and Ed25519 Authentication

[Nottt]

When LibreSSL will support Curve25519 for Key Exchange and Ed25519 Key Authentication to be possible to implement a full ECC public key infrastructure without using NIST curves and others with performance not so good? We can see that by now many libraries support it : http://ianix.com/pub/curve25519-deployment.html

LibreSSL 2.1 compiled on OpenBSD 5.7 does not show this curve.

Ed25519 : http://ed25519.cr.yp.to/

This algorithms is really more fast on low end hardware like embedded systems and mobile phones than RSA-4096 and AES-256 especially when mostly of low end hardware doesn't have any kind of hardware acceleration and yet they are even more secure. I hope to see those algorithms in the next release.

Possible relevant discussion : https://www.ietf.org/mail-archive/web/tls/current/msg10179.html

[busterb]

Hi, are you simply referring to libcrypto support, or the draft TLS key exchange RFC: https://tools.ietf.org/html/draft-ietf-tls-curve25519-01

[Nottt]

I'm talking about using Ed25519 and Curve25519 for key exchange and authentication for TLS. I guess we can take a few of code from OpenSSH? I would like to know when it will be implemented. I really want a viable implementation to have a full ECC public key infrastructure, with all the security gains and faster operations than RSA-4096 and AES-256 on mobile phones and embedded systems. I would really appreciate if we could be bold to support early algorithms.

Or would be possible to build libressl with another libcrypto support like Nettle?

[busterb]

OK. I do not believe the blocker is the crypto library, it is that the RFC for using Curve25519 for TLS key exchange has not been ratified yet. As you can see from the link above, the RFC is still in draft form.

[leonklingele]

Chrome 50 will add support for Curve25519/X25519:

• https://www.chromestatus.com/feature/5682529109540864
• https://code.google.com/p/chromium/issues/detail?id=579716
• https://groups.google.com/a/chromium.org/forum/#%21topic/blink-dev/A9RTBPzwe8w

[hlandau]

I don't think the fact that the draft hasn't been ratified should be a blocker; Chrome (and therefore BoringSSL) are already shipping it. Also, since BoringSSL and LibreSSL are both derived from the same codebase, porting it might be doable.

[jellemdekker]

Chrome 50 has been released and supports X25519 now!
Check it out yourself: https://www.ssllabs.com/ssltest/viewMyClient.html

[MichalStaruch]

X25519 was standardized as RFC 7748 months ago, and is already supported in OpenSSL 1.1.0 (stable). Would be nice if LibreSSL didn't lag much behind and support at least one safe curve, too.

[yonas]

I'm looking forward to seeing X25519 supported in LibreSSL!

[yonas]

@bob-beck Is there an intention to add X25519 to LibreSSL? What is the timeline for this?

[Wonderfall]

+1 for X25519, which is a safe curve compared to the NIST ones.

[secureemail]

https://en.wikipedia.org/wiki/Curve25519#Libraries
I really looked twice in the Libraries list because I thought they forgot to add LibreSSL. +1

[4a6f656c]

Support for TLS ECDHE with X25519 has been added in openbsd/src@0ad90c3

[leonklingele]

@4a6f656c when will this land in https://github.com/libressl-portable/openbsd?

[leonklingele]

libressl/openbsd@2ea639d doesn't work for me.
openssl ecparam -list_curves | grep 25519 returns nothing and nginx still reports EC_KEY_new_by_curve_name("X25519") failed (SSL: error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group)

[kaze87]

@busterb @4a6f656c same for me -- Why is this issue already marked closed? X25519 doesn't work right now

[busterb]

X25519 does not work the same as the other eliptical curves, so it is expected that it will not show up under ecparam's list. Try the same openssl ecparam -list_curves operation with OpenSSL 1.1.0, which also has X25519, and you will see the same result.

Will double-check that it's showing up in the handshake for the -portable branch. Seems to work fine on OpenBSD currently.

[busterb]

Looks to be live on the portable branch too. Look for Elliptic curve: ecdh_x25519 (0x001d) in the handshake.

[leonklingele]

Trying cf056d7 and libressl/openbsd@eb2dc5e, however nginx still reports EC_KEY_new_by_curve_name("X25519") failed (SSL: error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group).

Connections to an openssl s_server keep negotiating prime256v1.

@busterb How did you test for 0x001d?

Edit:
Is there a way to set curves for openssl s_server?

[busterb]

Hi @leonklingele, I just used 'openssl s_client -connect ' and 'nc -c' without changing anything else.

Though reports to the contrary (https://trac.nginx.org/nginx/ticket/993), NID_X25519 is not supported with EC_KEY_new_by_curve_name with OpenSSL or any of its current forks, though it may have worked at one time for a short while in OpenSSL 1.1.0. We may need to backport SSL_CTX_set1_curves_list() in order to allow the new way of setting curves with OpenSSL 1.1.0. EC_KEY just isn't a good API for this due to the way ECDHE is used with X25519.

Refs:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846085
https://mta.openssl.org/pipermail/openssl-dev/2016-October/008582.html

$ cat test.c 
#include <stdio.h>
#include <openssl/ec.h>
#include <openssl/objects.h>

int main()
{
	int nid = OBJ_sn2nid("X25519");
	printf("%d %p\n", nid, EC_KEY_new_by_curve_name(NID_X25519));
	return 0;
}

LibreSSL 2.5.1
1034 (nil)

OpenSSL 1.1.0c  10 Nov 2016
1034 (nil)

[leonklingele]

@busterb thanks for clarifying. Request to backport SSL_CTX_set1_curves_list is here: libressl/openbsd#58

[leonklingele]

Now that libressl/openbsd#33 / libressl/openbsd#33 was implemented, X25519 finally works with nginx when applying a small patch to define SSL_CTRL_SET_CURVES_LIST. Yay!
And with libressl/openbsd@7bbd539 we also get an option to set curves list for s_client. 😻