embit: pure-Python BIP340 signing diverges from libsecp256k1 on the default aux, and the parity test is skipped in CI

[fametrano]

What is measured

diybitcoinhardware/embit, pinned at
eb6104fd
(2026-08-08): src/embit/util/key.py:572,
def sign_schnorr(key, msg, aux=None, ...). With aux=None, line 594
sets t = sec.to_bytes(32, "big") — the raw secret key, with no aux
mask applied.

libsecp256k1's nonce_function_bip340_impl, given a NULL aux, XORs the
key with ZERO_MASK, a precomputed TaggedHash("BIP0340/aux", 0x0000...00) — not the raw key. embit.ec.PrivateKey.schnorr_sign
(src/embit/ec.py:234-235) never passes aux through, so every call
goes through this default.

Reproduced

BIP340 vector 0 (seckey 3, all-zero message): signing with the
fallback and an explicit zero-byte aux (matching libsecp256k1's
convention) reproduces the vector's expected signature, E907831F....
Signing with embit's actual default (aux=None, no masking) produces a
different signature, 8801B9FF....

The same key and the same message sign differently depending on which
backend embit loads — the ctypes/libsecp256k1 backend when available,
the pure-Python fallback otherwise. This is silent: nothing in embit's
public API surfaces which backend produced a given signature.

Why the test that would catch this doesn't run

tests/tests/test_bindings.py:134 — self.assertEqual(sig1, sig2) —
asserts exactly this parity between backends, but the test is
@skipUnless(_SCHNORR_AVAILABLE, ...) and .github/workflows/ci.yml
never installs libsecp256k1, so the check has been silently skipped in
CI since it was written.

Fix

t = sec.to_bytes(32, "big") should be masked with the BIP340
TaggedHash("BIP0340/aux", bytes(32)) constant when aux is None,
matching libsecp256k1's own default. Separately: add a CI cell that
installs libsecp256k1 so test_bindings.py's parity check actually runs.

Before sending upstream

Draft only. This is the highest-value finding in the embit survey — a
reproduced, silent, backend-dependent correctness bug in a library
targeting hardware-wallet firmware. Worth prioritizing if only one embit
report goes out. Include the official BIP340 vectors as part of the fix's
test coverage (tests/ has none today — correctness currently rests
entirely on the skipped parity test).

[fametrano]

Re-verified 2026-08-14, reproduced — and an open PR would delete the whole subject

embit master is still eb6104fd (committed 2026-08-08; the body said
2026-08-09). Every citation holds: key.py:572 is
def sign_schnorr(key, msg, aux=None, flip_p=False, flip_r=False), L594 is
t = sec.to_bytes(32, "big") in the aux is None branch, ec.py:234-235
never passes aux, and the parity assertion is test_bindings.py:134 under
a @skipUnless(_SCHNORR_AVAILABLE, ...) (gate built at L39, applied at L50).
ci.yml installs constraints-dev.txt and the package, and nothing builds
or fetches libsecp256k1 — only package-content-verification.yml mentions
the submodule, and only to check its URL. So the parity test has never run
in CI.

Reproduced against BIP340 vector 0 (seckey 3, all-zero message), calling
embit's pure-Python backend directly:

expected  E907831F80848D1069A5371B402410364BDF1C5F8307B0084C55F1CE2DCA821525F66A4A85EA8B71E482A74F382D2CE5EBEEE8FDB2172F477DF4900D310536C0
aux=None  8801B9FFC7D98703F11E3F1B437D2FBB86082AA6320EB1AA1BA82295526540D691769E03D7379D98C4629925A9B523C0231EDC34387A92156848E7310CAC1A4C   differs
aux=b"\x00"*32  E907831F80848D10…  matches

TaggedHash("BIP0340/aux", bytes(32)) is
54f169cfc9e2e5727480441f90ba25c488f461c70b5ea5dcaaf7af69270aa514, which is
libsecp256k1's ZERO_MASK constant — the value the C code XORs into the key
when aux is NULL, and the value embit's fallback omits.

The open PR that changes what to send

diybitcoinhardware/embit#135
("secp256k1: drop pure-Python fallback, add reproducible Docker build
environment", open since 2026-06-13, by kdmukai) proposes deleting
src/embit/util/py_secp256k1.py and making libsecp256k1 a hard import-time
requirement. Its stated motivation is this exact class of problem — "The pure
Python implementation diverges from libsecp behavior" — citing a divergence
found in
#125.
It also drops the cross-backend parity assertions from test_bindings.py.

If #135 merges, this finding and
the high-s one both cease
to exist as code, and what remains is that released versions carry them. If
#135 stalls, the fallback stays and both need fixing. Either way the finding
is worth sending, because it is the strongest concrete evidence for the
decision the maintainers are currently taking.

Nothing in the tracker covers it: the open issues are miniscript, descriptor
and PSBT items, and #106 ("Document secp256k1 wrapper function
behaviors"), #69 ("Choice of secp256k1 interface") and #56 are the
adjacent discussions.

The issue to open at diybitcoinhardware/embit

Title: Pure-Python schnorr_sign disagrees with libsecp256k1 on the default aux

util/key.py:572's sign_schnorr uses the raw secret key as the nonce
input when aux is None (L594). libsecp256k1's nonce_function_bip340
XORs the key with TaggedHash("BIP0340/aux", bytes(32)) in that case, so
the two backends produce different signatures for the same key and
message:

BIP340 vector 0 (seckey 3, msg all zero)
  expected                E907831F80848D10…
  py_secp256k1, aux=None  8801B9FFC7D98703…
  py_secp256k1, aux=zeros E907831F80848D10…

ec.PrivateKey.schnorr_sign (ec.py:234-235) never passes aux, so every
call through the public API takes this path, and nothing in the API tells
the caller which backend produced a signature.

test_bindings.py:134 asserts exactly this parity, but it is behind
@skipUnless(_SCHNORR_AVAILABLE, ...) and CI never installs libsecp256k1,
so it has never run there.

Both signatures verify, so nothing is broken on-chain — the problem is that
a hardware wallet and a host library agreeing on a key and a message can
disagree on the signature bytes, and any protocol that compares them (or
re-derives a signature to check a device) breaks.

This is another instance of the divergence
#135 is proposed to
end. If #135 is the direction, this needs no code fix and the BIP340
vectors below are still worth having; if the fallback stays, the one-line
fix is below and I am glad to send either.

The PRs, and they are alternatives, one of them already open

PR A — fix the fallback (only if #135 does not land):

• key.py:589-594: when aux is None, mask with the same tagged hash the
  aux is not None branch uses, over 32 zero bytes — i.e. make the default
  aux = bytes(32) rather than "no masking". One expression;
• tests/: add the official BIP340 vector file. tests/ has no BIP340
  vectors today, so correctness rests entirely on the skipped parity test —
  this is the more valuable half of the PR and it stands whichever way var_int.parse accepts non-canonical and truncated encodings, with no size cap #135
  goes;
• ci.yml: a job that builds or installs libsecp256k1 so
  test_bindings.py's parity assertions actually run. Note this conflicts
  with var_int.parse accepts non-canonical and truncated encodings, with no size cap #135, which deletes them.

PR B — support #135 instead. Review it, and add the BIP340 vectors to it
(or as a standalone PR against master that #135 does not touch), so the
capability is tested against the C library rather than the deleted fallback.
Cheaper, aligned with where the maintainers are going, and it leaves nothing
to argue about.

Send the issue first either way: it is evidence for a decision in progress,
and which PR is worth writing depends on the answer.

Verified against btclib d7c4b3d5.