Parameters

What the ≥120-bit instantiation actually costs: compute, key size, and communication measured against the paper’s advertised numbers. Short version: roughly 2× across the board.

What the paper advertises

paper VIA-C’s performance figures (§5.2, Table 1, p.18) are reported at \(n_1=2048,\ n_2=512\) — the parameters the paper also labels 110-bit. As the Fix page shows, that ring size delivers ~110 bits only under the paper’s Gaussian secret, and the via-rs implementation (ternary) is ~77–89 bits there by our estimator (malb ~87–101). So the advertised throughput, key sizes, and response sizes all belong to a sub-120-bit operating point. Re-pricing them at a genuine 120 bits means re-pricing them at \(n_1=4096\).

The cost levers that move when \((n_1,n_2,q_4)\) go \((2048,512,2^{12}) \to (4096,1024,2^{15})\), and how each scales inference:

↑

Measured

code Two measurements on the actual via-rs primitives, comparing the published \(n{=}2048\) ring against the secure \(n{=}4096\) ring at the paper’s conversion depth \(L{=}18\) on the \(q_1\)-RNS backend (release build, this machine; ratios are the portable part):

inference The gadget_product ratio (2.17×) lands almost exactly on the \(O(n\log n)\) prediction (2.18×), confirming the compute hit is the expected NTT scaling with no hidden super-linear term. The cascade-key measurement also doubles as a correctness check on the integration: the \(n{=}2048\) key reproduces the repository’s documented 24.75 MB exactly, so the \(n{=}4096\) instantiation (one extra cascade fold → 54 MB) is structurally sound.

code The end-to-end pipeline at \(n{=}4096\) is exercised and recovers correctly on a \(2\times2\) database (client_server_e2e_secure) — confirming the integration and the decode, not throughput at scale. unverified Wall-clock is machine-dependent and not asserted in-repo; the test header notes the single-threaded n=4096 NTT pipeline “runs for minutes.”

code A larger end-to-end run with the parallel first_dim at \(n_1{=}2048\), \(I{=}32,\ J{=}4096\) (\(2^{17}\) cells, a ~2 GB eval-form prepared DB) recovers the right record; it witnesses the multi-threaded first-dimension at real database width, short of the 32 GiB noise budget. unverified The specific wall-clock and host figures (run time, core count, RAM ceiling) are machine-dependent and not asserted in-repo.

↑

Derived

inference VIA’s headline metric is communication, so the size deltas matter as much as compute:

• Query (the \(O(\log N)\) compressed LWE ciphertexts of the index bits, at \(q_1\) on the large ring): \(\sim\!2\times\) — each ciphertext carries \(n_1\) coefficients and \(n_1\) doubles, while \(\log_2 q_1\) is essentially unchanged (\(2^{74.7}\) vs \(2^{75}\)).
• Response (the small-ring answer ciphertext at \(q_4\)): \(n_2\log_2 q_4 = 1024\cdot15\) vs \(512\cdot12\) → 2.5×. Both factors move: \(n_2\) doubles for small-ring security, and \(q_4\) grows \(2^{12}\!\to\!2^{15}\) to keep the decode correct at the larger \(n_1\).
• Offline (conversion key): 24.75 MB → 54 MB as measured: the dominant one-time server-side transfer in VIA-C.

↑

Verdict

inference Pulling it together:

So the paper’s VIA-C numbers do not describe a 120-bit scheme — reaching 120 bits roughly doubles every cost axis. VIA’s asymptotic story is untouched (still \(\tilde O(\log N)\) communication, still no offline phase beyond the conversion key); what changes is the concrete constant, by about \(2\times\). For a reader deciding whether VIA-C fits a deployment budget, the right figures to use are these, not the paper’s — and the gap is a direct, quantified consequence of the security shortfall the Fix page closes.

One optional change buys correctness margin: as the Fix page shows (re-derived in via-estimator), the shipped secure preset clears \(2^{-40}\) with ternary keys, but on a thin, model-sensitive margin. Raising the DMux / L_QUERY gadget length \(\ell\!:\!2\to3\) widens it enormously for one extra query gadget digit — a modest additive cost on top of the 2× above, not a doubling. (The paper’s intended Gaussian-key design does not clear \(2^{-40}\) at all — Yue’s noise-bound bug; via-rs only escapes it by running ternary keys.)

↑

Reproducing

code The measured numbers come from a timing/size test added alongside the secure preset:

# compute ratio (eval-backed gadget_product, n2048 vs n4096)
cargo test -p via-primitives --release --features alloc \
    --test secure_scaling -- --ignored --nocapture

# cascade key sizes (size_of, cheap)
cargo test -p via-primitives --release --features alloc \
    --test secure_scaling cascade_key_sizes -- --nocapture

# n=4096 end-to-end correctness (recovers the right record, ~17s release)
cargo test -p via-integration --release \
    --test client_server_e2e_secure -- --ignored

The security and correctness numbers behind the Fix page are produced by the in-repo via-estimator crate (a calibrated core-SVP lattice estimate + the Appendix-C noise calculator), which reads the shipped presets and gates CI:

# full security + correctness audit table
cargo run -p via-estimator

# CI gate (calibration anchors, preset security, noise budget)
cargo test -p via-estimator

# empirical: DMux output-noise scales with E[s^2] (Yue's bug, measured @ n4096)
cargo test -p via-primitives --release --features alloc \
    --test dmux_noise_empirical -- --ignored --nocapture

# empirical: LWE->RLWE conversion noise budget @ secure params (Yue's test #1)
cargo test -p via-primitives --release --features alloc \
    --test conversion_noise_secure -- --ignored --nocapture

It is the reproducible audit trail for the security_param = 120 claim — and the tool that reproduced Yue’s noise-bound bug (the paper’s Gaussian design fails \(2^{-40}\); ternary via-rs clears it).

↑