Parameters

Where the parameters in Spec diverge from what is true: the published values were corrected by an erratum, the claimed security is higher than anyone has measured, and the DMux/CMux noise bound — per Yue’s feedback — doesn’t hold for the paper’s own key distribution. Every value is tagged by where it comes from; the Fix page closes these.

The contested values, at a glance

Where the three sources disagree, that disagreement is the finding. The rest of this section gives the full numbers; this table is the map.

↑

The correctness budget

paper The target is a decryption-failure rate \(\le 2^{-40}\) (§5.1, and Appendix C.2, p.27). Correctness holds as long as the final accumulated error stays under the decode threshold; the paper's stated condition (App C.2, p.27) is

\(\lVert E_{\text{final}}\rVert_\infty \le \lfloor (q_3-q_4)/p\rceil/2 - 1\),   with   \(\Pr[\text{fail}] \le \operatorname{erfc}\!\big(\tfrac{\lfloor(q_3-q_4)/p\rceil/2-1}{\sqrt{2\,\theta_{\text{ans}}}}\big)\).

The error variance \(\theta_{\text{ans}}\) is built up by a per-stage recursion (App C.2, pp.26–27) that mirrors the pipeline. Each stage adds its own term; the load-bearing ones:

Two things make this budget the crux for an implementer:

1. The shipped bases don't certify \(2^{-40}\). Security review With the erratum bases the authors compute \(\log_2 P_{\text{fail}}\approx-43.4\) (32 GiB), clearing the target. code But the code ships the draft bases (55879 / 81 / 8) — larger bases mean a larger \(q^2/(12 B^{2\ell})\) gadget-noise term — so the very computation that meets \(2^{-40}\) does not apply to the shipped parameters (A1).

2. The code and the paper measure against different thresholds. code Decryption rescales the answer to \(q_4\) and decodes there, so the effective margin is \(\Delta/2 = (q_4/p)/2 = (4096/16)/2 = 128\). paper The Appendix-C condition above evaluates to \(\lfloor(8380417-4096)/16\rceil/2-1 = 261759 \approx 2.6\times10^5\) — about \(2000\times\) larger. Security review Yue Chen argues the \(q_4/p\) form (what the code does) is the correct one, citing SpiralPIR Thm 2.11 and SimplePIR Thm C.1. inference So the code is on the conservative (likely-correct) side, but the paper's proof certifies a margin the code does not use — and whether the real noise stays under \(128\) at the paper's \(\sigma\) and database size is never tested (every test runs ternary keys on a 2×2 DB; A3, VB-1).

↑

The security target

Security rests on the hardness of the underlying RLWE/MLWE instances. Hardness is governed by the triple \((n, q, \sigma)\): it rises with the ring dimension \(n\) and with the relative noise \(\sigma/q\) — so, for fixed \(n\) and \(\sigma\), raising \(q\) lowers security. That is the same lever that buys correctness headroom, which is why the two targets pull against each other. paper Crucially, VIA has more than one instance to satisfy: the big ring \(\mathcal R_{n_1,q_1}\) and the small ring are separate assumptions (the MLWE/LWE parameters are aligned to the big ring), and each must independently clear the target (§5.1, p.16).

Here the three sources give three different numbers for the same quantity:

inference Read through our own estimator — the only number we treat as authoritative (Fix) — the 110 is a claim to be checked, not a fact: code on the paper's Gaussian parameters via-estimator gives \(\approx\!95\text{–}96\) bits (the reviewers and malb put those same params nearer 110; we read our conservative ~95 as a floor, not a contradiction). On the ternary keys via-rs actually runs it gives \(\approx\!77\) bits (binding small ring; lib.rs:223-235). The reviewers' OpenFHE run on the authors' C++ owniai/VIA got 88/72: a third, separate artifact. unverified Those 88/72 figures are on the reviewers' authority, were not re-run here, and the 88/72-vs-big/small mapping is a positional reading of the review note. The hazard this page exists to flag: the code asserts 128 — higher than even the paper's claimed 110, and ~50 bits above what our estimator measures on the shipped ternary keys — with no derivation behind it (A2): a reader trusts a constant no tool ever produced.

For an implementer: treat the security level as derived, never asserted. Run an estimator on your exact \((n, q, \sigma)\) for every ring and every variant you ship, and gate CI on it: the one number you must not hard-code is the one that says you are safe. code via-rs now does this: the via-estimator crate (cargo run -p via-estimator) reports a calibrated core-SVP estimate per ring on the shipped presets and gates CI — so the hard-coded security_param is cross-checked against a real estimate rather than trusted. See the Fix page for the derived ≥120-bit set.

↑

Caveats for implementers

If you are porting or re-instantiating VIA, these are the traps the three sources together expose: each links to where it bites in the audit.

1. The published Table 6 gadget bases are draft values. Use the authors' erratum bases, not the ones printed in the paper (and shipped in the code); the \(2^{-40}\) correctness claim only holds with the corrected, smaller bases. The gadget base is the dominant noise lever, so this is not cosmetic. (Audit A1, VB-2.)
2. Do not trust a hard-coded security level — derive it. Run a lattice estimator on your exact \((n, q, \sigma)\) for every ring and every variant; both the big and the small ring are independent LWE instances and both must clear your target. Don't take the paper's 110 as given: our own via-estimator reads the shipped ternary keys far lower (see Security target above). (Audit A2.)
3. The final-ring budget is small; pick the conservative decode threshold and test against it. Decode against \(\Delta/2 = (q_4/p)/2\), not a \((q_3-q_4)/p\) budget, and add an assertion that the accumulated noise actually stays under it. (Audit A5.)
4. Wire the key/error distributions through from the parameters. A preset that declares Gaussian keys but samples ternary is a silent footgun: the security and noise story becomes decorative. And if you do use large-\(\sigma\) keys, re-derive the CMux/DMux noise: the TFHE-style lemmas assume a binary key and omit an \(\mathbb E[s_i^2]\) factor. (Audit A4.)
5. Parameters are per-database-size. \(I\) and \(J\) set how many noisy terms are summed, so a set that decrypts correctly at 1 GB can fail at 32 GB. Validate at your target dimensions with the real \(\sigma\), not on a toy 2×2 database with ternary keys. (Audit A3, VB-1.)
6. Respect the algebra. Rings are powers of two for the NTT, and a modulus that the paper writes as a prime square cannot be CRT-split into RNS channels: substitute two distinct NTT-friendly primes of the same size. (Audit A6.)
7. VIA-B inherits every VIA-C parameter caveat (its repack and prefix run on the same rings) and adds one: the repack recursion is \(\log_2(T\,n_1/n_2)\) levels deep, which the paper's \(\theta_{rep}\) noise formula slightly undercounts at the production batch size. (VB-3.)

↑