ED25519 Support

[atagar]

Hi there. Sorry if there's another issue tracking this. Presently Stem (part of Tor) is using PyNaCl to validate ed25519 certificates.

We use cryptography elsewhere and would love to use it for this too once there's support so we can drop the extra dependency. An email from January suggested this might be coming so just filing a tracking issue for us to watch so we know when we can switch.

If we should be following something else instead then feel free to resolve in favor of that.

Thanks! -Damian

[alex]

This won't happen until OpenSSL has ed25519 support: openssl/openssl#487

This can stay open, as none of our other tracking issues cover ed25519

[atagar]

Damn that was quick. Thanks Alex!

Filed a tracking issue on our end to take advantage of this once it's available. Looking forward to it! :P

https://trac.torproject.org/projects/tor/ticket/22022

[joelio]

+1 for this

[himikof]

Ed25519 support was recently merged in OpenSSL master: openssl/openssl#3503.

[reaperhulk]

Yep, we'll be implementing this when 1.1.1 is released.

[atagar]

Wonderful, thanks!

[reaperhulk]

I went ahead and implemented this as an experiment today: master...reaperhulk:ed25519

That is a WIP patch. It passes all tests, but there's no support for serialization of private keys, public key serialization is bare bytes only, and there's insufficient documentation. The API structure for loading/serializing probably needs a look as well since we'll likely want to support PKCS8. Also, to use this you'll have to compile against OpenSSL 1.1.1-dev (which means cloning current git master, building it, and successfully linking against it instead of whatever other OpenSSL you may have resident on your system)

[MaggieLplus]

Ed25519 TLS support was also merged to OpenSSL master: openssl/openssl#3585

[reaperhulk]

Since so many people are watching this issue here's an update. ed25519 support is basically ready, but we can't ship it (or ed448) until a bug fix release of OpenSSL 1.1.1 comes out to correct an issue we found in our testing. Hopefully that will happen sometime soon, but there's no timeline from the OpenSSL project at the moment.

[johnnybubonic]

thank you! excited to see this hit!

[wenottingham]

a bug fix release of OpenSSL 1.1.1 comes out to correct an issue we found in our testing.

Is this tracked somewhere public on the OpenSSL side?

[reaperhulk]

openssl/openssl#7706 and openssl/openssl#7693 are the issues I opened (and they link to the PRs that fix the bugs).

[reaperhulk]

Release is scheduled for next week: https://mta.openssl.org/pipermail/openssl-announce/2019-February/000145.html

Once that release comes out we can dust off the ed25519 and ed448 PRs, get them landed, and get a release out that adds support.

[ronf]

Looking forward to it!

Is there documentation available for what the API will look like here?

I'd also like to do some testing of what you have right now vs. the implementation I'm currently using from libnacl to see if I can make them interoperate.

[reaperhulk]

The API will look effectively identical to x25519/x448 but with sign/verify methods. You can see old PRs #4114 and #4610. Both of them need to be rebased and updated to match the serialization supported on the x25519/x448 side.

[ronf]

Great, thanks! I've already updated my curve25519/curve448 implementation to use the new serialization support for x25519/x448 in PyCA 2.5 and it's working well for doing ECDH. If similar public & private key classes are used but with sign() and verify() methods, I think that should work as long as I have a way to get the signature as a raw byte string (64 bytes in the Ed25519 case, or 114 bytes if I remember right for Ed448).

[reaperhulk]

Yeah the EdDSA signatures created by OpenSSL have no additional ASN.1 structure around them so the resulting byte strings should be what you expect.

[ronf]

I'm happy to report that both Ed25519 and Ed448 are now working in AsyncSSH using the support added to the PyCA 2.6.1 release last week. This is now released as part of AsyncSSH 1.16.0.