All FHE backend infrastructure (Torus compiler, ML SDK, TFHE runtime,
KMS, FHEVM) lives under the luxfhe org. luxfi/* repos are reserved for
the Lux-blockchain integrated surfaces (precompiles, coprocessor, core
FHE Go library).
Removes:
docs/workshop/fhevmjs/ (Zama JS package name; reencrypt + ABI demo)
docs/workshop/pyfhevm/ (Python wrapper around fhevm-tfhe-cli)
Both directories shelled out to upstream tooling that isn't part of
the Lux stack — fhevmjs (Zama's JS SDK) and fhevm-tfhe-cli (Zama's
CLI for TFHE-rs). The clients were also broken on a clean checkout
since neither tool ships with this repo.
Workshop Solidity examples are unchanged (erc20.sol +
eip712-reencrypt.sol — these are stable references). README is
replaced with a placeholder pointing at the Torus compiler /
Lux FHE Coprocessor as the canonical client path; we will re-add
the workshop client when Torus ships.
Naming map followed for replacement copy:
Lux FHE — umbrella product
Lux FHEVM — canonical EVM product
Lux FHE Precompiles, Coprocessor, GPU
Torus — compiler / framework brand
Drops the "Not a wrapper around tfhe-rs, not a binding to Zama, not a port of
OpenFHE" disclaimer in favor of stating what Lux FHE IS: a from-scratch TFHE
implementation in Go on luxfi/lattice, with optional C++ / GPU / FPGA accel
paths. No external library dependency.
Same change applied to the related papers + docs + skills in parallel
commits across lux/papers, lux/docs, lux/skills.
Adds the canonical noise-flooding threshold-decryption primitives that
upstream consumers (notably luxfi/threshold/protocols/tfhe) need to
implement true M-of-N FHE decryption without any party holding the
master key.
- ShareLWESecretKey: Shamir-splits the LWE secret coefficient-by-
coefficient over Z_q. No party ever sees the master.
- PartialDecryptLWE: party j computes d_j = c_1 · s_j + e_j with
fresh smudging noise from a discrete Gaussian.
- CombineLWE: integer-Lagrange (Bendlin-Damgård denominator clearing)
+ Δ^{-1} mod q to recover the plaintext polynomial.
- SmudgingSigma: tight noise calibration against the worst-case
integer Lagrange numerator, so Λ_max · σ · √t · 6 ≤ Q/16.
Decomplecting note: this LSSS-over-Z_q lives next to the existing
LSSS-over-RFC-3526-prime in pkg/threshold. The two are different
primitives — large-prime LSSS shares high-entropy secrets where the
secret space need not equal the FHE modulus; Z_q LSSS composes
directly with lattice arithmetic. Both stay in this package.
Decryption follows Bendlin-Damgård (TCC 2010, §4.2) and Asharov-Jain-
López-Alt-Tromer-Vaikuntanathan-Wichs (EUROCRYPT 2012, §4). Noise
flooding is the simulation-soundness mechanism.
Verified by round-trip tests at (t, n) ∈ {(2, 3), (5, 9), (11, 21)},
below-threshold negative test, share-doesn't-equal-master regression
guard, dedup guard, cross-parameter guard, and combine-determinism
test. All 8 new threshold tests pass.
Also adds public accessors:
- fhe.Parameters.ParamsLWE/ParamsBR — expose underlying rlwe.Parameters
so out-of-tree threshold callers can drive lattice primitives
against the same parameter set the encryptor uses.
- fhe.BitCiphertext.Bits / NewBitCiphertextFromBits — iterate per-bit
for threshold decryption without round-tripping MarshalBinary.
References:
- Bendlin, Damgård. Threshold Decryption and Zero-Knowledge Proofs
for Lattice-Based Cryptosystems. TCC 2010.
- Asharov, Jain, López-Alt, Tromer, Vaikuntanathan, Wichs. Multiparty
Computation with Low Communication, Computation and Interaction
via Threshold FHE. EUROCRYPT 2012.
- Mouchet, Troncoso-Pastoriza, Bossuat, Hubaux. Multiparty
Homomorphic Encryption from Ring-Learning-with-Errors. PETS 2021.
Adds the canonical noise-flooding threshold-decryption primitives that
upstream consumers (notably luxfi/threshold/protocols/tfhe) need to
implement true M-of-N FHE decryption without any party holding the
master key.
- ShareLWESecretKey: Shamir-splits the LWE secret coefficient-by-
coefficient over Z_q. No party ever sees the master.
- PartialDecryptLWE: party j computes d_j = c_1 · s_j + e_j with
fresh smudging noise from a discrete Gaussian.
- CombineLWE: integer-Lagrange (Bendlin-Damgård denominator clearing)
+ Δ^{-1} mod q to recover the plaintext polynomial.
- SmudgingSigma: tight noise calibration against the worst-case
integer Lagrange numerator, so Λ_max · σ · √t · 6 ≤ Q/16.
Decomplecting note: this LSSS-over-Z_q lives next to the existing
LSSS-over-RFC-3526-prime in pkg/threshold. The two are different
primitives — large-prime LSSS shares high-entropy secrets where the
secret space need not equal the FHE modulus; Z_q LSSS composes
directly with lattice arithmetic. Both stay in this package.
Decryption follows Bendlin-Damgård (TCC 2010, §4.2) and Asharov-Jain-
López-Alt-Tromer-Vaikuntanathan-Wichs (EUROCRYPT 2012, §4). Noise
flooding is the simulation-soundness mechanism.
Verified by round-trip tests at (t, n) ∈ {(2, 3), (5, 9), (11, 21)},
below-threshold negative test, share-doesn't-equal-master regression
guard, dedup guard, cross-parameter guard, and combine-determinism
test. All 8 new threshold tests pass.
Also adds public accessors:
- fhe.Parameters.ParamsLWE/ParamsBR — expose underlying rlwe.Parameters
so out-of-tree threshold callers can drive lattice primitives
against the same parameter set the encryptor uses.
- fhe.BitCiphertext.Bits / NewBitCiphertextFromBits — iterate per-bit
for threshold decryption without round-tripping MarshalBinary.
References:
- Bendlin, Damgård. Threshold Decryption and Zero-Knowledge Proofs
for Lattice-Based Cryptosystems. TCC 2010.
- Asharov, Jain, López-Alt, Tromer, Vaikuntanathan, Wichs. Multiparty
Computation with Low Communication, Computation and Interaction
via Threshold FHE. EUROCRYPT 2012.
- Mouchet, Troncoso-Pastoriza, Bossuat, Hubaux. Multiparty
Homomorphic Encryption from Ring-Learning-with-Errors. PETS 2021.
Adds NTTEngine.NTTBatch / INTTBatch that dispatch to luxfi/lattice/v7/gpu
(Metal on darwin, CUDA on linux/NVIDIA) when:
1. CGo is on and a GPU device is reachable (lattice/gpu.GPUAvailable())
2. The engine's (N, Q) has passed a deterministic byte-equality probe
against the CPU subring NTT oracle (cached per (N, Q))
Otherwise falls back to per-polynomial CPU subring NTT. The probe ensures
a GPU context with different convention encoding (Montgomery vs standard,
bit-reversed vs natural) is rejected before it can corrupt ciphertexts.
No `gpu` build tag. CGo is the only compile-time gate.
Tests: ntt_gpu_test.go::TestNTTBatch_ByteEqualToInPlace (probe enforces
byte equality), TestINTTBatch_RoundTrip (INTT(NTT(x)) == x).
The 8 demo mains imported github.com/hanzoai/base (HTTP server scaffold)
which pulled the legacy Google Cloud / temporal / grpc transitive chain.
Demos were the only consumers of that chain in the fhe tree.
One way only: fhe is a cryptographic library, not an app harness. App
authors who want HTTP wiring can vendor hanzoai/base directly in their
own cmd binary — fhe doesn't ship that scaffold.
The 8 demo mains import github.com/hanzoai/base which pulls grpc
transitively via the legacy Google Cloud SDK chain. grpc is opt-in
only across the Lux stack, so demos follow the same discipline:
build with -tags demos.
Default fhe build: 0 grpc / 0 google cloud.
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.
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.
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.
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.
hanzo-dev