Add Ed25519 support: algorithm definition and examples

[msporny]

It's been a very long time since I added the RSA signature test vectors to the appendix of the HTTP Signatures spec. We should replace them with more modern examples. My suggestion would be to use ed25519 examples, or secp256r1 (P-256) examples. The former would need a new signature algorithm specified, which would be a good thing.

[jricher]

We should add new examples, not remove ones that are there and are functional. All of the test vectors in the spec have been re-generated from scratch in the latest draft, so none of the older tests should still be in the draft at this point.

[jricher]

Additional tests for HMAC and ECDSA were added in #1528

[jricher]

Keeping this issue open as a call for adding support for Ed25519 and others.

[jricher]

Ed25519 support seems to have been implemented in the wild by libraries like https://github.com/igor-pavlenko/httpsignatures-go and https://github.com/trustbloc/orb/tree/main/pkg/activitypub/httpsig.

Tagging an implementor: @igor-pavlenko could you help define the parameters for Ed25519 support in the core spec?

[naturallymitchell]

You can do HTTP message signing with profile and key management using Jazz (a Rust programming language with Lua scripting) and its Content Management System, Jazz Flute (aka Lighttouch). The crypto implementation is in its keys module and keys package, and database is in ContentDB. Ping Pong has a refined basic example to see how it works. I'm working on a web site for jazz.dev with installation instructions, a getting started guide, organized documentation links, and example projects. If you need any help, I'd be happy to answer your questions.

[jricher]

I've implemented what I think is a reasonable version of Ed25519 using pynacl and added it to the demo generation script, if someone else can confirm this code and its results that would be best. I had to do a lot of unpacking of the key values by hand because support wasn't natively there in the libraries I could find.

https://github.com/bspk/sig-example-scripts/commit/df035171949db76c73d67d7cccabaacfff274a05

@bblfish perhaps?

Script output:

Base String:

"date": Tue, 20 Apr 2021 02:07:56 GMT
"@method": POST
"@path": /foo
"@authority": example.com
"content-type": application/json
"content-length": 18
"@signature-params": ("date" "@method" "@path" "@authority" \
  "content-type" "content-length");created=1618884475\
  ;keyid="test-key-ed25519"

Signature:

Signature: sig1=:u9DvOJe17NdTTuIJjKac9WncuAo/1d4gOh6TXMV6AN4hxLdttB\
  SegWS/RcWPZ+lENCtykh6YGl8GJiQrxgibBg==:

[bblfish]

I am just in the process of pulling out my implementation of Signing HTTP Messages to its independent repository http4s.

But I can check that the signatures work in JS and Java for bobcats PR 48...

[jricher]

After asking around, I've updated the code to run a SHA-512 hash on the input base string before feeding it to the signer, to have some things to compare to. This results in the following signature instead, with all other parameters being the same:

Signature: sig1=:a3a+juFLCw/11lNo8NnpntB7pfH1i6KFgHir4lsQ3wuta1P9Nn\
  IxlYjWn1NyBHkSr3dKRE0p7r8fNehG3yBwCw==:

This simple change is in https://github.com/bspk/sig-example-scripts/commit/764e6bd3c54e060d73287aa5e8b5a4bb448d2741

[jricher]

After even further investigation, I'm still not sure whether the pre-hash is really the right approach here or not.

[bblfish]

Would having other implementations help decide this? (I have not gotten round to it trying an implementation) What is it that is making you undecided? (Perhaps knowing that could help me give you an answer by implementing)

[jricher]

Other implementations are always welcomed. What's getting me right now is that I can't see if it's necessary or expected with Ed25519, as it would be with other signature schemes like RSA or ECDSA.

[martinthomson]

To my knowledge, the pre-hash variant of Ed25519 is not very well supported relative to the "pure" variant.

[bblfish]

In Java I found the following:

• Ed25519 in the KeyPairGenerator Algorithms

• Ed25519 in the Signature Algorithms

  In the Java 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. From that it seems that there is no built in implementation in Browsers. It seems people have been building their own implementations in JS.

There are implementations such as noble-ed25519 aimed at node.js. But I can't tell which are well built, or not. So that means that on the JS side there is quite a lot of work to do.

So that is something to keep in mind when developing bobcats PR 48...

[msporny]

/cc @dlongley -- I know we've had this discussion w/ a number of vendors, where did we end up -- what seemed to be the most "used by default" approach for EdDSA w/ Ed25119?

[jricher]

This code from the RFC shows that there's an internal hash in the algorithm applied to the message:

https://www.rfc-editor.org/rfc/rfc8032#section-6

This is true whether PH(M) is a SHA function or an identity function, so I'm now really not seeing the value in having PH(M) be an additional hash.

[bblfish]

I got @jricher's first signature above to work in Java with this commit: https://github.com/typelevel/bobcats/pull/48/commits/4ffd678b99e699f4cbba62cfa8cae3a22b587fee#diff-761b3ea7aacf5fe09f926c3c452989e6094f6f33353cc550e029692fe9a6b588

That did not require me to set any hash.

[jricher]

I've backed out the prehash changes from the generator script, and we'll be adding a definition that use PureEdDSA with no PH function. Other functions can, of course, be defined on their own in the future.

[dlongley]

+1 for PureEdDSA with no PH function.

[bc-pi]

No PH seems like the right thing