Parameters

What VIA’s parameters are: the knobs, the security↔correctness tension behind every choice, the descending modulus chain, and the value tables (paper alongside what the code sets). Where these diverge from what’s true — the security shortfall, the correctness bug — is the Gaps page.

Overview

VIA is not a single parameter set; it is a recipe for choosing one, valid only when it clears the security and correctness checks together (the Primer lays out that model). This page is the recipe itself: the knobs, why the two checks pull against each other, the descending modulus chain, and the value tables: the paper’s numbers alongside what the code sets. Where those values fail a check is the Gaps tab.

The short version of the divergence: inference the code faithfully ships the published paper, but the published paper's gadget bases were a draft the authors later corrected, and the published security level is higher than what reviewers measured on the authors' own implementation. So "matches the paper" and "is correct/secure as intended" are not the same statement here — see the Audit for the severity-ranked consequences.

↑

The knobs

VIA is built on RLWE/MLWE, so its parameters are the usual lattice-encryption knobs plus a few PIR-specific ones. Grouped:

↑

The security ↔ correctness tension

This is the whole game: the levers point in opposite directions. Reading the table, "turn up" means increase that one knob holding the others fixed.

So "make decryption reliable" pulls toward big \(q\), small \(\sigma\), small gadget bases, many digits, small database; "make it secure" pulls toward big \(n\), big \(\sigma\), modest \(q\). Parameter selection is the joint optimization that clears both targets while keeping communication small. inference The reason VIA can do this with modest parameters at all is that its two signature tricks — the DMux tree for query expansion and the LWE→RLWE conversion with only \(O(n\log n)\) noise growth — keep noise growing logarithmically in the database size instead of linearly.

↑

The modulus chain

VIA does not use a single modulus; it uses a descending chain \(q_1 > q_2 > q_3 > q_4 > p\), mod-switching down between stages. Mod-switching from \(q_i\) to \(q_{i+1}\) multiplies both the value and the noise by \(q_{i+1}/q_i\), and rewrites each coefficient into fewer bits. Two payoffs follow:

• Communication. The answer is squeezed to a small modulus before being sent, so each coefficient costs fewer bits: VIA's headline metric is response size.
• The budget travels with the modulus. The query rides at the big \(q_1\) (where the LWE→RLWE conversion needs room); the first-dimension sum happens at \(q_2\); response compression walks \(q_2\!\to\!q_3\!\to\!q_4\). The final decode happens at \(q_4\), where in VIA-C \(\Delta/2=(q_4/p)/2\) is only on the order of a hundred: a tiny budget that works precisely because the noise was scaled down the chain alongside the modulus.

inference The practical consequence: the final-ring budget is small and unforgiving, so the question "exactly which threshold does decode compare against?" — \(q_4/p\) vs \((q_3-q_4)/p\) — is not pedantic; it changes the certified margin by a large factor (see Correctness budget and Audit A5).

↑

The parameter values

One structural fact first, because it shapes every table below: code the repository has no plain-VIA protocol preset: the wired end-to-end presets are all VIA-C / VIA-B: REALISTIC_PARAMS (paper-scale), SECURE_PARAMS (the ≥120-bit set — see Fix), and the VIA-B REALISTIC_B_PARAMS. The plain-VIA numbers appear only as paper::Via* moduli aliases used in low-level NTT/RNS unit tests, never in a PIR pipeline. So in the "code" column the VIA values are never exercised end-to-end and the live numbers are VIA-C / VIA-B. Tables below show the REALISTIC (paper-scale) instantiation, \(n_1=2048,\ n_2=512\); the secure \(n_1=4096\) set is on the Fix page.

Rings & modulus chain

Source: paper Appendix B, p.22 (moduli) & §5.1, p.16 (dimensions); code basis.rs (q1 primes), modulus.rs (q2–q4, p), presets.rs. inference Caveats: the code's VIA-C moduli match the paper exactly; only plain-VIA's \(q_1\) diverges (square vs two primes). \(n_3\) is never given a number in the paper.

Distributions (secret key \(\chi_S\), error \(\chi_E\))

Source: paper §5.1, p.16; code presets.rs:158-164, client.rs:93-105. inference Two traps here: the paper prints the small-ring \(\sigma\) under a typo'd \(\sigma_{1,E}\) subscript (it is \(\chi_2\)'s, not the big ring's); and the code's \(\sigma=1.0\) fields are never read: the actual key/error is ternary, so neither the paper's \(\sigma\) nor the preset's \(1.0\) is what runs (A4).

Gadget parameters

This is where "matches the paper" and "is correct as intended" come apart. The lengths \(\ell\) are unchanged across draft and erratum (so performance/key-size is identical); only the bases \(B\) moved, and the base is what governs the noise. VIA-C / VIA-B:

Source: paper Table 6, p.23 (draft); Security review VIA authors' May-11 erratum ("Table 6 … were inadvertently left at draft values"), \(\log_2 P_{\text{fail}}\approx-43.4\) at 32 GiB with the corrected bases; code presets.rs:150,153,156 (unchanged at the audited commit: erratum not adopted). inference The code ships the draft bases, which the authors' own analysis does not certify to \(2^{-40}\); plain VIA's gadgets are a separate set (Table 5: DMux \(B{=}370758\), CMux \(B{=}24\), rs \(B{=}24\)) and are not implemented.

Database dimensions (paper Table 4, p.23)

inference \(I\) (rows, the first-dimension sum) and \(J\) (columns, the CMux tree) are the noise drivers — bigger means more accumulated error — so the parameter set is only valid for a given database size. Security review The authors note the code does not auto-configure \(\log I,\log J\); they must be set by hand to match the target size.

↑