Posted on

Walking in the Forest of Curves

Elliptic Curve. For various reasons it’s probably time to stop toodling around the Internet with a 70’s era crypto algorithm inside our certificates. Seems to me Ed25519 is a rational choice to try to use. I’m walking into a discussion that’s been going on for years. This is not a news flash. I assumed it would be straightforward. “Stick it in the certs I make with OpenSSL, start testing with latest Chrome.” My worst problem should be spelling it right in the blog post. (is it “Ed25519” or “ED25519”?)

Yeah right. Welcome to the bleeding edge.

There is, almost, I think, an IETF draft on how to use an Ed25519 signature inside a PKIX certificate.
There is a variant of OpenSSL (BoringSSL) that implements Ed25519. In it’s “speed” command (OpenSSL remix, remember, so think “openssl speed” at a shell prompt.) Not in certificates. So this is wired in but not for old-school certificates (in the PKIX/X.509 sense.)

Looking at the inside wiring of OpenSSL (Or BoringSSL) it would appear there are open tasks. IMO here’s the list:

  • curve name not wired to methods
  • PKEY entries for Ed25519 method needs more, specifically signature and verification
  • need to confirm signing and verification functions as implemented for Ed25519 fit with the certificate mechanisms (the code underneath the “openssl req” command)

How about SSH? PuTTY doesn’t seem to have it. Devuan for the Pi doesn’t seem to have it. This the kind of spotty algorithm coverage I would expect at the edge of the adoption wave so I’m not worried about the implementations I am finding. I’m still worrying about whether I’m talking about the use of the algorithm in mechanically correct ways 😉