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.
Hanzo AI