Native-Go authority for the Lux VM state roots — the byte-for-byte
reference the GPU accelerators (CUDA/HIP/Metal/Vulkan/WGSL) match.
- crypto/hash/keccak.go: ComputeKeccak256{,Array} via
sha3.NewLegacyKeccak256 (Ethereum Keccak-256, 0x01 pad) — NOT
sha3.Sum256 (FIPS-202 SHA3, 0x06 pad), which would diverge from the
GPU kernels and split consensus.
- crypto/merkle: Root/LeafHash/NodeHash/EmptyRoot. leaf=keccak(0x00|d),
node=keccak(0x01|L|R), RFC-6962 lone-right promotion, keccak256("")
empty root. Shape depends only on leaf count -> bit-identical to the
gpu-kernels lux::merkle::merkle_root spec across all backends.
Reproduces the spec's 7 canonical KAT vectors byte-for-byte
(n=0,1,2,3,4,5,8). CGO_ENABLED=0 clean, pure-Go, luxfi deps only.
Computation + tests ONLY — consensus wiring (fill xvm StandardBlock.Root
+ executor activation gate) is the separate next phase.
The blake3_c.go cgo block can't switch to #cgo pkg-config: lux-crypto
yet because the install-tree header prefixes symbols with lux_crypto_*
but the dylib still exports brand-neutral crypto_*. Both names exist
in the project at the same time and the .pc bundle binds the wrong pair.
Replace the dated comment with the current state (verified 2026-05-21
against the installed luxcrypto.dylib) and the exact conditions for
flipping over to pkg-config (either re-prefix the dylib OR drop the
prefix from the install header).
No functional change: the workaround #cgo lines are the same shape, only
the explanatory comment is updated to match reality.
Domain separation tags and identifiers in cryptographic code must be
readable in a scientific paper without product context. Strip the Lux
brand from in-code crypto identifiers; algorithm names ARE the namespace.
DSTs (golden vectors regenerated):
pedersen NewGenerators: LUX_PEDERSEN_{G,H} -> PEDERSEN_{G,H}_V1
pedersen NewGeneratorsFromSeed: LUX_PEDERSEN_SEEDED_GEN_V1 -> PEDERSEN_SEEDED_GEN_V1
pedersen golden G/H test vectors recomputed for the new DST.
Env vars (one canonical name only — no deprecated alias):
backend.envBackend: drop LUX_CRYPTO_BACKEND fallback, CRYPTO_BACKEND only
rust/build.rs: drop LUX_CRYPTO_DIR / LUX_CRYPTO_BUILD_DIR fallbacks
Rust c-abi link names:
lux-crypto-keccak: extern "C" name keccak256 (was lux_keccak256)
lux-crypto-secp256k1: secp256k1_ecrecover{,_batch} (was lux_*)
lux-crypto umbrella: drop all #[link_name = "lux_*"] attrs;
the canonical luxcpp/crypto C-ABI exports brand-neutral symbols
directly, the Rust function names mirror them one-for-one.
Go cgo aliases:
hash/blake3/blake3_c.go: drop the four #define aliases that mapped
crypto_* -> lux_crypto_*; the C header now declares brand-neutral
names directly.
Tests passing:
lux/crypto: 50 packages ok, 0 fail (GOWORK=off go test ./... -short)
rust workspace: 18 tests across 3 crates (CRYPTO_BUILD_DIR=... cargo test --release)
Changed build tag from `//go:build cgo && darwin` to `//go:build gpu && darwin`
so that CGO code requiring luxcpp/crypto is only compiled when explicitly
building with the gpu tag.
This allows the pure Go implementation (using zeebo/blake3) to be used
by default without requiring native library dependencies.
- Change CGO files to use luxgpu tag (opt-in)
- Change pure Go files to use !luxgpu tag (default)
- Fix relative paths to luxcpp/crypto headers
This allows CGO=0 and CGO=1 builds to work without requiring
the full GPU libraries to be installed.
Add stub implementations for GPU packages that return
false for Available() when GPU libraries are not present.
This allows building with CGO_ENABLED=0 or CGO_ENABLED=1
without requiring Metal/CUDA libraries.
- bls/gpu/gpu_stub.go
- hash/blake3/gpu/gpu_stub.go
- hash/poseidon2/gpu/gpu_stub.go
- pqcrypto/*/gpu/gpu_stub.go (mldsa, mlkem, slhdsa)
The hash package is the canonical implementation.
The hashing package now re-exports from hash for backwards compatibility.
New code should import github.com/luxfi/crypto/hash directly.
zeekay