Add Ed25519 support

[bblfish]

The HTTPbis WG's Signing HTTP Messages RFC team have been looking to add support for Ed25519.

[bblfish]

I did some research to see what would be needed. It looks like Java support comes out of the box, but there is no support in browsers. I can't tell for NodeJS.

Here's what I found:

In Java we have:

• Ed25519 in the KeyPairGenerator Algorithms

• Ed25519 in the Signature Algorithms

  In the JavaScript Web Crypto API I found a proposal to Support Curve25519 in WebCrypto from Feb 2020. I found an issue in Chrome's Blink-dev Intent to Prototype: Curve25519 in Web Cryptography which linked to an issue Feature: Curve25519 in Web Cryptography. Both seem to say that there is no built in implementation in Browsers. People have been building their own implementations in JS.

[armanbilge]

I'm hesitant to do anything more than wrap existing crypto APIs—there's no way we can implement, test, and maintain our own crypto algorithms to any useful standard. So this one will have to wait :)

[bblfish]

I'm hesitant to do anything more than wrap existing crypto APIs

Yes, I was not suggesting to implement any cryptographic algorithms! That would be way too much work. The problem is that some algorithms are implemented in some frameworks but not others. So Ed25519 is available in Java but not JS Web Crypto API. (It may be available in NodeJS crypto).

I think the example is useful though in so far as it indicates that we should perhaps work on making the system more open, so that it is possible for users to add new algorithms as separate downloadable modules.

This could be an argument against for example having the algorithms being sealed.

I could see for example that someone would wish to add Ed25519 support for themselves using their trusted library.

[yilinwei]

Caveat, I'm only really familiar with the crypto framework in Java (SecurityProvider etc), WebCrypto and openssl. I don't know about node enough really to comment.

On the one hand, I'm super-sympathetic to the idea of being able to plug a separate algorithm (and indeed most of the API's practically allow for it) especially if it is just a separate hash algorithm.

On the other, it's a nightmare as a user to figure out how to use some of this stuff; I think Web Crypto (missing implementations aside) does a good job and we see something like OpenSSL also introducing higher-level API's.

Ideally there are a few goals which I'd quite like which I don't think the current encoding works for, I ideally like to achieve the following:

1. Allow users to add algorithms
2. Fail to compile if the algorithm doesn't exist on the platform or isn't added by the user

Of course, we still have reflection/runtime behaviour (if you compile your openssl or do weird things with your SecurityProvider then $INSERT_DIETY help you), but I'm hoping that most people won't need to resort to this escape hatch.