contract-sdk: Expose signature verification to wasm contracts

[jberci]

Closes #368

[codecov]

Codecov Report

Merging #793 (8eea938) into main (64a33cc) will decrease coverage by 1.13%.
The diff coverage is 2.46%.

@@            Coverage Diff             @@
##             main     #793      +/-   ##
==========================================
- Coverage   73.14%   72.00%   -1.14%     
==========================================
  Files         114      116       +2     
  Lines        8846     8987     +141     
==========================================
+ Hits         6470     6471       +1     
- Misses       2353     2493     +140     
  Partials       23       23              

Impacted Files	Coverage Δ
client-sdk/go/crypto/signature/secp256k1/signer.go	59.37% <0.00%> (-16.63%)	⬇️
client-sdk/go/modules/contracts/types.go	40.00% <ø> (ø)
contract-sdk/src/abi/env.rs	0.00% <0.00%> (ø)
contract-sdk/src/testing.rs	12.90% <0.00%> (-5.28%)	⬇️
contract-sdk/types/src/crypto.rs	0.00% <0.00%> (ø)
contract-sdk/types/src/lib.rs	100.00% <ø> (ø)
runtime-sdk/modules/contracts/src/abi/oasis/env.rs	70.58% <ø> (+16.42%)	⬆️
runtime-sdk/modules/contracts/src/abi/oasis/mod.rs	62.96% <ø> (ø)
runtime-sdk/modules/contracts/src/lib.rs	69.19% <ø> (ø)
runtime-sdk/src/crypto/signature/ed25519.rs	43.75% <0.00%> (-12.25%)	⬇️
... and 3 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 64a33cc...8eea938. Read the comment docs.

[Yawning]

Per discussion: The batch verification stuff should just go away, because it's a giant pain.

While I'm commenting on this:

The Ed25519 signature verification in oasis-core/runtime/src/common/crypto exposes our flavor of Ed25519 (with our janky domain separation), and our idea how to handle certain edge cases.

Is it ok that we are forcing this on end user code? I suppose that the circumstances that lead us to use something non-standard at the consensus side in the first place haven't really changed ("Ledger doesn't support Ed25519ctx/Ed25519ph"), but actual contract authors might want Ed25519pure (as opposed to Ed25519-prehashed-oasis-flavor-because-ledger).

If we do want this, I would recommend using one of ZIP-215/FIPS 186-5/Oasis flavored Ed25519pure, which would require additional code (or pulling in a crate), with a slight preference towards one of the latter two.

[kostko]

The Ed25519 signature verification in oasis-core/runtime/src/common/crypto exposes our flavor of Ed25519 (with our janky domain separation), and our idea how to handle certain edge cases.

Yeah we should definitely not impose our domain separation scheme and we should expose Ed25519pure here, possibly the ZIP-215 one?

[Yawning]

Yeah we should definitely not impose our domain separation scheme and we should expose Ed25519pure here, possibly the ZIP-215 one?

I wish ZIP-215 was closer to the FIPS draft, though my preferred Ed25519 definition involves rejecting small-order-A.

[Yawning]

Since we're going to expose Ed25519pure, the only primitive where a domain separation context makes sense is sr25519. Should we nix the argument for now, or leave it?

[kostko]

Since we're going to expose Ed25519pure, the only primitive where a domain separation context makes sense is sr25519. Should we nix the argument for now, or leave it?

Dropping it would make the interface more consistent, but I guess it could be useful for sr25519?

[Yawning]

The new API looks ok to me.

[kostko]

This should also add parameters for controlling maximum sizes of inputs and set them to some sensible defaults.