JavaScript JcsEd25519Signature2020 fails against Test Vectors

[Aconitin]

When running the code over here against the Test Vectors , I always receive signatures different to the one(s) in the test vector data.

Is there something special I need to consider to get the example to work? Could you confirm that the Test Vectors are still up-to-date w.r.t. the JavaScript implementation?

It doesn't seem to me that the Test Vectors are the result of following the specification precisely...

[JelleMillenaar]

So after doing some test runs, we concluded that there are currently two "groups" of implementations of JcsEd25519 signing in the repository that are incompatible with each other. The JavaScript implementation follows the spec, by hashing the input first with SHA-256 and using Ed25519 from TweetNaCl. Both Golang and Java don't follow the spec as they don't hash with SHA-256, but instead use an Ed25519 implementation that hashes with SHA-512 during the signature generation (This is probably also incompatible with TweetNaCl). This result is also what matches the Test Vectors and this result was easy to recreate in Rust using the Z-Cash Ed25519 implementation.

Our recommendation would be to alter the spec to remove the SHA-256 hashing step as that is usually taken care of by the Ed25519 signature generation anyway, while also updating the JavaScript implementation to match the Test Vectors.

We would love a response to hear which of the two directions will be chosen as we otherwise have to alter our implementation (Which will be a breaking change for our DID library). Thanks :)

[olivereanderson]

@OR13 and/or @decentralgabe do you know if there are any plans to reconsider the Proof Generation Algorithm in the JcsEd25519Signature2020 specification with regards to the recommendations from @JelleMillenaar and @cycraig (see #26)?

[OR13]

Transmute is not planning to support this suite... there are better alternatives being discussed in the VCWG.

I am happy to review a PR that addresses both implementation and test vectors.

[decentralgabe]

@olivereanderson similarly, I am no longer interested in this work. Aligned with Orie. That said, if you wish to become a new owner, happy to support you there.

[olivereanderson]

Thank you both for explaining (and also for kindly offering to help us if we decide to propose a PR).

@OR13 would you be willing to go into a bit more detail about the alternatives being discussed in the VCWG and how they compare to JcsEd25519Signature2020?

[OR13]

The primary alternative is https://github.com/w3c-ccg/lds-jws2020

It supports all the JOSE signature types, but relies on URDNA2015 for canonicalization, which aligns it with 99% of other Data Integrity Proofs.

You can also just with VC-JWT, which does not require any normalization, supports standard signature envelope formats, and is probably the simplest way of creating a credential with off the shelf libraries.

I'm editor on both of those items in the VC WG, we have not imported any history for either yet, but we are starting that process, here are the repos to follow:

• https://github.com/w3c/vc-jws-2020
• https://github.com/w3c/vc-jwt

[olivereanderson]

@OR13 Thank you very much for your reply and the links. This is indeed useful for us to know.

We have yet to make a decision on how to proceed, but from reading the create verify hash algorithm from the VC Data Integrity spec it seems that the problem of knowing whether to hash the value to be signed before passing it to a signature algorithm that (also) hashes internally affects other LD proof suites as well (see the issue under point 5).

[OR13]

Yes, the createVerifyData algorithm, uses hashing an canonicalization to protect RDF.... the exact algorithm is being defined at the W3C.