Conversation
The typed-data signing scheme (dusk-network/wallet#22) is implemented in JavaScript twice: in the Connect SDK and in the wallet extension. Both check themselves against a shared vector corpus, and until now nothing checked that corpus against this crate. That gap is not theoretical. Dusk signs under a custom hash-to-curve domain separation tag, BLS_SIG_BLS12381G1_XMD:SHA-256_DUSK_V2, and every BLS library defaults to the IETF ciphersuite instead. An implementation that leaves the default in place is self-consistent: it verifies its own signatures, all of its round-trip tests pass, and every signature it produces is rejected on chain. Only fixed expected bytes, checked against this implementation, catch it. The test derives keys with derive_bls_sk, signs the tagged message with the V2 path, and compares the secret key, public key, signed message and signature to the vendored bytes. It also asserts that a corpus signature does not verify over the bare 32-byte digest, which is the property the domain tag exists to provide. Vectors are vendored verbatim from dusk-network/typed-data with the source commit recorded in tests/vectors/SOURCE. They are generated there, not here.
serde_json is a dev-dependency used only by tests/bls_typed_data_vectors.rs. unused_crate_dependencies is evaluated per target, so the lib test target denied it and the package failed to build under cargo test.
ichbindas
marked this pull request as ready for review
September 13, 2026 20:49
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft: opened to get a CI build.
The test has not been compiled locally. Its assertions were verified against
bls12_381-bls0.6.0 in a standalone crate with derivation transcribed fromwallet-core, but the in-tree build againstdusk_wallet_core::keysanddusk_coreis unproven. Marking ready once CI is green.Adds a conformance test for the typed-data signing scheme (dusk-network/wallet#22) and vendors its vector corpus.
Why this belongs here
The scheme is implemented in JavaScript twice — in the Connect SDK and in the wallet extension — and both check themselves against a shared corpus. Nothing checks that corpus against this crate.
That gap is not theoretical. Dusk signs under a custom hash-to-curve domain separation tag,
BLS_SIG_BLS12381G1_XMD:SHA-256_DUSK_V2, while every BLS library defaults to the IETF ciphersuite. An implementation that leaves the default in place is self-consistent: it verifies its own signatures, all of its round-trip tests pass, and every signature it produces is rejected on chain. Only fixed expected bytes, checked against this implementation, catch it.What the test does
Derives keys with
derive_bls_sk, signsSIG_TAG || digeston the V2 path, and compares the secret key, public key, signed message and signature to the vendored bytes. It also asserts a corpus signature does not verify over the bare 32-byte digest, which is the property the domain tag exists to provide, and thatderive_bls_skis deterministic for a fixed seed and index — the assumption the rest of the file rests on.What it adds
wallet-core/tests/bls_typed_data_vectors.rswallet-core/tests/vectors/bls-v1/— five vectors, vendored verbatimwallet-core/tests/vectors/SOURCE— the upstream commit they came fromserde_jsoninwallet-core's dev-dependencies; already a workspace dependency, so the lockfile change is one lineVectors are generated in
dusk-network/typed-dataand are not edited here. Changing them means changing them there and re-vendoring.Related: dusk-network/connect#35, dusk-network/wallet#101, dusk-network/typed-data.