wire/wire.go — fhe's wire-format hardening boundary. FHE wire formats
nest deeper than pulsar's (CKKS ciphertext = Vec<Poly> over RNS chain
of Vec<u64>) so MaxDepth = 5 + larger MaxFrameBytes (32 MiB) reflect
the deeper polynomial structure.
Tests:
* TestValidateCiphertextFrame_RejectsHugeLength — regression for
lattice issue #4 attack input class. Same substrate, same
rejection.
* TestValidateCiphertextFrame_OverCap — MaxFHESliceLen+1 rejected.
go.mod adds luxfi/math v1.3.0 dependency.
This completes Phase 5 of LP-107: every Lux Go protocol repo
(pulsar, lens, fhe, lattice) now consumes the math substrate for
bounded wire decoding. The same lattice issue #4 attack input is
rejected identically across all four consumers.
Lands the Lux FHE-KAT corpus generators consumed by the C++ production
runtime at github.com/luxfi/luxcpp/crypto/fhe (LP-167). Mirrors the
pulsar/lens/warp regen script shape; emits a sha256 manifest and
supports --verify mode for determinism diffing.
Delivered:
cmd/kat_oracle/main.go KAT oracle. --emit --out <dir>
writes one JSON entry per
(param_set, seed) tuple. Each
entry pins parameter-set ID,
seed, operation tag, and a
CRC32 fingerprint of the SHA-256
digest of the canonical SecretKey
MarshalBinary output.
scripts/regen-kats.sh Driver: runs kat_oracle, runs the
in-tree determinism tests
(TestNewKeyGeneratorFromSeed_Deterministic
+ TestNewKeyGeneratorFromSeed_DifferentSeeds),
emits manifest. --verify mode
diffs against existing manifest;
fails on mismatch.
scripts/regen-kats.manifest.sha256 Initial 4-entry manifest:
PN10QP27 / PN11QP54 × seed-zero /
seed-lp167-stable.
Verification:
$ LUXCPP_DIR=$HOME/work/luxcpp scripts/regen-kats.sh --verify
OK: Lux FHE KAT regeneration is byte-equal across runs (4 files)
$ cd \$HOME/work/luxcpp/crypto/fhe
$ ctest --test-dir build -R fhe_kat_replay
OK lux-fhe-cpp KAT replay (4 entries)
LP-167 §"Cross-runtime KAT contract" requires both directions of
byte-equality. The Go→C++ direction is exercised by this commit and
the C++ replay test. The reverse direction (C++ generates, Go
verifies) is queued behind v0.1.0-rc2-fhe-gpu in lockstep with the
production CUDA NTT + key-switch + bootstrap kernels.
go test -count=1 -timeout=300s ./... -> 3/3 ok
ok github.com/luxfi/fhe 48.345s
ok github.com/luxfi/fhe/pkg/encrypted 98.833s
ok github.com/luxfi/fhe/pkg/threshold 0.778s
Document fhed's two operating modes (standalone + threshold) explicitly
in cmd/fhed/README.md. fhed never reaches across the network for crypto
state — both modes are self-contained.
Add cmd/fhed/standalone_test.go behind the integration build tag. It
builds fhed, starts it on a free port with a fresh data dir, waits for
/v1/fhe/health, and round-trips an encrypted bit through the HTTP API.
Run: go test -tags=integration ./cmd/fhed/... -count=1 -timeout 180s
Honest scope-limit: the test currently fails on bootstrap-key persistence
("max slice length exceeded" from zapdb). The bug is upstream of this
change — fhed itself cannot complete first-time keygen on any parameter
set against current zapdb. Test is correct against the documented API
and will go green once the zapdb blob-size cap is raised in
github.com/luxfi/database.
Exports NewCmd() returning a cobra.Command with keygen, encrypt,
decrypt, and eval subcommands. Wires directly to fhe.KeyGenerator,
fhe.Encryptor, and fhe.Decryptor -- no stubs.
Operators can't see your data. Nobody can decrypt without t-of-n MPC approval.
Regulators can force-decrypt via legal process (threshold approval flow).
Endpoints:
POST /v1/vault/store encrypt + store (operator sees only ciphertext)
GET /v1/vault/list list records (all encrypted, no plaintext)
POST /v1/vault/request request decryption (starts approval process)
POST /v1/vault/approve/{id} MPC key holder approves (t-of-n threshold)
GET /v1/vault/reveal/{id} get plaintext (only after threshold met)
GET /v1/vault/audit full audit trail of all requests + approvals
POST /v1/vault/compute homomorphic computation on encrypted data
Architecture: FHE public key encrypts. Secret key Shamir-split across N MPC nodes.
No single party (including operator) can decrypt. Social/legal process required.
Each demo is a sovereign app: go run ./cmd/demos/<name> serve
darkpool: /v1/orders, /v1/match, /v1/reveal — encrypted order matching
compliance: /v1/portfolio, /v1/check — SEC diversification on encrypted holdings
marketmaker: /v1/quotes, /v1/best — private market making
auction: /v1/bids, /v1/determine-winner, /v1/reveal — sealed-bid auction
voting: /v1/votes, /v1/tally, /v1/result — encrypted shareholder voting
nav: /v1/holdings, /v1/compute — confidential fund valuation
proof: /v1/positions, /v1/prove — compliance proofs without revealing data
All use Base embedded SQLite + admin UI at /_/. FHE key material
stored in Base's encrypted collections. Original FHE logic preserved.
F13: Add EncryptSafe(bool) (*Ciphertext, error) that returns errors instead of
panicking. Existing Encrypt(bool) is preserved but deprecated -- it now calls
EncryptSafe internally.
F07: Remove data-dependent branch (if hi == 0) from mulModBarrett. Always
execute the full 128-bit reduction path to eliminate timing side-channel.
Bug 1: PN11QP54 used 0x3FFFFFFFFFC0001 which factors as 67*1447*6571*452444119.
Replaced with 0x3FFFFFFFFED001 (prime, 54-bit, Q ≡ 1 mod 4096).
Bug 2: findPrimitiveRoot only checked g^((Q-1)/2) != 1 but must check
g^((Q-1)/p) != 1 for ALL prime factors p of Q-1. Added primeFactors()
to compute distinct prime factors.
Also fixed: div128 overflow for Q > 32 bits (now uses math/bits.Div64),
mulModBarrett correctness for large Q, and INTTInPlace twiddle indexing.
Replace flat-file key storage (secret.key, public.key, bootstrap.key)
with encrypted ZapDB (ChaCha20-Poly1305). All FHE key material is now
stored in a single encrypted database at <dataDir>/zapdb/.
New pkg/store package wraps luxfi/database/encdb for:
- Secret/public/bootstrap key storage (encrypted at rest)
- Ciphertext cache by content hash
- Metadata storage
New --password flag (or FHED_PASSWORD env) for ZapDB encryption.
Both standard and threshold modes use ZapDB.
- data-seal: Verifiable Data Integrity Seal (PIP-0010/LP-0535)
FHE-encrypted tamper-proof sealing with Public/ZK/Private modes,
batch sealing, homomorphic verification
- content-provenance: AI & Media Content Provenance (PIP-0011/LP-7110)
Model manifests, output attestation via homomorphic comparison,
media derivation DAGs
- encrypted-crdt: Encrypted CRDT (PIP-0013/LP-6500)
LWW-Register with FHE values, OR-Set with tag-based add/remove,
Lamport timestamp conflict resolution, deterministic merge
- shadow-governance: Shadow Government Protocol (PIP-7010)
Anonymous ministries, encrypted voting with homomorphic tallying,
nullifier-based anti-fraud, quorum enforcement
Each example includes Solidity contracts, Hardhat tests, CLI tasks,
and README linking to corresponding PIP and LP specifications.
Six production-ready example applications demonstrating the FHE library:
- cmd/seal: document integrity sealing with encrypted verification
- cmd/vote: encrypted voting system with threshold tallying
- cmd/mediaseal: media content authentication with FHE
- cmd/provenance: AI model provenance tracking with encrypted attestation
- cmd/crdt: encrypted LWW-Register for fheCRDT architectures (LP-6500)
- cmd/stats: secure multiparty statistics over encrypted data
Also pins luxfi/mdns to v0.1.0 and excludes compiled binaries from git.
Remove all submodules and non-Go content.
JS SDKs, plugins, templates, and examples live in their own repos.
Kept:
- Go FHE library (*.go)
- cmd/, pkg/, internal/
- docs/, bin/
Hanzo AI