Use a consistent definition of Ed25519

[Yawning]

aka "Just use Ristretto"

• Go:
  • Use github.com/oasisprotocol/curve25519-voi/primitives/x25519 for X25519 (crypto: Fix the rust and go ideas of Ed25519 to match reality #140).
  • Use github.com/oasisprotocol/oasis-core/go/common/crypto/signature for Ed25519.
  • Fix the replace directives under client-sdk/go/go.mod, though nothing in this code-base should import the stdlib's X2551/Ed25519 code (crypto: Fix the rust and go ideas of Ed25519 to match reality #140).
  • Third parties that chose to use crypto/ed25519 instead of what we provide, are causing issues for themselves, so this should be documented.
• Rust:
  • Don't import ed25519-dalek, use common::crypto::signature from github.com/oasisprotocol/oasis-core/runtime (Requires runtime/common/crypto/signature: Switch Ed25519 to our consensus flavor oasis-core#3946) (crypto: Fix the rust and go ideas of Ed25519 to match reality #140).
• Typescript/JS:
  • Someone that can stomach writing TypeScript/JS needs to implement Ed25519 signature verification with our semantics.

[kostko]

Go: Use github.com/oasisprotocol/oasis-core/go/common/crypto/signature for Ed25519.

Isn't this already the case?

[Yawning]

Go: Use github.com/oasisprotocol/oasis-core/go/common/crypto/signature for Ed25519.

Isn't this already the case?

Yeah, just being thorough.

[Yawning]

Looking over the JS/TS case, applying the retrofit to tweetnacl is non-trivial. I don't know of any JS/TS libraries that both provide what is required, that I have high confidence in, so the question would be "how much do we care that JS/TS behaves in an inconsistent manner"?

As is (assuming the rust code is fixed), all signatures that Rust/Go implementations consider to be valid will be verify with the JS/TS implementation, but not in the reverse (there will be signatures that JS/TS code considers to be valid that will be rejected).

[pro-wh]

maybe we should get rid of the signature verification in the ts library. can we still use tweetnacl to sign consistently with the rust and go libraries?

[Yawning]

can we still use tweetnacl to sign consistently with the rust and go libraries?

Signing behavior is consistent across basically every Ed25519 implementation, yes.

[Yawning]

There probably should be documentation somewhere that SDK developers will see concerning our Ed25519 verification semantics just so people don't try to do something exotic and end up surprised.

All of the verification behavior is triggered by key-pairs and signatures that won't ever be generated by a honest implementation, and I'm not sure how much behavioral consistency matters on the client side...

[Yawning]

Wait, why did you close this? It is 100% possible to produce signatures that will pass validation with the js/ts code that will not anywhere else, because ts-web/core/src/signature.ts is flat out incorrect.

At the very least, this behavioral inconsistency should be documented somewhere.