The earlier draft listed secp256k1 as a hard violation. That was a
misread. /Users/z/work/lux/crypto/secp256k1/secp256k1.go (build tag
!cgo) is a complete vanilla Go canonical via decred/dcrd/dcrec/secp256k1/v4
covering Sign / RecoverPubkey / VerifySignature / DecompressPubkey /
CompressPubkey -- byte-for-byte parity verified with the cgo libsecp256k1
backend on KAT (deterministic RFC 6979 k, fixed seckey, fixed message;
sig + recovered pub identical between backends).
This matches the audit's own legend (line 16): established Go crypto
crates count as vanilla; decred secp256k1 is in the same class as
circl, gnark-crypto, x/crypto.
Hard violation count drops 4 -> 3. The remaining hard violations are
blake3 (missing), verkle (re-export wrapper), banderwagon (empty dir).
Backend status verified 2026-04-27:
vanilla (CGO_ENABLED=0): tests pass; sign 67us, recover 362us, verify 557us
cgo libsecp256k1: tests pass; sign 24us, recover 63us, verify 56us
cgo is faster (~3-10x) and stays as opt-in accelerator. Both produce
identical signatures.
Read-only enumeration of canonical paths across luxcpp/crypto and
lux/crypto. Documents 4 hard violations (blake3 missing, verkle as
upstream re-export, banderwagon empty, secp256k1 cgo-primary) plus
6 luxcpp C++/CPU body gaps and 14 Rust binder gaps.
P0 work to author: verkle, secp256k1, blake3, banderwagon vanilla Go
bodies. Source-to-port cited per file.
Hanzo AI