Adds GitHub Actions CI on push to main/dev + PRs:
- go build ./...
- go test -count=1 -short -timeout 300s ./...
- go vet ./...
- govulncheck (non-blocking, reports advisories)
GOWORK=off per repo convention.
PN10QP27 (~128-bit security) drives a full BlindRotate inside
lattice/v7@v7.1.0 — ~22s on Apple silicon. Comment added so future
maintainers don't mistake the test wall-clock for a hang.
Detailed invention disclosures are sensitive pre-filing material. Moved to
lux-private/patents to preserve international filing rights (EU/JP/KR/CN
absolute-novelty rule). Cross-ref: github.com/lux-private/patents/bundles/
CRYPTOGRAPHER-SIGN-OFF.md captures the Tier A artifact review:
- APPROVED WITH GATES for F-Chain TFHE (LP-066/LP-134) and the
threshold-FHE compliance package (LP-019/LP-076/LP-167)
- Verified green: build, dudect bridges build, EC theories 0/0
admits, Lean 0 sorry, bridge map cites each axiom, Jasmin
algorithm shape correct, CT obligations correctly stated
- 4 minor findings, 2 informational
- 4 open gates:
GATE-1: dudect submission-grade run (10^9 samples)
GATE-2: jasminc -checkCT pass on production Jasmin
GATE-3: deployment runbook for F-Chain TFHE
GATE-4: Lean tactic-script transcription of EC proof
None of the gates require algorithm or code change; they are
about empirical confirmation and operational disclosure.
Empirical constant-time analysis harness mirroring the Pulsar
pack at ~/work/lux/pulsar/ct/dudect/:
encrypt_ct.go + dudect_encrypt.c - cgo bridge + C main loop
decrypt_ct.go + dudect_decrypt.c - the CT-critical routine
bootstrap_ct.go + dudect_bootstrap.c - PBS composite
CT population (operational framing):
- Both classes are VALID inputs to the routine under test
- Class A is a fixed input; class B is uniformly drawn from a
pre-built pool of K independent valid inputs
- Any timing difference is a real secret-content signal
All three cgo shared libraries build clean:
GOWORK=off go build -buildmode=c-shared -tags tfhe_encrypt_ct
GOWORK=off go build -buildmode=c-shared -tags tfhe_decrypt_ct
GOWORK=off go build -buildmode=c-shared -tags tfhe_bootstrap_ct
dudect.h fetched on demand via fetch.sh (not committed).
dudect_compat.h supplies _mm_mfence/__rdtsc on AArch64 hosts.
Submission-grade run pending (GATE-1 in CRYPTOGRAPHER-SIGN-OFF.md).
proofs/lean-easycrypt-bridge.md pins the 1:1 correspondence between
the EasyCrypt theory axioms in fhe/proofs/easycrypt/ and the Lean
theorems in ~/work/lux/proofs/lean/Crypto/FHE/TFHE.lean +
Crypto.Threshold.Lagrange.
Maps 5 axioms:
pbs_correctness <-> programmable_bootstrap_correct
shamir_inverse_eval <-> threshold_reconstructs_secret
reshare_preserves_secret <-> reshare_preserves_constant_term
pbs_noise_bound <-> pbs_noise_bound
decrypt_constant_time <-> (operational; no Lean counterpart)
EasyCrypt Tier A theories at fhe/proofs/easycrypt/:
TFHE_Correctness.ec - PBS correctness theorem
TFHE_Threshold_Keygen.ec - threshold-DKG correctness + privacy + reshare
TFHE_Noise_Growth.ec - per-op noise budgets + parameter-set invariant
lemmas/TFHE_CT.ec - CT obligations on hot path
Closure strategy: each top-level theorem reduced to small set of named
functional hypotheses imported from the luxfi/lattice/v7 reference
layer. Admit budget 0/0 across the pack.
Bridge map at proofs/lean-easycrypt-bridge.md pins axiom-to-theorem
correspondence 1:1 to Lean Mathlib (Crypto.Threshold.Lagrange).
Cites existing LaTeX at ~/work/lux/proofs/fhe/correctness.tex,
parameter-security.tex, dual-runtime-equivalence.tex.
Single LICENSING.md file referencing the canonical three-tier IP and
licensing strategy at github.com/luxfi/.github/blob/main/profile/README.md.
LICENSE file is unchanged; this only adds a navigational pointer.
Drop local SecurityProfile, ProfileClassical128, ProfileStrictPQ,
ProfileStrictPQHighValue, IsPostQuantum, String,
ProfileFromPQFlag. The strict-PQ Mode vocabulary lives in
github.com/luxfi/pq as the single source of truth across warp,
dex, evm, fhe, zap.
DefaultParamsForProfile (local enum) → DefaultParamsForMode
(pq.Mode): strict-PQ ⇒ PN9QP27_STD128Q (NIST FIPS 203 / 204
LMKCDEY); classical / hybrid ⇒ PN10QP27 (~128-bit classical,
dev-only). The FHE gate is parameter SELECTION, not refusal — no
classical ciphertext to refuse at the parameter layer, so the
ValidateMode call doesn't apply here.
ProfileStrictPQHighValue dropped: it was a no-op tier returning
the same PQ literal as the base strict-PQ profile. Once
STD192Q_LMKCDEY-aligned ParametersLiterals land, callers pick
them explicitly — the mode vocabulary stays single-purpose.
Single seam every Liquid FHE chain boot routes through to pick a
ParametersLiteral. Direct references to PN10QP27 / PN11QP54 /
PN9QP27_STD128Q in chain-config code are a bug — they bypass the
profile gate and can silently weaken the chain to classical-only
security.
ProfileClassical128 → PN10QP27 (~128 bit *classical*)
ProfileStrictPQ → PN9QP27_STD128Q (128 bit *quantum*,
OpenFHE STD128Q_LMKCDEY-aligned)
ProfileStrictPQHighValue → PN9QP27_STD128Q today; will return
STD192Q_LMKCDEY-aligned params once
published, no consumer churn
ProfileFromPQFlag(pq bool) wires this onto the chain-config "pq"
boolean the liquidity/operator writes into
/data/configs/chains/<id>/config.json. The Liquid FHE plugin reads
"pq":true from that file and asks DefaultParamsForProfile — strict-PQ
chains get STD128Q_LMKCDEY parameters at chain boot, with no
direct PN10QP27 reference anywhere on the boot path.
Tests pin the security guarantee byte-for-byte: ProfileStrictPQ
returns PN9QP27_STD128Q (not "some PQ literal" — the exact one), so a
regression that swaps the underlying literal name requires an
explicit test update.
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