PQ-WB-KEM: Toward a White-Box Construction of ML-KEM-768 with Arithmetic Masking for M2M Communications

Abstract

Machine-to-machine and Internet of Things endpoints operate in physically accessible environments, motivating decapsulation-path hardening against an adversary with full code access. We present PQ-WB-KEM, a feasibility study that is, to our knowledge, the first systematic exploration of the table-based white-box design space for a NIST-standardized lattice key-encapsulation mechanism (ML-KEM-768, FIPS 203); prior white-box post-quantum work targets hash-based SPHINCS+ and multivariate hidden field equations (HFE; 256 GB), while the only earlier lattice-based white-box is custom and non-standardized. Because the base multiply runs in the number-theoretic transform (NTT) domain, where the secret operand $\widehat{s}=\mathrm{NTT}\left(s\right)$ is full-range over ${\mathbb{Z}}_q$, coefficient smallness does not shrink the tables. We map the design space with two verified lookup-only constructions: a shared full multiply table (Construction A, a measured 22.16 MB base, 25.57 MB core) and per-component tables with the secret baked in (Construction B, 7.67 MB base, 11.08 MB core), with the base tables being about 11,600× (A) and 33,400× (B) smaller than the 2022 256 GB HFE white box. Three-share arithmetic masking drives the measured first-order differential computation analysis (DCA) correlation to near the noise floor (${\rho }_{\max }=0.011$, versus $0.85$ unmasked). The projected deployment overhead is ≈47×, anchored on the native-C protected primitive measured with its mask-generation random number generator (RNG) randomness included ($4.30\times$, times an ≈11× embedded cache factor); the RNG-excluded harness yields the $17\times$ lower bound. We delimit scope honestly: against the full white-box adversary this construction does not achieve key confidentiality because the base multiply forms the clear product coordinates $p_0,p_1$ before masking and these yield linear equations for the secret; every positive result holds only against strictly weaker adversaries, and the work maps the lattice white-box design space rather than delivering a fully white-box key-encapsulation mechanism.

1. Introduction

The white-box (WB) attack model [1,2] captures adversaries with complete access to cryptographic implementations: code inspection, execution tracing, memory dumps, and behavioral modification. This model has become increasingly relevant for machine-to-machine (M2M) and Internet of Things (IoT) deployments [3] where devices operate in physically accessible, potentially hostile environments [4,5], a setting that is now driving post-quantum deployment on constrained devices [6].

Additionally, on 13 August 2024, the U.S. National Institute of Standards and Technology (NIST) published its first post-quantum cryptographic standards: the Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM), as Federal Information Processing Standards (FIPS) 203 [7]; the Module-Lattice-based Digital Signature Algorithm (ML-DSA), as FIPS 204 [8]; and the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA, based on SPHINCS+), as FIPS 205 [9]. NIST IR 8547 [10] sets a transition timeline that deprecates quantum-vulnerable algorithms by 2030 and disallows them by 2035. The intersection of white-box threats and quantum adversaries motivates research into cryptographic implementations secure in both dimensions.

This paper makes five specific, verifiable contributions. First, we provide the first systematic exploration of table-based white-boxing applied to ML-KEM (Section 4)—a feasibility study whose masking layer adapts standard arithmetic-masking techniques and whose number-theoretic transform (NTT) factorization restates known structure for completeness, the new material being the design-space map itself, filling the gap left by hash-based [11] and multivariate [12] approaches for the lattice-based NIST standards (Table 1). Second, building on the standard incomplete factorization of the NTT domain for $q=3329$ into 128 degree-2 extensions—well-known for ML-KEM [7] but reproved here in self-contained form—we design the degree-2 white-box base-multiply tables it enables (Section 3.2). Third, we observe that the base-multiply operand is the NTT image $\widehat{s}=\mathrm{NTT}\left(s\right)$, which is full-range over ${\mathbb{Z}}_q$ (coefficient smallness does not carry into the NTT domain), and map the resulting design space with two correct, verified lookup-only constructions—a shared full multiply table (Construction A, a measured $22.16$ MB, secret-independent) and per-component tables with the fixed secret baked in (Construction B, a measured $7.67$ MB at module rank $k=3$, the ML-KEM-768 parameter)—with a working reference implementation that verifies correctness across all 128 NTT components and all three secret polynomials against the reference base multiply (Section 4.2). The measured base tables ($22.16$ MB for A, $7.67$ MB for B) are about $\mathrm{11,600}\times$ (A) and $\mathrm{33,400}\times$ (B) smaller than Galissant–Goubin’s 2022 256 GB hidden field equations (HFE) white box [12]; with the $3.41$ MB encoding sublayer, the protected cores are $25.57$ MB (A) and $11.08$ MB (B) and, to our knowledge, the first correct table footprints reported for a lattice-based white-box KEM. Fourth, three-share arithmetic masking ($s=s^{\left(1\right)}+s^{\left(2\right)}+s^{\left(3\right)}\mathrm{mod}q$), with an information-theoretic proof of second-order security of share observation (any two of the three shares are independent of the secret—relative to an external, unobserved randomness source—so the first-order leakage is exactly 0), corroborated by a measured first-order differential computation analysis (DCA) correlation ${\rho }_{\max }=0.011$ at the ${10}^4$-trace noise floor—below the $0.031$ maximum wrong-key correlation, so the attack fails—versus $0.85$ unmasked, and combined with constant-time table-based operations, resists white-box DCA of the product shares and introduces no division-timing leak in the protected base multiply, complementing rather than replacing the gray-box timing defenses against KyberSlash [13] and NTT plaintext-checking [14] (Section 4.3). Fifth, the accompanying native-C benchmark (primitive_bench.c) measures a protected-primitive overhead of $4.30\times$ (x86-64) and $2.85\times$ (aarch64) for the protected base multiplication (Section 4.2 and Section 6); because the tables exceed second-level cache, an embedded deployment is DRAM-bound; with an ≈11× cache factor (bracketed by a measured $1.9$–$63\times$ range), this gives a gateway-class projection of ≈47× (=$4.30\times$ masking $\times \approx$11× cache) for Construction B, the $4.30\times$ being the faithful native-C protected primitive with its per-share mask-generation random number generator (RNG) included; the Python harness, whose timing loop replaces that RNG with a deterministic stand-in, gives the $17\times$ ($1.55\times$ masking $\times \approx$11× cache) lower bound. All figures are emulation- and host-derived projections: we claim no measured deployment on physical ARM hardware.

Table 1. Existing White-Box PQC Approaches. For this work, “Yes (proj.)” denotes footprint-based deployment feasibility only; it does not denote key confidentiality against the full white-box adversary, which is not achieved because the base multiply forms clear product intermediates $p_0,p_1$ before masking (Section 4, Algorithm 1). Bold marks the row for this work. Abbreviations: PQC, post-quantum cryptography; NIST, National Institute of Standards and Technology; FIPS, Federal Information Processing Standards; PoC, proof of concept.

Work	PQC Type	NIST Std	Size	Practical
Bicakci [11]	Hash-based	FIPS 205	Medium	Moderate
Galissant (ePrint 2022) [12]	Multivariate	None	256 GB	No
Galissant (CASCADE 2025) [15]	Multivariate	None	94–752 MB	No
Barthelemy (ePrint 2020) [16]	Lattice (custom)	None	<20 MB	PoC
This work	Lattice	FIPS 203	11–26 MB	Yes (proj.)

Table 1. Existing White-Box PQC Approaches. For this work, “Yes (proj.)” denotes footprint-based deployment feasibility only; it does not denote key confidentiality against the full white-box adversary, which is not achieved because the base multiply forms clear product intermediates $p_0,p_1$ before masking (Section 4, Algorithm 1). Bold marks the row for this work. Abbreviations: PQC, post-quantum cryptography; NIST, National Institute of Standards and Technology; FIPS, Federal Information Processing Standards; PoC, proof of concept.

Work	PQC Type	NIST Std	Size	Practical
Bicakci [11]	Hash-based	FIPS 205	Medium	Moderate
Galissant (ePrint 2022) [12]	Multivariate	None	256 GB	No
Galissant (CASCADE 2025) [15]	Multivariate	None	94–752 MB	No
Barthelemy (ePrint 2020) [16]	Lattice (custom)	None	<20 MB	PoC
This work	Lattice	FIPS 203	11–26 MB	Yes (proj.)

Algorithm 1 Base-Multiply Table Lookup for NTT Component i (Construction B; masking applied to outputs)

Require:  Ciphertext pair $(c_0,c_1)\in {\mathbb{Z}}_q^2$; per-component baked tables $h_i^0,h_i^1,h_i^2$ (the full-range NTT-domain secret $\widehat{s}$ and twiddle ${\gamma }_i$ are embedded at build time) Ensure:  Masked product shares ${(p_0^{\left(j\right)},p_1^{\left(j\right)})}_{j=1}^3$ with ${\sum }_j{p}_c^{\left(j\right)}\equiv p_c\left(\mathrm{mod}q\right)$ 1: $p_0\leftarrow h_i^0\left[c_0\right]+h_i^2\left[c_1\right]\mathrm{mod}q \{$$={\widehat{s}}_0{c}_0+{\gamma }_i{\widehat{s}}_1{c}_1$; two lookups and a modular add} 2: $p_1\leftarrow h_i^0\left[c_1\right]+h_i^1\left[c_0\right]\mathrm{mod}q \{$$={\widehat{s}}_0{c}_1+{\widehat{s}}_1{c}_0$; base mult. in ${\mathbb{Z}}_q\left[X\right]/(X^2-{\gamma }_i)$} 3: for $c\in \{0,1\}$ do 4:    $(p_c^{\left(1\right)},p_c^{\left(2\right)})\leftarrow {\mathbb{Z}}_q^2$ (uniform);   $p_c^{\left(3\right)}\leftarrow p_c-p_c^{\left(1\right)}-p_c^{\left(2\right)}\mathrm{mod}q$ split output into 3 shares 5: end for 6: return ${(p_0^{\left(j\right)},p_1^{\left(j\right)})}_{j=1}^3$

To delimit the contribution precisely, we state at the outset what this work does not claim. We make no claim of provable strong incompressibility, which cannot be proven under standard assumptions for key-fixing schemes [17], nor of protection against algebraic attacks: under the full white-box adversary, the base multiply forms the clear product coordinates $p_0,p_1$ before masking, and these yield linear equations for the secret (Section 5), so key confidentiality is not achieved there; what remains open is the structural security of the arithmetic table encodings. The construction targets gateway-class devices rather than resource-constrained IoT sensors, and its three-share masking addresses DCA only up to the second order, not the third or higher. Finally, we do not address fault-injection or time-of-check-to-time-of-use (TOCTOU) attacks. The value we claim for such a delimited study is the map itself: white-box cryptography has repeatedly advanced through published breaks and negative results—from the cryptanalyses of the first white-box Advanced Encryption Standard (AES) constructions to the WhibOx contests, in which every submission is fielded precisely so that most can fall—and an explicit account of where table-based lattice designs fail, with measured footprints and attack costs attached, spares the community from rediscovering the same dead ends privately and states exactly which open problem (structural security of arithmetic table encodings) any successor must solve.

2. Related Work

White-box cryptography began with Chow et al. [1,2], who implemented AES as a network of encoded lookup tables so that a key never appears in memory. Algebraic cryptanalysis [18,19,20] and DCA [4] went on to break every published key-hiding AES and Data Encryption Standard (DES) construction, and the WhibOx contests [21,22] have since confirmed the pattern at scale: in the 2024 edition every submitted Elliptic Curve Digital Signature Algorithm (ECDSA) implementation fell within days. That record has pushed the field in two directions—towards security notions and impossibility results, from the Delerablée–Lepoint–Paillier–Rivain framework [23] to the non-provability of strong incompressibility under standard assumptions [17], and towards designs that trade key-hiding for space-hardness [24] or for dedicated structure [25,26].

Post-quantum white-box work remains sparse, and none of it targets a standardized lattice key-encapsulation mechanism. Bicakci et al. (IACR CiC 2024) [11] gave the first peer-reviewed white-box post-quantum cryptography (PQC) construction, applying the space-hardness principles of Bogdanov–Isobe’s SPACE cipher [24] to SPHINCS+ and bounding attacker data access by a space-hardness parameter; SPHINCS+ is hash-based, however, with ≈8–50 KB signatures that suit bandwidth-constrained deployments poorly. Galissant–Goubin (ePrint 2022 [12], CASCADE 2025 [15]) proposed white-box HFE using multivariate cryptography with homomorphic encodings; the 2022 construction [12] reports an ≈256 GB white-box at security level $2^{80}$ with an ≈62.5 MB public key, which we cite rather than re-measure, and the 2025 conference version [15] refines the table construction to ≈94 MB ($\lambda =80$) through ≈752 MB ($\lambda =128$). The only earlier lattice-based white-box, Barthelemy [16] (ePrint 2020/893), is a custom, non-standardized encryption scheme under 20 MB rather than a KEM. Table 1 summarizes the landscape.

This work is therefore, to the best of our knowledge, the first feasibility study of table-based white-boxing for a lattice-based NIST post-quantum standard, specifically ML-KEM-768 (FIPS 203). We do not claim a secure white-box construction: the masking layer adapts standard arithmetic-masking techniques, the NTT factorization restates known structure for completeness, and the contribution is the design-space map itself—its measured footprints, its achievable partial guarantees, and the delimiting negative results that mark where table-based designs fail. Our measured base tables—22.16 MB for Construction A, 7.67 MB for Construction B, with protected cores of 25.57 MB and 11.08 MB once the encoding sublayer is added (the 11–26 MB of Table 1)—are about 11,600× (A) to 33,400× (B) smaller than the 2022 256 GB HFE white box [12], a cross-primitive contrast between a signature scheme and a KEM rather than a like-for-like comparison; against the 2025 CASCADE figures, our footprint is ≈4–98× smaller, and the primitive is still multivariate and still a signature. What distinguishes the present work is the target: the NIST primary standard for key encapsulation.

Extensive research already addresses gray-box attacks on ML-KEM. On masking, Bos et al. [27] and Heinz et al. [28] provide first-order schemes and Coron et al. [29] higher-order masking gadgets (developed for Dilithium, applicable to lattice masking generally); for calibration, Bos et al. report first-order masked Kyber decapsulation at ≈3.5× the unprotected pqm4 cost (Cortex-M4F), of the same order as our faithful native-C $4.30\times$ protected-primitive overhead (the Python harness’s table-lookup-plus-recombination wall-clock ratio is ≈1.55×, a lower bound on masking cost, since its timing loop substitutes a deterministic stand-in for the per-share RNG draws), although the two are not directly comparable (white-box table lookups versus gray-box masking, on different platforms) and our end-to-end ≈47× projection additionally folds in a white-box-specific ≈11× cache-miss factor, while SUCRE [30] accelerates ML-DSA masking 4–6× via shuffle-and-unmask (indicative of the broader push toward efficient masked PQC, although not directly applicable to ML-KEM key encapsulation). On timing attacks, KyberSlash [13] exploits secret-dependent divisions, Li et al. [31] recover keys through a Hertzbleed frequency-scaling channel, and Pay and Standaert [14] propose NTT-domain refreshing against plaintext-checking side channels with a gray-box constant-time construction; our white-box constant-time table lookups instead eliminate secret-dependent arithmetic in the protected base multiply, complementing rather than replacing these defenses. On power analysis and deep-learning side-channel analysis, Ravi et al. [32], Rajendran et al. [33], Du et al. [34], and Berzati et al. [35] report attacks on ML-KEM (with the latter describing a simple-power-analysis-assisted chosen-ciphertext attack), and Dubrova et al. [36] recover keys from a fifth-order masked Kyber implementation by profiled deep learning; fault attacks are studied by Kundu et al. [37], and combined countermeasures include Reed–Solomon code-based masking (RS-CBM) [38] and quasi-linear masking for combined fault and side-channel-analysis protection [39].

The key distinction is that all of this prior work addresses gray-box side channels—bounded probing, timing, power, and electromagnetic emanations—rather than white-box complete code access. Our feasibility study maps that gap for lattice-based PQC, introducing no division-timing leak in the protected base multiply by design; KyberSlash’s own divisions lie in the unprotected decode and compression path, and protecting them is left to future work.

3. Background and Motivation

This section fixes the ML-KEM and NTT background, the white-box threat model, and the DCA adversary the construction must resist and outlines the motivation for the design.

3.1. ML-KEM Parameters and Structure

ML-KEM-768 [7,40], whose security rests on the module/ring learning-with-errors problem [41,42,43], operates over $R_q={\mathbb{Z}}_q\left[X\right]/(X^{256}+1)$ with parameters in

Table 2. ML-KEM-768 Parameters [7].

Parameter	Value	Description
n	256	Polynomial degree
q	3329	Prime modulus
k	3	Module rank
${\eta }_1,{\eta }_2$	2, 2	lefted binomial distribution parameters
$\left|pk\right|$	1184 B	Public key size
$\left|ct\right|$	1088 B	Ciphertext size
$\left|K\right|$	32 B	Shared secret

.

3.2. NTT Domain Structure

The factorization below is well known for ML-KEM [7]; we restate it with a self-contained proof because the degree-2 structure—rather than scalar coefficients—is what drives the table design of Section 4.2.

Theorem 1 

(NTT Factorization for ML-KEM). For $q=3329=2^8·13+1$ and $n=256$:

$$X^{256}+1\equiv {\displaystyle \prod _{i=0}^{127}}(X^2-{\zeta }^{2i+1})\left(\mathrm{mod}q\right),$$

(1)

where $\zeta =17$ is a primitive 256th root of unity, and each factor is irreducible over ${\mathbb{Z}}_q$.

Proof. 

We provide a complete proof in four steps:

Step 1 (Existence of primitive 256th root): Since q is prime, the multiplicative group ${\mathbb{Z}}_q^{\ast }$ is cyclic of order $q-1=3328=2^8·13$. Since $256=2^8$ divides 3328, primitive 256th roots of unity exist.

Step 2 (Verification of $\mathbf{\zeta }=\mathbf{17}$): We verify computationally that ${17}^{256}\equiv 1\left(\mathrm{mod}3329\right)$ (so 17 is a 256th root), that ${17}^{128}\equiv 3328\equiv -1\left(\mathrm{mod}3329\right)$ (so it is primitive, not a 128th root), and that ${17}^{64}\equiv 1729\not\equiv \pm 1\left(\mathrm{mod}3329\right)$ (so it is not a smaller-order root).

Step 3 (Factorization of ${\mathit{X}}^{\mathbf{256}}+\mathbf{1}$): Substituting $Y=X^2$ and using ${\zeta }^{128}\equiv -1$ (Step 2), we write $X^{256}+1={\left(X^2\right)}^{128}-{\zeta }^{128}=Y^{128}-{\zeta }^{128}$. Since ${\zeta }^2$ is a primitive 128th root of unity in ${\mathbb{Z}}_q$, the 128 roots of $Y^{128}-{\zeta }^{128}$ are exactly $\zeta ·{\left({\zeta }^2\right)}^i={\zeta }^{2i+1}$ for $i\in \{0,\dots ,127\}$, so

$$Y^{128}-{\zeta }^{128}={\displaystyle \prod _{i=0}^{127}}\left(Y-{\zeta }^{2i+1}\right).$$

Re-substituting $Y=X^2$ gives the factorization over ${\mathbb{Z}}_q$:

$$X^{256}+1={\displaystyle \prod _{i=0}^{127}}(X^2-{\zeta }^{2i+1}).$$

Step 4 (Irreducibility): It remains to be shown that each quadratic factor is irreducible, i.e., that ${\zeta }^{2i+1}$ is a quadratic non-residue modulo q. Suppose ${\zeta }^{2i+1}={\alpha }^2$ for some $\alpha \in {\mathbb{Z}}_q^{\ast }$. Then

$${\alpha }^{256}={\left({\zeta }^{2i+1}\right)}^{128}={\left({\zeta }^{128}\right)}^{2i+1}={(-1)}^{2i+1}=-1,$$

so ${\alpha }^{512}=1$ while ${\alpha }^{256}=-1\ne 1$; hence $\mathrm{ord}\left(\alpha \right)=512$ exactly. But $512\nmid 3328=q-1$, so ${\mathbb{Z}}_q^{\ast }$ contains no element of order 512—a contradiction. Therefore each $X^2-{\zeta }^{2i+1}$ is irreducible over ${\mathbb{Z}}_q$. (Equivalently, by Euler’s criterion ${\left({\zeta }^{2i+1}\right)}^{(q-1)/2}={\left({\zeta }^{1664}\right)}^{2i+1}={(-1)}^{2i+1}=-1$, since ${\zeta }^{1664}={\left({\zeta }^{128}\right)}^{13}=-1$, confirming non-residuosity.)    □

Corollary 1. 

By the Chinese Remainder Theorem (the 128 quadratic factors are distinct irreducibles, hence pairwise coprime), the NTT representation of $R_q$ is as follows:

$$R_q\cong {\displaystyle \prod _{i=0}^{127}}{\mathbb{Z}}_q\left[X\right]/(X^2-{\zeta }^{2i+1}).$$

(2)

Each component is a degree-2 field extension of ${\mathbb{Z}}_q$, not a copy of the base field ${\mathbb{Z}}_q$.

Remark 1 

(Critical Implementation Note). This characterization differs from some simplified descriptions that treat NTT coefficients as scalars. Each NTT “coefficient” is a pair $(a_0,a_1)$ representing $a_0+a_{1}X$ in a degree-2 extension. Multiplication requires the following:

$$\begin{array}{cc}\hfill (a_0,a_1)·(b_0,b_1)& =(a_0{b}_0+\gamma a_1{b}_1,a_0{b}_1+a_1{b}_0),\hfill \end{array}$$

(3)

where $\gamma ={\zeta }^{2i+1}$ is the reduction constant for component i. This structure fundamentally shapes our white-box table design.

3.3. Threat Model Hierarchy

We distinguish three attack models with increasing adversary capability:

Definition 1 

(Black-Box Model). The adversary observes only inputs and outputs. Security relies on cryptographic hardness assumptions, namely the Module Learning with Errors problem for ML-KEM.

Definition 2 

(Gray-Box Model). The adversary observes side-channel leakage—power consumption, electromagnetic emanations, timing, and cache behavior—and is typically countered by constant-time implementations and masking [27].

Definition 3 

(White-Box Model [1,17]). As formalized in Definition 6, the adversary has complete code and data access, executes the implementation on arbitrary inputs, observes all intermediate values, and collects unlimited traces.

3.4. Differential Computation Analysis

Definition 4 

(DCA [4]). DCA correlates intermediate values V with key hypotheses $H_k$:

$$\rho (V,H_k)={\displaystyle \frac{Cov(V,H_k)}{{\sigma }_V·{\sigma }_{H_k}}}.$$

(4)

The attack succeeds when $|\rho (V,H_{k^{\ast }})|>|\rho (V,H_k)|$ for the correct key $k^{\ast }$ and all wrong keys $k\ne k^{\ast }$.

Definition 5 

(d-th Order DCA). A d-th order DCA attack correlates d intermediate values $(V_1,\dots ,V_d)$ with key hypotheses via a combining function g:

$$\rho (g(V_1,\dots ,V_d),H_k).$$

(5)

Common combining functions include the product $g=\prod V_i$ and the sum $g=\sum V_i$.

3.5. Precise White-Box Attacker Model

We formalize the white-box attacker capabilities explicitly:

Definition 6 

(White-Box Attacker Capabilities). Adversary $\mathcal{A}$ possesses complete code access (the full binary/source of the implementation), arbitrary execution (running the implementation on any chosen input), memory observation (reading all RAM contents during execution), and unlimited trace collection with intermediate values. The adversary has no external access (it cannot query external oracles or trusted hardware) and only read-only memory access (it cannot modify program code or data during execution, so TOCTOU attacks are excluded in this model).

Remark 2 

(Model Limitations). We explicitly exclude memory tampering attacks (fault injection) and TOCTOU attacks from our threat model. Addressing these requires hardware countermeasures beyond software white-box techniques. The model also distinguishes internal from external entropy: any pseudo-random state generated inside the observed execution is readable—and therefore predictable—by $\mathcal{A}$, so mask randomness drawn from it offers no independence; the masking layer of Section 5 is accordingly conditioned on an external, unobservable entropy source (a hardware true random number generator or an externally supplied seed; Theorem 2, Remark 5), and without such a source, its guarantees do not apply.

The gap identified in Section 2 (no practical white-box construction for a lattice-based NIST standard), together with the concurrent white-box (DCA) and gray-box (timing) threats above, motivates a construction that targets simultaneous DCA resistance of the shared intermediates and constant-time execution in its protected base multiply. Table size is not a third objective: Section 5 reports the measurement that rules it out as a security parameter here, so we treat the footprint throughout as a deployment cost. The remainder of the paper develops a candidate construction along these lines for ML-KEM-768 decapsulation and evaluates the extent to which it meets these goals.

4. The Proposed PQ-WB-KEM Construction

Having established the mathematical foundations and threat model in the previous section, we now present the proposed construction. The design exploits the NTT domain structure characterized in Theorem 1 to achieve practical table sizes while providing second-order DCA resistance of share observation (Section 4.3).

4.1. Architecture Overview

Our construction applies three protection layers, designed specifically for the algebraic structure of lattice cryptography, as illustrated in Figure 1:

4.2. Coefficient-Pair Multiplication Tables

Definition 7 

(Base-Multiply Tables on the Full-Range NTT-Domain Secret). The ML-KEM base multiply operates in the NTT domain, so the stored secret is the NTT image $\widehat{s}=\mathrm{NTT}\left(s\right)$, and the tabulated operation is the per-component product in ${\mathbb{Z}}_q\left[X\right]/(X^2-{\gamma }_i)$ with ${\gamma }_i={\zeta }^{2i+1}$:

$$p_0={\widehat{s}}_0{c}_0+{\gamma }_i{\widehat{s}}_1{c}_1\mathrm{mod}q,p_1={\widehat{s}}_0{c}_1+{\widehat{s}}_1{c}_0\mathrm{mod}q,$$

(6)

where $({\widehat{s}}_0,{\widehat{s}}_1)$ are the component’s secret coordinates and $(c_0,c_1)$ the ciphertext coordinates. We realize the products by table lookups, with only modular additions of lookup outputs remaining (Algorithm 1).

A dense tabulation of the full pair-product map $T_i:{\mathbb{Z}}_q^2\times {\mathbb{Z}}_q^2\to {\mathbb{Z}}_q^2$ would store $q^4$ entries of $2\lceil {\log }_{2}q\rceil =24$ bits each, i.e., ≈368 TB per component (over ${10}^5$ TB across all $384=k\times 128$ component multiplications, module rank $k=3$)—entirely impractical. The natural instinct is to exploit the smallness of the Kyber secret, but that smallness does not survive the transform into the domain in which the base multiply operates:

Remark 3 

(Coefficient Smallness Does Not Carry into the NTT Domain). With $\eta =2$, each coefficient-domain secret coordinate $s_i$ lies in $\{-2,\dots ,2\}$, drawn from the centered binomial distribution (CBD) [7]. The base-multiply operand, however, is the NTT image $\widehat{s}=\mathrm{NTT}\left(s\right)$, every coordinate of which is a ${\mathbb{Z}}_q$-linear combination of all 256 coefficient-domain coordinates weighted by distinct powers of ζ; reducing that 256-term sum mod q leaves no residual smallness, and the measurement bears this out. On the reference sample (768 coordinates at $k=3$, seed 42) $\widehat{s}$ spans $\left[\mathrm{7,3325}\right]$, and none of the 768 coordinates falls in $\{-2,\dots ,2\}$—which is what a single draw can look like, and precisely why one draw cannot settle the question. Over 200 independent secrets the rate is $0.147\%$ (226 of $\mathrm{153,600}$ coordinates), matching the $5/q=0.150\%$ rate expected of a coordinate ranging over all of ${\mathbb{Z}}_q$ and nowhere near the $100\%$ that inherited smallness would give (whitebox_reference.json). A table indexed by the secret operand must therefore admit any value in ${\mathbb{Z}}_q$, and the five-value coefficient domain yields no reduction here.

We accordingly give two correct lookup-only constructions, both operating on the full-range $\widehat{s}$ and both verified against the reference base multiply, that trade footprint against secret-independence.

The first, Construction A (shared full multiply table), uses a single table $M\left[x\right]\left[y\right]=x·y\mathrm{mod}q$ over ${\mathbb{Z}}_q\times {\mathbb{Z}}_q$ for every component: ${\widehat{s}}_0{c}_0=M\left[{\widehat{s}}_0\right]\left[c_0\right]$, and the twiddle is a second lookup ${\gamma }_i\left({\widehat{s}}_1{c}_1\right)=M\left[{\gamma }_i\right]\left[M\left[{\widehat{s}}_1\right]\left[c_1\right]\right]$. This table is secret-independent and shared across all 128 components and all k polynomials; it holds $q^2$ two-byte entries, measuring $22.16$ MB.

The second, Construction B (baked per-component tables), embeds the fixed secret in three q-entry tables per component i: $h_i^0\left[c\right]={\widehat{s}}_{0,i}c$, $h_i^1\left[c\right]={\widehat{s}}_{1,i}c$, and $h_i^2\left[c\right]={\gamma }_i{\widehat{s}}_{1,i}c$, so that $p_0=h_i^0\left[c_0\right]+h_i^2\left[c_1\right]$ and $p_1=h_i^0\left[c_1\right]+h_i^1\left[c_0\right]$. This stores $128\times 3\times q$ two-byte entries per secret polynomial ($2.56$ MB), a measured $7.67$ MB at module rank $k=3$. Construction B is the genuine white-box form—the secret resides inside the tables—and has the smaller footprint, at the cost of scaling with k.

A working reference implementation (whitebox_reference.py) builds both constructions on a real full-range $\widehat{s}$ and, over 5000 random ciphertexts spread across all 128 components and all $k=3$ polynomials, verifies that each reproduces the reference product in ${\mathbb{Z}}_q\left[X\right]/(X^2-{\gamma }_i)$ (correct in every trial), cross-checked against an independent pairwise NTT multiply. The serialized footprints measure $22.16$ MB (Construction A) and $7.67$ MB (Construction B) (results/whitebox_reference.json); Table 3 breaks these down into base tables, the encoding sublayer, and the deployment total. Both remain far below the 256 GB of the multivariate HFE white-box—by ≈11,600× (A) and ≈33,400× (B).

We additionally measure the protected primitive of Construction B (table lookup plus 3-share masking versus direct arithmetic) in native C via primitive_bench.c on two architectures: the protected-over-direct base-multiplication ratio is $4.30\times$ on x86-64 and $2.85\times$ on aarch64 (cross-compiled with the aarch64 GCC and run under qemu-aarch64). Because QEMU is functional emulation rather than cycle-accurate, the ratio—not the absolute timing—is the comparable metric (results/primitive_bench_*.json). Because the tables ($2.56$–$7.67$ MB) exceed second-level cache, a cache-poor embedded target without a last-level cache reads them from DRAM: a pointer-chase working-set sweep on the host measures a random-access penalty rising to ≈71× in the DRAM regime (cache_effect.json); with an embedded cache factor of ≈11× (a mid-estimate bracketed by these measurements, Section 6.2), the deployed decapsulation overhead is a cache-dominated projection of ≈47× (Construction B; $4.30\times$ native masking $\times \approx$11× cache) rather than a single measured figure. The footprint confines deployment to gateway-class (application-processor, Arm A-profile) targets with ≥64 MB RAM; M-profile microcontrollers cannot hold the tables and are explicitly out of scope.

The per-component table layout is depicted in Figure 2. In Construction B the tables are indexed by the public ciphertext coordinate with the full-range secret $\widehat{s}$ baked into the table values, so the base-multiply lookup has no secret-dependent access pattern; masking is applied to the table outputs (Algorithm 1, lines 3–5), consistent with the arithmetic-masking analysis of Section 4.3. Construction A instead indexes the shared multiply table by the secret coordinate $\widehat{s}$, whose access pattern is a secret-dependent channel addressed heuristically by the shuffling and encoding layers and not claimed to be provably eliminated (see Section 5.2 and Section 7.2).

Table 3. Storage breakdown for the ML-KEM-768 white-box, for both constructions. Every stored component is measured (whitebox_reference.py, whitebox_encoded.py, obfuscation_storage.py); the masking support stores nothing, its shares being drawn at run time, which is why its row reads zero. The shuffle and masking layers add almost nothing beyond the measured core (which already includes the $3.41$ MB encoding sublayer): the coefficient shuffle $\pi$ is a permutation of the 256 secret coefficients stored with its inverse per polynomial (a few kilobytes), and runtime masking stores no table, so the deployment total exceeds the measured core by only the shuffle’s few kilobytes. Construction A uses one secret-independent table shared across all components and polynomials; Construction B bakes the fixed secret into per-component tables (scaling with module rank k).

Component	A (Shared)	B (Baked)	Basis
Base-multiply tables *	22.16 MB	7.67 MB	Measured
Output-encoding sublayer	3.41 MB	3.41 MB	Measured
Measured core	25.57 MB	11.08 MB	Measured
Coefficient shuffle ($\pi$, ${\pi }^{-1}$)	3 KB	3 KB	Measured
Masking support	0	0	runtime
Deployment total	25.58 MB	11.08 MB	Measured

* The base-multiply tables are the measured artifact and are stored once unmasked; masking is applied to lookup outputs at runtime with fresh per-decapsulation randomness (Algorithm 1), so no masked tables are stored. The measured core (base tables plus the $3.41$ MB output-encoding sublayer) is $25.57$ MB (A) and $11.08$ MB (B); the coefficient shuffle adds 3 KB (its permutation of the 256 secret coefficients and the inverse, per polynomial, obfuscation_storage.py), and masking adds nothing, so the deployment total is the core plus the 3 KB shuffle ($25.58$ MB for A, $11.08$ MB for B).

Table 3. Storage breakdown for the ML-KEM-768 white-box, for both constructions. Every stored component is measured (whitebox_reference.py, whitebox_encoded.py, obfuscation_storage.py); the masking support stores nothing, its shares being drawn at run time, which is why its row reads zero. The shuffle and masking layers add almost nothing beyond the measured core (which already includes the $3.41$ MB encoding sublayer): the coefficient shuffle $\pi$ is a permutation of the 256 secret coefficients stored with its inverse per polynomial (a few kilobytes), and runtime masking stores no table, so the deployment total exceeds the measured core by only the shuffle’s few kilobytes. Construction A uses one secret-independent table shared across all components and polynomials; Construction B bakes the fixed secret into per-component tables (scaling with module rank k).

Component	A (Shared)	B (Baked)	Basis
Base-multiply tables *	22.16 MB	7.67 MB	Measured
Output-encoding sublayer	3.41 MB	3.41 MB	Measured
Measured core	25.57 MB	11.08 MB	Measured
Coefficient shuffle ($\pi$, ${\pi }^{-1}$)	3 KB	3 KB	Measured
Masking support	0	0	runtime
Deployment total	25.58 MB	11.08 MB	Measured

* The base-multiply tables are the measured artifact and are stored once unmasked; masking is applied to lookup outputs at runtime with fresh per-decapsulation randomness (Algorithm 1), so no masked tables are stored. The measured core (base tables plus the $3.41$ MB output-encoding sublayer) is $25.57$ MB (A) and $11.08$ MB (B); the coefficient shuffle adds 3 KB (its permutation of the 256 secret coefficients and the inverse, per polynomial, obfuscation_storage.py), and masking adds nothing, so the deployment total is the core plus the 3 KB shuffle ($25.58$ MB for A, $11.08$ MB for B).

Figure 2. White-box base-multiply table structure (Construction B). Because the base-multiply operand is the full-range NTT-domain secret $\widehat{s}=\mathrm{NTT}\left(s\right)$, the tables are indexed by the ciphertext coordinate $c\in {\mathbb{Z}}_q$ with the fixed secret baked in: per component i, three q-entry tables $h_i^0,h_i^1,h_i^2$ combine to the product pair $(p_0,p_1)$, which is then split into three arithmetic shares (Algorithm 1). The shaded cell marks the single entry that one such lookup reads, selected by the public ciphertext coordinate. Construction A instead uses one shared $q\times q$ multiply table with the secret as a full-range index.

Figure 2. White-box base-multiply table structure (Construction B). Because the base-multiply operand is the full-range NTT-domain secret $\widehat{s}=\mathrm{NTT}\left(s\right)$, the tables are indexed by the ciphertext coordinate $c\in {\mathbb{Z}}_q$ with the fixed secret baked in: per component i, three q-entry tables $h_i^0,h_i^1,h_i^2$ combine to the product pair $(p_0,p_1)$, which is then split into three arithmetic shares (Algorithm 1). The shaded cell marks the single entry that one such lookup reads, selected by the public ciphertext coordinate. Construction A instead uses one shared $q\times q$ multiply table with the secret as a full-range index.

Remark 4 

(Comparison with Prior Work). Galissant–Goubin [12] require 256 GB for white-box HFE—our measured base tables ($7.67$–$22.16$ MB for Constructions B/A) are about 33,400× (B) and 11,600× (A) smaller (a cross-primitive footprint contrast, KEM versus signature). This practical size fits gateway-class devices such as the Raspberry Pi 4 (4 GB RAM, 26 MB ≈ 0.6% of memory); this is a footprint statement only—no performance measurement on such hardware is claimed.

4.3. Three-Share Arithmetic Masking

Definition 8 

(Arithmetic Masking over ${\mathbb{Z}}_q$). A sensitive value $s\in {\mathbb{Z}}_q$ (a secret coefficient or an intermediate table output, cf. Algorithm 1) is represented as

$$s=s^{\left(1\right)}+s^{\left(2\right)}+s^{\left(3\right)}\mathrm{mod}q,$$

(7)

with $s^{\left(1\right)},s^{\left(2\right)}$ sampled uniformly from ${\mathbb{Z}}_q$ per decapsulation from an external seed expanded by a deterministic random bit generator (DRBG)—fresh entropy that lies outside the execution state the white-box adversary observes—and $s^{\left(3\right)}=s-s^{\left(1\right)}-s^{\left(2\right)}\mathrm{mod}q$.

The independence statement below is the standard $(t,t)$-additive-sharing fact over ${\mathbb{Z}}_q$, recalled here in the form the rest of the paper uses; what is specific to the white-box setting is the external-randomness condition of Remark 5 and the restriction to share the observation made explicit in the corollary that follows and in Section 5.1, which states what the clear product coordinates leave observable.

Theorem 2 

(Second-Order DCA Resistance of Share Observation). Assume the masks $s^{\left(1\right)},s^{\left(2\right)}$ are drawn afresh per decapsulation from an entropy source external to, and unobservable within, the execution state visible to the adversary (Remark 5); an adversary who can read or predict the generator’s internal state falsifies this hypothesis and voids the conclusion. Under this assumption, for three-share arithmetic masking, any pair of shares $(s^{\left(i\right)},s^{\left(j\right)})$ with $i\ne j$ is statistically independent of s. This is expressed formally as follows:

$$I(s^{\left(i\right)},s^{\left(j\right)};s)=0\forall i\ne j,$$

(8)

where $I(·;·)$ denotes mutual information.

Proof. 

We prove this information-theoretically. Let $s\in {\mathbb{Z}}_q$ be the secret.

Case 1: $i,j\in \{1,2\}$. Shares $s^{\left(1\right)},s^{\left(2\right)}$ are sampled independently and uniformly from ${\mathbb{Z}}_q$. For any fixed s

$$\mathrm{Pr}[(s^{\left(1\right)},s^{\left(2\right)})=(a,b)\mid s]=\mathrm{Pr}[s^{\left(1\right)}=a]·\mathrm{Pr}[s^{\left(2\right)}=b]={\displaystyle \frac{1}{q^2}}.$$

This equals $\mathrm{Pr}[(s^{\left(1\right)},s^{\left(2\right)})=(a,b)]$ unconditionally, so $(s^{\left(1\right)},s^{\left(2\right)})\perp s$.

Case 2: $\{i,j\}=\{1,3\}$ (similarly for $\{2,3\}$). We have $s^{\left(3\right)}=s-s^{\left(1\right)}-s^{\left(2\right)}\mathrm{mod}q$. For any fixed s and any $(a,c)\in {\mathbb{Z}}_q^2$

$$\begin{array}{cc}\hfill \mathrm{Pr}[(s^{\left(1\right)},s^{\left(3\right)})=(a,c)\mid s]& =\mathrm{Pr}[s^{\left(1\right)}=a,s-s^{\left(1\right)}-s^{\left(2\right)}=c]\hfill \\ \hfill & =\mathrm{Pr}[s^{\left(1\right)}=a]·\mathrm{Pr}[s^{\left(2\right)}=s-a-c]\hfill \\ \hfill & ={\displaystyle \frac{1}{q}}·{\displaystyle \frac{1}{q}}={\displaystyle \frac{1}{q^2}}.\hfill \end{array}$$

(9)

Again, this is independent of the specific value of s.

Therefore, for all pairs $(i,j)$ with $i\ne j$: $H(s^{\left(i\right)},s^{\left(j\right)}\mid s)=H(s^{\left(i\right)},s^{\left(j\right)})=2{\log }_{2}q$, implying $I(s^{\left(i\right)},s^{\left(j\right)};s)=0$.    □

Remark 5 

(Randomness Source). Theorem 2 assumes the masks $s^{\left(1\right)},s^{\left(2\right)}$ are drawn afresh per decapsulation from a source external to the observed execution state (a seed expanded by a DRBG). In the declared white-box model—where the adversary reads all RAM and every intermediate value—masks produced from internally observable program state could be recomputed by the adversary, so the information-theoretic independence holds only relative to this external randomness source, which is the trust anchor of the masking layer.

Corollary 2 

(DCA Attack Complexity for Share Observation). A DCA attack observing any two of the three arithmetic shares cannot distinguish between different masked values, so recovering the masked value from the shares alone requires at least third-order analysis (three simultaneous probes). This statement is limited to attacks that observe the shares themselves; second-order security for all intermediate values (scalar table outputs, partial sums, the composed product) requires a separate 2-probing/non-interference composition argument, which we do not provide here (see Section 5.2).

Remark 6 

(Why Not 2-Share Masking?). Two-share masking ($s=s^{\left(1\right)}+s^{\left(2\right)}$) provides only first-order resistance. First-order DCA on a masked implementation must overcome the $1/\sqrt{N}$ sampling-noise floor before any residual first-order leakage becomes detectable, and the first-order masked construction of Bos et al. [27] targets precisely this setting, with higher-order gadgets developed by Coron et al. [29]. Three shares provide meaningful security improvement at a moderate native primitive cost ($4.30\times$; Section 6.2).

Remark 7 

(Boolean vs. Arithmetic Masking). Boolean masking $s=s^{\left(1\right)}\oplus s^{\left(2\right)}\oplus s^{\left(3\right)}$ is incompatible with mod-q arithmetic without costly Boolean-to-arithmetic (B2A) and arithmetic-to-Boolean (A2B) conversions: XOR operates on binary representations rather than ring elements, $(a\oplus b)\mathrm{mod}q$ destroys the algebraic structure, and polynomial operations require arithmetic over ${\mathbb{Z}}_q$. This distinguishes lattice masking from AES masking [27,44]. Conversion between masking types requires expensive algorithms [45,46].

4.4. Freedom from Division-Timing Leakage in the Protected Base Multiply

Theorem 3 

(Freedom from Secret-Dependent Branching and Variable-Latency Arithmetic). Within the table-protected base-multiplication region (Algorithm 1, where $sk$ enters), PQ-WB-KEM contains no secret-dependent branches and no data-dependent division or modular reduction, so the protected base multiply introduces no division-timing leak of the KyberSlash class. The secret-derived message decode and the Fujisaki–Okamoto [47] (FO) re-encryption (Algorithm 2, lines 6–7) run outside this boundary and are not covered by this statement; cache-line-level constant-time behavior is not claimed (see the cache-timing limitation in Section 5.2).

Proof. 

We enumerate the secret-dependent operations. In Construction B the base-multiply lookup indexes the baked tables by the public ciphertext coordinate, so the index computation involves no secret and introduces no data-dependent division or modular reduction (the array access is not cache-line constant-time, but its address depends only on public data; in Construction A, where the secret $\widehat{s}$ is the index, the access pattern is a secret-dependent channel; see the cache-timing limitation in Section 5.2). Share combination $s^{\left(1\right)}+s^{\left(2\right)}+s^{\left(3\right)}\mathrm{mod}q$ uses constant-time modular arithmetic (addition followed by a branch-free conditional subtraction), and all control flow is determined by public parameters (component indices, iteration counts). Therefore, within the protected base-multiplication region, no secret-dependent branch or variable-latency arithmetic operation exists. The secret-derived message decode and FO re-encryption (Algorithm 2, lines 6–7) fall outside this region; their timing behavior is that of the underlying FIPS-203 implementation and is out of scope here. The residual cache-access-pattern channel is addressed as the cache-timing limitation in Section 5.2.    □

Algorithm 2 Protected Decapsulation: composition of the secret-key path

Require:  Ciphertext c; white-box tables (stored unmasked with the $E_{i,j}$ output-encoding sublayer; masking is applied to lookup outputs at runtime, Algorithm 1); shuffle $\pi$ with inverse ${\pi }^{-1}$; decode maps $E_{i,j}^{-1}$; public key $pk$ Ensure:  Shared secret K (or implicit reject) 1: $(u,v)\leftarrow \mathsf{Decompress}\left(c\right)$;   $\widehat{u}\leftarrow \mathsf{NTT}\left(u\right)$ public inputs; no secret 2: for module row $\ell =1$ to k and NTT component $i=0$ to 127 do 3: evaluate Algorithm 1 on ${\widehat{u}}_{\ell ,i}$ under shuffle $\pi$ (the baked tables embed ${\widehat{s}}_{\ell ,i}$) protected: masked, $E_{i,j}$-encoded shares 4: end for 5: decode ($E_{i,j}^{-1}$), unshuffle (${\pi }^{-1}$), recombine the three mask shares, and sum over ℓ to obtain $\widehat{w}={\sum }_{\ell }{\widehat{s}}_{\ell }·{\widehat{u}}_{\ell }$ clear intermediate; masking/encoding boundary ends here 6: $m^{\prime }\leftarrow \mathsf{Decode}\left(v-\mathsf{INTT}\left(\widehat{w}\right)\right)$$\{m^{\prime }$ is secret-derived} 7: Fujisaki–Okamoto re-encryption (per FIPS 203): $c^{\prime }\leftarrow \mathsf{K}-\mathsf{PKE}.\mathsf{Encrypt}(pk,m^{\prime };r^{\prime })$ with $r^{\prime }=G\left(m^{\prime }\right)$; if $c^{\prime }=c$ return $K\leftarrow \mathsf{KDF}(·)$ else implicit reject unprotected sub-step 8: return K

4.5. Putting It Together: Protected Decapsulation

The protected primitive (Algorithm 1) composes into full decapsulation as follows. Two obfuscation layers wrap the base multiplication: a secret coefficient shuffle $\pi$ and secret output encodings $E_{i,j}$.

Definition 9 

(Shuffle Permutation $\pi$). π is a secret permutation of the 256 NTT coefficients of the secret, keyed by a random seed, applied before each protected lookup, with matching inverse ${\pi }^{-1}$ applied after. As a coordinate permutation, π is linear, and its composition with the linear NTT remains linear; it is therefore security-neutral—it spreads access patterns but adds no algebraic hardness (cf. the algebraic-attack analysis, Section 5)—at a negligible stored cost of 3 KB in total across the $k=3$ polynomials (Table 3).

The output encodings $E_{i,j}:{\mathbb{Z}}_q\to {\mathbb{Z}}_q$ are the secret nonlinear layer defined in Proposition 1 (each a q-entry lookup table, the origin of the measured $3.41$ MB encoding cost); their structural security is the construction’s central open problem (Section 7.2).

Algorithm 2 bounds the protected region to the secret $\widehat{s}·\widehat{u}$ base multiplications (lines 2–4) and the decode/recombination that closes the boundary (line 5), where $sk$ enters; the surrounding FIPS-203 steps are standard. One honest caveat: the Fujisaki–Okamoto re-encryption (line 7) consumes the secret-derived message $m^{\prime }$ and, as implemented, runs outside the table-protected boundary, so a white-box adversary observing that sub-computation could target $m^{\prime }$ directly. Extending the protected boundary to the message-decode and re-encryption path (or masking $m^{\prime }$) is future work; the present construction protects the $sk$-dependent multiply, consistent with our decapsulation-only protection scope.

Remark 8 

(KyberSlash Mitigation). The KyberSlash attack [13] exploits variable-time division in reference ML-KEM implementations. Our table-based approach keeps the protected base multiply division-free, so it introduces no KyberSlash-style division-timing leak. Crucially, the KyberSlash divisions themselves lie not in the base multiply (which uses fixed-time reduction) but in the secret-derived message decode and in the ciphertext compression of the Fujisaki–Okamoto re-encryption, both of which remain outside the protected boundary (Algorithm 2); KyberSlash is therefore not mitigated by this construction unless that boundary is extended, which we leave to future work.

5. Security Analysis

With the construction fully specified, we now analyze its security properties. This section establishes both the achieved guarantees (DCA resistance of share observation and division-timing freedom) and the fundamental limitations inherent to white-box cryptography.

5.1. Achieved Security Properties

We first state what is not achieved: under the full white-box adversary of Definition 6, the clear product coordinates $p_0,p_1$ (Algorithm 1, lines 1–2) and the recombined $\widehat{w}$ (Algorithm 2, line 5) are observable intermediates that each yield linear equations for $\widehat{s}$, so the construction provides no key confidentiality against that adversary; the two properties below are the partial guarantees it does deliver, each scoped to a strictly weaker adversary. First, Theorem 2 guarantees second-order DCA resistance of share observation: provided the masks are drawn from an entropy source external to, and unobservable within, the execution state (Remark 5), no key leakage follows from observing any two of the three product shares (information-theoretically). In Construction B the lookup index is the public ciphertext coordinate, so the base-multiply access pattern carries no secret, and the masking protects the product shares; in Construction A the secret $\widehat{s}$ is the index, and protection of the key value against index leakage rests on the shuffle and (unproven) encoding layers (Section 7.2). Full second-order security across all intermediates is not proven (see the limitations below). Second, Theorem 3 eliminates secret-dependent branches and variable-latency arithmetic within the protected base multiply, so it introduces no KyberSlash-style division-timing leak there; KyberSlash’s own divisions, in the unprotected decode and compression, are not addressed, and cache-line constant-time is not claimed.

The measured 11–26 MB of stored tables is a deployment cost and not a third property, and we withdraw the space-hardness reading of it on the strength of our own measurement. Reading 768 entries—1536 bytes, a measured $0.0139\%$ of the $11.08$ MB Construction-B core—regenerates all $\mathrm{7,670,016}$ bytes of that construction’s baked table set bit-exactly for 5 of 5 seeds and 384 of 384 component–polynomial pairs, a compression ratio of $4993.5\times$—and the regenerated tables reproduce decapsulation on 1000 of 1000 fresh random ciphertexts (results/table_extraction_witness.json). The cause is structural rather than incidental: each baked table $h_i^0\left[c\right]={\widehat{s}}_{0,i}c$ is ${\mathbb{Z}}_q$-linear in its public index, so a single read at any of the 3328 nonzero indices returns ${\widehat{s}}_{0,i}$ by a modular inverse, and blinding a distinguished index is therefore no repair; Construction A, whose shared table is a public function of q alone, is reproduced with no table read whatever (results/entry_determinacy.json).

This measurement does not overturn the paper’s confidentiality posture; it sharpens a concession the paper already makes. We concede above that $p_0,p_1$ are observable intermediates yielding linear equations for $\widehat{s}$, so key confidentiality against the full white-box adversary was never asserted and is not what is refuted here. What the witness adds is that the same leak is available far more cheaply and against a strictly weaker adversary: the conceded attack must observe a running execution, whereas this one issues no queries, collects no traces, performs 768 lookups against the static table set, and never inspects an access pattern. A scope hedge thereby becomes a number, and the honest reading of the megabytes follows: they are what a deployment must ship and hold resident, not a cost any adversary is obliged to pay.

Enlarging the tables cannot repair this. The read budget is the number of independent secret scalars times the bytes per entry—$768\times 2=1536$ bytes at $k=3$ and 0 for Construction A—an expression carrying no table-size term; consistently, when the stored set grows from the $7.67$ MB base to the $11.08$ MB core, the budget does not move, which is evidence of that independence rather than a proof of it. Nor is what separates these tables from the space-hard symmetric designs a matter of key-determinism. We built the control that settles this, following the space-hard design of Bogdanov and Isobe [24]: the same table shape, the same byte count, with entries drawn from real AES-128 instead of from $\widehat{s}$. Rebuilding it from its key reproduces it byte for byte, so it is every bit as key-determined as ours—and yet none of the 3328 candidate single-entry reads regenerates it, and predicting an unread entry from one that was read lands on the $1/q$ chance floor where Construction B lands on certainty. The difference is not what the tables are made of but how cheaply the making can be undone: our entries are a ${\mathbb{Z}}_q$-linear image of $\widehat{s}$, so one of them hands back the scalar that produced it, while a pseudorandom-function-keyed entry hands back nothing. The design criterion this yields—make the key-to-table map one-way rather than ${\mathbb{Z}}_q$-linear—recovers the Bogdanov–Isobe requirement exactly and is a positive outcome of the design-space mapping this paper sets out to perform.

Two readings must be resisted, each of which would overstate what has been measured. First, the 1536-byte figure is what this attack has to read off the shipped tables, and it should not be mistaken for how small $\widehat{s}$ can be written down. The same secret occupies 1152 bytes once packed by the FIPS 203 twelve-bit encoding [7], and a deployment that provisions from a seed carries it in 32; the 1536 bytes are an artifact of the 16-bit container the tables are built from, not a property of the secret. Second, no floor here is information-theoretic, and we claim none: the adversary holds $pk=(A,b=As+e)$, which determines $(s,e)$ uniquely with overwhelming probability, so an unbounded adversary recovers $sk$ at a budget of 0 with no table reads at all. Every floor in this construction is computational, resting on module learning-with-errors, and the tables contribute nothing to it.

Table 4. Comprehensive White-Box PQC Comparison. “Practical deployment: Yes (proj.)” is a footprint and latency judgment only and does not assert key confidentiality against the full white-box adversary (not achieved; the clear product intermediates $p_0,p_1$ are observable, Section 5); the “Masking-independence” row is scoped to share observation (Theorem 2).

Aspect	Bicakci [11]	Galissant [12]	This Work
PQC family	Hash-based	Multivariate	Lattice
Algorithm	SPHINCS+	HFE	ML-KEM-768
NIST standard	FIPS 205	None	FIPS 203
Implementation size	Medium	256 GB	11–26 MB
Practical deployment	Moderate	No	Yes (proj.)
Signature/CT size	≈8–50 KB	N/A	1088 B
Algebraic attack risk	Low	High	High (unprotected vs. informed adversary)
Masking-independence (standard)	No	N/A	Yes (Theorem 2)

positions these guarantees against the prior white-box post-quantum constructions.

5.2. Limitations and Open Attacks

We explicitly acknowledge the following limitations. First, we provide no incompressibility of either strength. Bock et al. [17] show the strong notion cannot be proven achievable for key-fixing encryption under standard assumptions (it remains attainable only in idealized models such as the random oracle), and our construction does not attain the weak notion (space-hardness) of Bogdanov–Isobe [24] either. That notion bounds only a table-access-bounded adversary—one that reads at most M bits of the tables and whose retained view is independent of the secret-dependent access pattern while being otherwise computationally unbounded—and the argument delivering it needs the table family to be entry-unpredictable, meaning that an entry omitted from that bounded read is not determined by the entries retained. Neither construction supplies such a family, Construction B’s baked tables being ${\mathbb{Z}}_q$-linear in the public index and regenerating from a single entry and Construction A’s shared table being a public function of q that carries no secret at all. The measured read budget at which the functionality is reproduced is accordingly 1536 bytes for Construction B and 0 for Construction A, in both cases independent of the footprint (results/entry_determinacy.json, results/table_extraction_witness.json). The limitation is therefore not the weaker one that a lower bound goes unproven: the hypothesis itself fails for these tables, no table size repairs it, and this concedes more than the theoretical limits of white-box cryptography require, being a measured property of these two constructions rather than an instance of Bock et al.’s proof barrier. Second, third-order and higher DCA (attacks combining three or more intermediate values) may succeed, since our 3-share masking protects only against ≤2-order attacks; higher-order masking ($t\ge 4$ shares) increases security at $O\left(t^2\right)$ overhead [29]. On this point we do not claim immunity to the deep-learning attacks of Dubrova et al. [36] against high-order masked Kyber: in the white-box model the attacker obtains noise-free intermediate values, so higher-order combining is if anything easier than in the gray box. Our DCA simulation (

Table 5. DCA Simulation Results. ${\rho }_{\max }$ denotes the correct-key correlation; the maximum over the 100 wrong-key hypotheses spans $0.028$–$0.106$ across the rows, and in every masked row, ${\rho }_{\max }$ falls below that row’s wrong-key maximum, itself within the null noise band. These rows characterize the masked share intermediates only: the clear product coordinate $p_0$, formed before masking (Algorithm 1), still leaks at the unmasked $\rho \approx 0.85$ level.

Implementation	Traces	${\mathit{\rho }}_{\max }$	Attack
Unmasked	1000	0.866	Success
Unmasked	10,000	0.853	Success
3-share masked	1000	0.031	Fail
3-share masked	5000	0.005	Fail
3-share masked	10,000	0.011	Fail

), which observes the masked shares (not the clear product coordinates $p_0,p_1$, which yield the key at first order and are conceded in Section 5.1), measures a first-order correlation of ${\rho }_{max}=0.011$ over 10,000 traces; Theorem 2 implies the true first-order correlation of the shares is 0, with the measured value lying near the sampling-noise floor ($1/\sqrt{N}=0.01$ for ${10}^4$ traces, statistically indistinguishable from zero), so the corresponding $\approx 2^{13}$ figure (the standard $1/{\rho }^2$ estimate with ${\rho }_{max}=0.011$) is an engineering estimate near the noise floor rather than a finite trace complexity extrapolable from this experiment; at the floor, $1/{\rho }^2$ simply returns the trace budget N. The three shares are uniform over ${\mathbb{Z}}_q$ by construction (Theorem 2); empirically, a ${\chi }^2$ goodness-of-fit test averaged over 100 regenerations gives mean $p\approx 0.50$, and the maximum absolute correlation of any share (or share pair) with the secret is $0.037$ and of a single masked output $0.023$—both within the noise band expected for a maximum over ∼256 hypotheses at the $1/\sqrt{N}=0.01$ per-test floor ($N=\mathrm{10,000}$ traces; share_statistics.py)—while 5-share masking would add margin at an estimated $4.03\times$ performance overhead and as a hypothetical fully gadget-masked Ishai–Sahai–Wagner (ISW) [48] $O\left(t^2\right)$ upper bound, with $2.78\times$ memory (scaling_analysis.py). Third, algebraic attacks exploiting the linear structure of NTT operations are analyzed and empirically mitigated but not proven secure: our experiments (

Table 6. Algebraic Attack Analysis Results. The $0\%$ row holds only against the mixing-unaware linear solver; a mixing-aware (informed) attacker inverts the public cube and recovers $128/128$ components (Section 5), so the scheme is unprotected against an informed adversary.

Implementation	Queries	Success	Error
Unprotected	1–2	100%	0.0
Protected (mixing + shuffle)	100	0% *	30,683.7

* 0% recovery is against the mixing-unaware linear solver; a mixing-aware attacker that inverts the public cubic map recovers $128/128$ components (Section 5). The Error column is the mean ${\ell }_2$ distance between the recovered and true secrets, averaged over the trials (algebraic_attack_analysis.json); it is finite because the linear system remained solvable and returned a wrong key, rather than becoming unsolvable. Protected implementation uses nonlinear mixing ($x^3\mathrm{mod}q$) and random shuffling. The relative cryptographic overhead of the mixing/shuffling layers is ≈1.6–3.3× ($N=20$ wall-clock, Table 7; Windows $1.61$, WSL $3.33$); absolute run times are platform-dependent single-run measurements and are omitted here.

) show $100\%$ key recovery with one–two queries on an unprotected implementation (solving a linear system over ${\mathbb{Z}}_q$) and $0\%$ against the mixing-unaware attacker once nonlinear mixing (the cubic power map $x\mapsto x^3\mathrm{mod}q$) and random coefficient shuffling are added (at an ≈1.6–3.3× full-protection overhead, $N=20$;

Table 7. Wall-clock measurements as the mean ± 95% confidence interval over $N=20$ independent runs in two environments on a single Intel Core i9-13980HX host: Windows 11 native (Python 3.12.6, liboqs 0.15.0 portable build) and WSL2 Ubuntu-20.04 (Python 3.8.10; liboqs unavailable). Dimensionless ratios are the build-stable, comparable metric; absolute liboqs times are build-specific.

Metric	Windows (Portable)	WSL/Linux
Protected-primitive overhead (×, RNG excl.)	$1.55\pm 0.08$	$1.60\pm 0.03$
Algebraic mixing overhead (×)	$1.57\pm 0.04$	$3.29\pm 0.09$
Algebraic shuffling overhead (×)	$1.00\pm 0.04$	$1.01\pm 0.03$
Algebraic full overhead (×)	$1.61\pm 0.06$	$3.33\pm 0.12$
liboqs decaps (ms)	$0.213\pm 0.009$	— *

Generated by wallclock_ci.py (results/wallclock_statistics_windows.json, …_wsl.json). The protected-primitive overhead (≈1.55–1.60×; a lower bound with the mask-generation RNG excluded, the faithful native-C primitive being $4.30\times$) is stable across both environments and supplies the RNG-excluded lower-bound term; the headline ≈47× anchors on the faithful native-C $4.30\times$ primitive (× the ≈11× cache factor), $17\times$ being the optimistic floor; the algebraic-countermeasure overhead is more platform-variable (≈1.6× Windows, ≈3.3× WSL). The WSL wall-clock run did not re-measure liboqs (module unavailable), so no portable liboqs decaps CI is reported for WSL (*); the committed x86-64 baseline is ≈0.19 ms (overhead_calculation.json, Table 8; a single run of the series whose $N=20$ mean, $0.213\pm 0.009$ ms above, supersedes it). Deterministic results (masking ${\chi }^2$, full ML-KEM-768 recovery, DCA correlation, footprints, NTT) reproduce exactly and are not repeated here.

), although a mixing-aware attacker can invert the public cubic map; these countermeasures break the linear structure exploited by Billet–Gilbert–Ech-Chatbi (BGE)-style attacks [18]. Fourth, learning-parity-with-noise (LPN)-based methods [49] can break masked implementations resistant to standard DCA, and their applicability to our construction is an open question. Fifth, our threat model excludes the fault-injection attacks of Kundu et al. [37] (Definition 6). Finally, although the table lookups are constant-time at the instruction level, cache-based side channels may leak access patterns if the adversary can observe cache state, and mitigation requires cache-oblivious access patterns (future work).

5.3. Why Only Decapsulation Is Protected

Our white-box protection targets decapsulation only. This design choice is intentional. Encapsulation, $\mathsf{Encaps}\left(pk\right)$, requires no secret—an attacker with code access already has $pk$ from the binary—whereas white-box attackers aim to extract the embedded secret key $sk$, which encapsulation never uses, so protecting encapsulation provides no security benefit and would merely double the implementation size, contrary to the principle of minimal sufficient protection. This also matches typical KEM deployment, in which the server holds $sk$ (and needs protection) while clients hold only the public $pk$; our construction accordingly protects the server-side decapsulation. One scope clarification is owed here because decapsulation is not free of encapsulation: per FIPS 203, $\mathsf{Decaps}$ internally re-executes the deterministic $\mathsf{K}-\mathsf{PKE}.\mathsf{Encrypt}(pk,m^{\prime };r^{\prime })$ (the encryption core of $\mathsf{Encaps}$) with $r^{\prime }=G\left(m^{\prime }\right)$ for the Fujisaki–Okamoto validity check. In our design this re-encryption is not integrated into the three-share masked table pipeline: it runs outside the table-protected boundary (Algorithm 2, the step marked “unprotected sub-step”), so the secret-derived message $m^{\prime }$ and the derived coins $r^{\prime }$ appear in the clear to a white-box observer. The reference implementation likewise exercises only the protected base-multiply primitive; the full FO loop is executed only by the unprotected liboqs baseline used for timing. Masking the FO re-encryption end-to-end—so that $m^{\prime }$ never materializes unshared—is future work, and this exposure is one of the concrete reasons we do not claim key confidentiality against the full white-box adversary.

6. Performance Evaluation

The security properties established in Section 5 were validated through extensive experimentation. This section presents performance benchmarks, DCA resistance measurements, and algebraic attack analysis on real implementations.

6.1. Implementation Details

Our implementation is provided as electronic Supplementary Materials with this article.

All experiments were run on a single Intel Core i9-13980HX host (32 logical cores, 32 GB RAM) in two environments—Windows 11 native (Python 3.12.6, liboqs 0.15.0 portable build) and WSL2 Ubuntu-20.04 (Python 3.8.10; liboqs unavailable, pure-Python overhead ratios only)—with ARM64 obtained by running AArch64 binaries under qemu-aarch64 user-mode emulation on that same host—QEMU emulates the ARM64 instruction set while the i9 performs the work, so the emulated figures characterize instruction-level behavior and carry no information about any ARM device’s clock, microarchitecture or memory latency—and with liboqs ML-KEM-768 (FIPS 203 compliant) [50,51] compiled by GCC 9.4.0 at -O3. The x86-64 liboqs baseline is taken over 10,000 iterations; the ARM64/QEMU baseline is the mean ± 95% confidence interval over $N=20$ independent qemu-aarch64 runs (code/c/build_arm64_benchmark.sh), and the ARM64/QEMU decapsulation baseline is $0.310\pm 0.015$ ms (a run-to-run coefficient of variation of ≈10%), reported for instruction-level calibration only—no projection anchors on it. The native x86 liboqs decapsulation figure is ≈0.19 ms (overhead_calculation.json), a single run of the series whose $N=20$ portable-Windows mean is $0.213\pm 0.009$ ms (mean ± 95% CI; Table 7); that mean is the value to read. Because absolute times are build- and platform-specific, dimensionless ratios rather than absolute times are the comparable metric. All wall-clock figures (masking overhead, algebraic-countermeasure overhead, and the portable-Windows liboqs baseline) are therefore reported as the mean ± 95% confidence interval (CI) over $N=20$ independent runs (wallclock_ci.py; Table 7), whereas deterministic results (masking ${\chi }^2$, the full ML-KEM-768 algebraic recovery, the DCA correlation, footprints, and the NTT factorization) use a fixed seed and reproduce exactly on any platform.

6.2. Performance Results

Table 8 presents baseline performance measurements across different platforms, while Table 9 analyzes the white-box overhead.

Table 8. Baseline Performance Measurements (x86-64 native; ARM64 under QEMU emulation on the same host).

Operation	x86-64 liboqs	ARM64 QEMU ($\mathit{N}=20$)
KeyGen	0.137 ms	$0.215\pm 0.006$ ms
Encaps	0.161 ms	$0.254\pm 0.011$ ms
Decaps	0.194 ms	$0.310\pm 0.015$ ms

x86-64 column: liboqs 0.15.0 baseline over 10,000 iterations (overhead_calculation.json); this decaps figure is one run of the series the portable-Windows statistic averages to $0.213\pm 0.009$ ms ($N=20$; Table 7), not an independent build, and the $N=20$ mean supersedes it. The ARM64 column is the mean ± 95% confidence interval over $N=20$ independent runs of a cross-compiled liboqs ML-KEM-768 benchmark under qemu-aarch64 user-mode emulation on the same i9-13980HX host (code/c/build_arm64_benchmark.sh, arm64_benchmark.json): QEMU emulates the ARM64 instruction set while the host CPU performs the work, so these figures characterize instruction-level behavior and are not the wall clock of any ARM device. Consistent with the rule stated in Section 4.2 and Section 6, the dimensionless ratio rather than the absolute emulated time is the comparable metric.

Table 8. Baseline Performance Measurements (x86-64 native; ARM64 under QEMU emulation on the same host).

Operation	x86-64 liboqs	ARM64 QEMU ($\mathit{N}=20$)
KeyGen	0.137 ms	$0.215\pm 0.006$ ms
Encaps	0.161 ms	$0.254\pm 0.011$ ms
Decaps	0.194 ms	$0.310\pm 0.015$ ms

x86-64 column: liboqs 0.15.0 baseline over 10,000 iterations (overhead_calculation.json); this decaps figure is one run of the series the portable-Windows statistic averages to $0.213\pm 0.009$ ms ($N=20$; Table 7), not an independent build, and the $N=20$ mean supersedes it. The ARM64 column is the mean ± 95% confidence interval over $N=20$ independent runs of a cross-compiled liboqs ML-KEM-768 benchmark under qemu-aarch64 user-mode emulation on the same i9-13980HX host (code/c/build_arm64_benchmark.sh, arm64_benchmark.json): QEMU emulates the ARM64 instruction set while the host CPU performs the work, so these figures characterize instruction-level behavior and are not the wall clock of any ARM device. Consistent with the rule stated in Section 4.2 and Section 6, the dimensionless ratio rather than the absolute emulated time is the comparable metric.

Table 9. White-Box Overhead Analysis.

Metric	Value	Notes
Overhead factor	≈47× (proj.)	$4.30\times$ native protected primitive × ≈11× cache; $17\times$ with the RNG-excluded $1.55\times$ lower bound
Est. WB decaps (x86-64 host)	≈10 ms (7–14)	Based on 0.213 ms × 47, ±35% band; no ARM-device measurement
Storage	11–26 MB	Construction B/A measured core

The ≈47× factor is a projection. The ≈1.55× term is the $N=20$ mean of wallclock_ci.py (Table 7; Windows, $1.60\times$ WSL) for a table lookup plus three-share recombination versus direct arithmetic; it is a lower bound on masking cost because the Python timing loop (measure_overhead in whitebox_reference.py) substitutes a deterministic stand-in for the per-share mask-generation randomness and so excludes the RNG cost. The faithful native-C protected primitive, with a real pseudo-random number generator (PRNG), measures $4.30\times$ (x86-64) and $2.85\times$ (aarch64); that figure anchors the headline ≈$4.30\times 11\approx 47\times$ projection, while the RNG-excluded $1.55\times$ term gives the $17\times$ floor. The ≈11× cache factor (Table 10) models the same table lookup already inside the $1.55\times$ term, so the two factors are not strictly independent; we therefore report ≈47× as the headline projection—not a conservative upper bound—and $17\times$ as its optimistic, RNG-excluded lower bound. The ≈10 ms figure is the point estimate; with the ±35% platform-variance band of Table 12, it spans the 7–14 ms range reported there.

Table 9. White-Box Overhead Analysis.

Metric	Value	Notes
Overhead factor	≈47× (proj.)	$4.30\times$ native protected primitive × ≈11× cache; $17\times$ with the RNG-excluded $1.55\times$ lower bound
Est. WB decaps (x86-64 host)	≈10 ms (7–14)	Based on 0.213 ms × 47, ±35% band; no ARM-device measurement
Storage	11–26 MB	Construction B/A measured core

The ≈47× factor is a projection. The ≈1.55× term is the $N=20$ mean of wallclock_ci.py (Table 7; Windows, $1.60\times$ WSL) for a table lookup plus three-share recombination versus direct arithmetic; it is a lower bound on masking cost because the Python timing loop (measure_overhead in whitebox_reference.py) substitutes a deterministic stand-in for the per-share mask-generation randomness and so excludes the RNG cost. The faithful native-C protected primitive, with a real pseudo-random number generator (PRNG), measures $4.30\times$ (x86-64) and $2.85\times$ (aarch64); that figure anchors the headline ≈$4.30\times 11\approx 47\times$ projection, while the RNG-excluded $1.55\times$ term gives the $17\times$ floor. The ≈11× cache factor (Table 10) models the same table lookup already inside the $1.55\times$ term, so the two factors are not strictly independent; we therefore report ≈47× as the headline projection—not a conservative upper bound—and $17\times$ as its optimistic, RNG-excluded lower bound. The ≈10 ms figure is the point estimate; with the ±35% platform-variance band of Table 12, it spans the 7–14 ms range reported there.

We directly measured the cache-miss factor. The ≈11× term in the ≈47× projection models the cost of replacing arithmetic base multiplication with lookups into the multi-megabyte white-box tables on a memory-constrained target. We measured this on the host (i9-13980HX; cache_effect.c, results/cache_effect.json) with a dependency-chained pointer chase (Sattolo random cycle over 64-byte nodes), which isolates true random-access latency as a function of working-set size (Table 10). A working set matching the $7.67$ MB Construction-B table set is L3-resident on this desktop, its random-access latency already costing ≈63× an L1-resident access; the penalty rises to ≈71× only once the working set exceeds the 36 MB L3 and spills to DRAM (Table 10). This worst-case per-access latency is not the base-multiply penalty, however: on this desktop, deep out-of-order execution amortizes independent lookups against arithmetic, so the realistic cold primitive-level penalty is only ≈1.9× (cache_effect.json). The deployed overhead is therefore genuinely uncertain and cache-dominated; the ≈11× embedded cache factor used in our projection is a mid-estimate between this desktop-realistic ≈1.9× and the ≈63× worst-case random-access latency and is an embedded-target estimate rather than a desktop measurement.

Table 10. Measured random-access latency versus working-set size (pointer chase, 64-byte nodes, i9-13980HX; cache_effect.c). The 7.67 MB row matches the Construction-B table set.

Working Set	ns/Access	Penalty vs. L1
16 KB (L1)	1.6	1.0×
256 KB (L2)	4.9	≈3×
2 MB (L2 edge)	10.3	≈6×
7.67 MB (tables)	102.6	≈63×
36 MB (L3 edge)	111.2	≈69×
64 MB (DRAM)	114.7	≈71×

Bold marks the working set corresponding to the Construction-B tables. Representative single-host run (cache_effect.c, seed 42); run-to-run spread is not measured. The $7.67$ MB Construction-B tables are L3-resident on this desktop (≈63× an L1 access), the DRAM regime (≈71×) being reached only by the 64 MB row; this worst-case random-access latency brackets the ≈11× embedded cache factor of the ≈47× projection from above, while out-of-order execution on this desktop yields a realistic amortized primitive penalty of only ≈1.9×.

Table 10. Measured random-access latency versus working-set size (pointer chase, 64-byte nodes, i9-13980HX; cache_effect.c). The 7.67 MB row matches the Construction-B table set.

Working Set	ns/Access	Penalty vs. L1
16 KB (L1)	1.6	1.0×
256 KB (L2)	4.9	≈3×
2 MB (L2 edge)	10.3	≈6×
7.67 MB (tables)	102.6	≈63×
36 MB (L3 edge)	111.2	≈69×
64 MB (DRAM)	114.7	≈71×

Bold marks the working set corresponding to the Construction-B tables. Representative single-host run (cache_effect.c, seed 42); run-to-run spread is not measured. The $7.67$ MB Construction-B tables are L3-resident on this desktop (≈63× an L1 access), the DRAM regime (≈71×) being reached only by the 64 MB row; this worst-case random-access latency brackets the ≈11× embedded cache factor of the ≈47× projection from above, while out-of-order execution on this desktop yields a realistic amortized primitive penalty of only ≈1.9×.

The measured footprint places the construction comfortably within gateway-class memory budgets.

Table 11. Deployment suitability using the Construction A deployment total (≈26 MB, the conservative case; Construction B is ≈11 MB, about half). ECU denotes an electronic control unit. Suitability is a footprint judgment only—no timing is measured on these devices, and fitting the tables does not confer key confidentiality against the full white-box adversary (Section 5).

Platform	RAM	26 MB %	Suitable
Raspberry Pi 4	4 GB	0.6%	Yes
Automotive ECU	512 MB–2 GB	1.2–5.0%	Yes
Edge server	16+ GB	<0.2%	Yes
Industrial gateway	256 MB–1 GB	2.5–10.0%	Yes
IoT sensor	32–256 KB	N/A	No

summarizes the suitability of our white-box implementation across various deployment platforms based on memory requirements.

6.3. DCA Resistance Evaluation

We conducted a DCA simulation following the methodology of Bos et al. [4], collecting 10,000 traces (a budget that reaches the $1/\sqrt{N}=0.01$ detection floor) under a Hamming-weight leakage model of the intermediate values and targeting the secret-key coefficients in the NTT domain.

The unmasked implementation yields a correlation of $\rho =0.85$ over 10,000 traces (the attack succeeds, $p\approx 1.8\times {10}^{-214}$; dca_simulation.json), whereas the 3-share masked implementation gives a correct-key correlation ${\rho }_{max}=0.011$ (the maximum over the 100 wrong-key hypotheses is $0.031$ on this row, within the null band expected for a maximum over that many tests at the $0.01$ per-test floor): the correct-key correlation drops from $0.85$ to $0.011$, about $1.1\times$ the $1/\sqrt{N}=0.01$ floor and below the $0.031$ wrong-key maximum, and the attack—whose success criterion is that the correct-key correlation rise above the wrong-key spread—fails, so no first-order leakage is detectable at this trace budget.

The 3-share masking reduces the measured correlation from $\rho =0.85$ (unmasked) to ${\rho }_{max}=0.011$ (masked)—about $1.1\times$ the $1/\sqrt{N}=0.01$ sampling-noise floor for 10,000 traces and below the $0.031$ wrong-key maximum—so no first-order leakage is detectable at this trace budget. (The machine-readable dca_simulation.json sets its Boolean resistant field by the stricter naive ${\rho }_{max}<0.01$ noise-floor test, which $0.011$ marginally exceeds; the operative distinguishing criterion applied here—correct-key $0.011$ below the $0.031$ wrong-key maximum—is what determines that the attack fails.) The masked correct-key correlations ($0.031$, $0.005$, $0.011$ at $1000/5000/\mathrm{10,000}$ traces) are non-monotone because all three are sampling-noise-floor values (≈$1/\sqrt{N}$) rather than a decaying signal; in particular the 1000-trace masked correct-key value ($0.031$) coincidentally equals the $\mathrm{10,000}$-trace wrong-key maximum ($0.031$), both being noise-band samples and neither a detectable leak. The reduction ratio is taken against the noise floor and is therefore not itself a security level. The simulation uses a gray-box Hamming-weight leakage model; in the noise-free white-box model, higher-order combining is easier (as noted for Dubrova et al.), so these first-order figures characterize the masked share intermediates rather than a whole-program white-box guarantee. Concretely, the harness models the sensitive intermediate as a coefficient-wise secret-times-ciphertext product—a scalar stand-in for the degree-2 base multiply in ${\mathbb{Z}}_q\left[X\right]/(X^2-{\gamma }_i)$—input-masks the secret into its three shares, and runs the distinguisher against 100 independent uniformly random wrong keys at a single fixed Hamming-weight noise level; it therefore certifies only that the masked shares of that product sit at the noise floor, whereas the clear product coordinate $p_0$ formed before masking (Algorithm 1) still leaks at the unmasked $\rho \approx 0.85$ level.

6.4. Algebraic Attack Resistance

We conducted experimental analysis of algebraic attacks exploiting NTT linearity. Table 6 presents the results.

The NTT multiplication $\widehat{s}·\widehat{c}$ is linear in the secret key coefficients $\widehat{s}$. Given input–output pairs $(c_i,P\left(c_i\right))$, an attacker can construct a system of linear equations over ${\mathbb{Z}}_q$:

$$A·\widehat{s}=b\left(\mathrm{mod}q\right),$$

(10)

where A depends on ciphertext values and b on observed outputs. With $n=256$ unknowns, a single query provides n equations—sufficient for a unique solution via Gaussian elimination over ${\mathbb{Z}}_q$.

We apply nonlinear mixing ($x\mapsto x^3\mathrm{mod}q$) before table lookup, breaking the plain linear-solve attack tested here. We stress the scope of this result: the cubic map is a public bijection ($\gcd (3,q-1)=1$, inverse exponent 2219), so a mixing-aware attacker can invert it and re-linearize; the observed $0\%$ recovery holds only against the mixing-unaware adversary in our harness. Two clarifications sharpen what is protective. Random coefficient shuffling is a linear permutation: composed with the linear NTT the system stays linear, so shuffling adds obfuscation but no algebraic hardness—the plain linear solver still recovers the secret from shuffled intermediates. Genuine algebraic protection must therefore come from secret nonlinear encodings on the table outputs, which we instantiate and measure below (Proposition 1); their structural security remains open (Section 7.2). The single-run ≈$1.63\times$ figure (algebraic_attack_analysis.json) is the cryptographic overhead of the mixing/shuffling layers, consistent with the ≈1.6–3.3× range measured over $N=20$ runs in Table 7; neither is a security level.

Lemma 1 

(Encoding key entropy). A uniformly random bijection $E:{\mathbb{Z}}_q\to {\mathbb{Z}}_q$ is one of $q!$ equiprobable maps, so its key entropy is $H\left(E\right)={\log }_2(q!)={\sum }_{j=1}^q{\log }_{2}j$ bits; for $q=3329$ this is ≈$3.4\times {10}^4$ bits. The base-multiplication encoding layer applies 128 components $\times 2$ output coordinates $=256$ independent such bijections, drawing from a key space of ${(q!)}^{256}$, i.e., ≈$256{\log }_2(q!)\approx 8.7\times {10}^6$ bits of encoding key material.

Proposition 1 

(Conditional Algebraic Security under Secret Encodings). Wrap each NTT component’s two base-multiplication output coordinates in secret bijections $E_{i,j}:{\mathbb{Z}}_q\to {\mathbb{Z}}_q$, each realized as a q-entry lookup table sampled by a keyed Fisher–Yates shuffle (its inverse stored alongside) and drawn uniformly from the $q!$ bijections of ${\mathbb{Z}}_q$ (carrying ${\log }_2(q!)\approx 3.4\times {10}^4$ bits of key entropy, Lemma 1). If the encodings are structurally indistinguishable from random bijections—no efficient algorithm recovers $E_{i,j}$ from the encoded implementation faster than exhausting its key—then the plain NTT-linearity attack above, which operates on the unencoded intermediates, does not recover the secret: the attacker must first strip an encoding.

We realize this layer concretely (whitebox_encoded.py): correctness is preserved (the matching inverse decodes to the exact product over 5000 trials across all 128 components) at a measured $3.41$ MB encoding-table cost (the base-multiplication output-encoding sublayer, i.e., the measured encoding sublayer of Table 3), and the plain linear-solve’s per-component recovery drops from $128/128$ on unencoded intermediates to $\mathbf{0}/\mathbf{128}$ against the encoding-unaware (mixing-aware) attacker, while an encoding-aware attacker still recovers $128/128$—confirming the encoding is the sole barrier (results/whitebox_encoded.json). We stress the scope of this result under Definition 6: a nonlinear bijection is not additively homomorphic, and the product $p_0=h_i^0\left[c_0\right]+h_i^2\left[c_1\right]$ (Algorithm 1) is formed by adding two clear lookups, so the clear $p_0,p_1$ are observable intermediates that already yield linear equations for the secret. The measured $0/128$ recovery is therefore against an adversary restricted to the encoded outputs—a restriction of the full white-box model, paralleling the composed-product limitation of the masking analysis. Hiding the clear product would require an encoded-addition mechanism, and we can now say something firmer about that mechanism than that it is future work: it is foreclosed by the same linearity the extraction witness exploits rather than priced out by footprint. Two cases exhaust the possibilities, and each fails structurally. If the encoding is ${\mathbb{Z}}_q$-linear or affine, the plain modular adder of Algorithm 1 stays correct on encoded operands, but the encoded table is then itself ${\mathbb{Z}}_q$-linear in its public index, so one read at a nonzero index recovers its scalar by a modular inverse, and the extraction of Section 5 applies verbatim at the same 1536 bytes; such an encoding changes what the table stores and not how little of it must be read. If instead the encoding is a random bijection of ${\mathbb{Z}}_q$—the layer this paper actually instantiates, which we measure to be entry-unpredictable, its entry-determinacy degree being the full $q-1=3328$ and prediction of an omitted entry from a half-retained table sitting at the ≈$6.0\times {10}^{-4}$ bijectivity-aware chance floor (results/encoding_layer_entropy.json)—then it is not additively homomorphic, $E\left(a\right)+E\left(b\right)$ agreeing with $E(a+b)$ only by chance at probability ≈$1/q$, and the addition must itself be tabulated over encoded operands: a different mechanism, not the present one enlarged. Entry-unpredictability and compatibility with the plain adder are thus at odds, and the obstacle is linearity rather than megabytes, so the repair calls for a one-way key-to-table map. We are explicit about what this does not establish: it does not show encoded addition to be impossible, since a tabulated encoded adder is constructible with both its cost and its security left open, and it bears on no claim made in this paper, which instantiates no encoded adder and asserts no confidentiality that one would be needed to support. What it forecloses is the cheap repair, and it forecloses substituting a larger table set for that repair.

The premise is the open problem, not a fact. Structural indistinguishability of table encodings was refuted for AES by the BGE attack [18], which peeled Chow et al.’s encodings [1,2] from the algebraic structure of the encoded S-box network; later attacks [19,20,52] and the WhibOx competitions [21,22] confirmed that table encodings are eventually stripped. BGE does not port verbatim—it exploits that each AES encoded lookup is an ${\mathbb{F}}_{2^8}$ affine-equivalent of a known S-box, whereas our tables encode an arithmetic product over ${\mathbb{Z}}_q$ (base multiplication in ${\mathbb{Z}}_q\left[X\right]/(X^2-{\gamma }_i)$) with output-side nonlinear bijections, so the affine-peeling step has no direct analogue—but this only means such an attack must be re-derived for the arithmetic setting, not that it fails. Whether a structural attack recovers the arithmetic encodings is the central open problem of the construction (Section 7.2); we neither assume nor claim it fails.

The nonlinear-mixing overhead is ≈1.6–3.3× (Windows $1.57\pm 0.04$, WSL/Linux $3.29\pm 0.09$; $N=20$ mean ± 95% CI, Table 7), the shuffling overhead is ≈1.0× (Windows $1.00\pm 0.04$, WSL $1.01\pm 0.03$; a security-neutral linear permutation), and full protection (mixing plus shuffling) costs ≈1.6–3.3× (Windows $1.61\pm 0.06$, WSL/Linux $3.33\pm 0.12$; $N=20$).

The ≈1.6–3.3× overhead for algebraic protection is acceptable given that no successful key recovery was observed in our 100-query simulation; we emphasize this is an empirical negative result for the tested attack configuration, not a proof (see Section 7.2).

6.5. Memory Overhead Justification

The 11–26 MB footprint warrants explicit justification.

For comparison, the Galissant–Goubin 2022 [12] HFE white box requires 256 GB (about $\mathrm{11,600}\times$ the $22.16$ MB (A) and $\mathrm{33,400}\times$ the $7.67$ MB (B) base tables)—their 2025 CASCADE version reduces this to 94–752 MB—and standard white-box AES (Chow et al. [1]) about $0.75$ MB in total, whereas our ML-KEM-768 construction occupies 11–26 MB (Constructions B/A deployment total)—about 15–$34\times$ that of white-box AES, but still under $1\%$ of a 4 GB device’s RAM.

This size is acceptable for the intended setting. The target deployment is gateway-class devices (Raspberry Pi 4, edge servers, automotive ECUs, industrial gateways) with 256 MB–$16+$ GB RAM, where an 11–26 MB library consumes from <0.2% to $10.0$% of available memory across the tabulated targets (Table 11), staying under $4\%$ only on devices with ≳1 GB RAM, and the tables are loaded once at initialization with only the relevant entries accessed during operation. On the security–storage trade-off there is, in the end, no trade to make. The measured core—≈$2^{24.6}$ bytes (Construction A, $25.57$ MB) or ≈$2^{23.4}$ bytes (Construction B, $11.08$ MB)—is the size of the artifact a deployment ships and holds resident, and it is not a quantity any adversary is obliged to copy. Section 5 measures what actually suffices: 1536 bytes of table reads for Construction B, which regenerate its $\mathrm{7,670,016}$-byte baked set bit-exactly and reproduce decapsulation on 1000 of 1000 fresh random ciphertexts and nothing at all for Construction A, whose shared multiply table $M\left[x\right]\left[y\right]=x·y\mathrm{mod}q$ is public and regenerable in one line of code and whose secret operand $\widehat{s}$ is a plain program array rather than table content (results/table_extraction_witness.json). Neither budget grows with the tables, so smaller tables would not lower a cost that is already independent of them. The secret-bearing material is the output encoding together with the ∼KB secret key, and here too the storage figure must not be read as key material: of the 512 stored encoding tables, only 256 are independent, each inverse being reconstructible from its forward map, so the layer carries $256{\log }_2(q!)\approx 1.09$ MB $=2^{20.06}$ bytes of entropy while occupying $3.41$ MB, overstating the secret-bearing material by a measured factor of $3.12$ (results/encoding_layer_entropy.json). For bandwidth context, a typical 4K video stream requires on the order of 15–25 Mbps, so the 11–26 MB library download is equivalent to roughly 4–14 s of video streaming.

The construction is not suitable for microcontrollers (<1 MB RAM), mobile apps requiring instant startup, or bandwidth-constrained over-the-air (OTA) updates.

6.6. Performance vs. Security Trade-Off

Figure 3 visualizes the trade-off between modeled security exponents and performance overhead for different masking configurations.

Three-share masking is the sweet spot, placing the modeled first-order trace-complexity estimate at ≈2¹² for an acceptable ≈47× overhead. Two cautions govern how that figure may be read, and they are the reason we plot the model rather than our measurement. First, the exponent is modeled, not measured: every $\ge 2$-share arithmetic masking with fresh, unobservable mask randomness has zero true first-order leakage (Theorem 2), so no share count on this axis carries an empirical first-order figure. Second, our own measurement cannot fill that gap even in principle. We measure ${\rho }_{max}=0.011$ over ${10}^4$ traces (Table 5), which yields $1/{\rho }^2\approx 2^{13}$, but ${\rho }_{max}$ sits at the sampling-noise floor ($1/\sqrt{N}=0.01$ for $N={10}^4$), so $1/{\rho }^2$ recovers the trace budget N rather than any property of the construction—which is precisely why it agrees with the ≳$2^{13}$-trace non-detection floor. It records how far the experiment reached, not how much leakage would resist an attacker, and a larger trace budget would move it. Returns diminish thereafter—each additional share raises the estimate by one security order (the $6\to 12\to 18\to 24$ security exponents follow the same illustrative 6-bits-per-order model) at ∼1.8× overhead per step—so that, for mission-critical applications, 5-share masking reaches ≈2²⁴ at ∼131× overhead (≈2.78× the 3-share overhead, from the script’s modeled $4.03\times$ versus $1.45\times$ per-share performance factors (the modeled 3-share analogue of the measured $1.55\pm 0.08$) and $2.78\times$ memory factors, the memory factor being a hypothetical fully-gadget-masked ISW $O\left(t^2\right)$ upper bound; scaling_analysis.py).

6.7. ML-KEM Parameter Scaling Analysis

Table 12 projects overhead for different ML-KEM security levels.

The overhead scales slightly superlinearly ($k^{1.1}$) with module rank k, not exponentially. ML-KEM-1024 (NIST Level 5) remains practical at a ≈14 MB Construction-B core—with the same ≈26 MB Construction-A deployment total as every other set since Construction A is k-independent—and is suitable for gateway- and server-class deployments requiring the highest security.

Table 12. White-Box Overhead Scaling by ML-KEM Parameter Set.

Parameter	ML-KEM-512	ML-KEM-768	ML-KEM-1024
Module rank k	2	3	4
NIST Level	1	3	5
NTT factors (constant)	128	128	128
Component mult. ($k\times 128$)	256	384	512
Construction-B core (est.)	≈9 MB	≈11 MB	≈14 MB
Decaps overhead	≈30×	≈47×	≈64×
Decaps time (est.)	4–9 ms	7–14 ms	9–18 ms
Target RAM	≥64 MB	≥64 MB	≥64 MB

Projections from the ML-KEM-768 base, anchored on the ≈47× projection of Table 9, using an assumed $k^{1.1}$ superlinear scaling (per-set deployment factors computed directly from the $47\times$ anchor by scaling_analysis.py; computed, not measured). NTT structure (128 factors) is constant across all parameter sets. The decapsulation-time ranges apply a $\pm 35\%$ platform-variance band to the per-set $k^{1.1}$ overhead; the ML-KEM-768 entry (7–14 ms) brackets the ≈10 ms host-anchored estimate ($0.213$ ms × 47) of Table 9; no ARM-device time is claimed. The size row reports the Construction-B core (base multiply plus the $3.41$ MB encoding sublayer), which scales with k; Construction A is k-independent at $25.57$ MB core ($25.58$ MB deployment total) for every parameter set, so with Construction A included the deployment envelope is 11–26 MB for ML-KEM-768, widening to ≈9–26 MB once ML-KEM-512’s smaller Construction-B core is included; the security-level ordering ($512<768<1024$) is carried by the Construction-B core. The footprint scales with the module rank k: Construction B’s q-entry tables are built from the full-range NTT-domain secret (indexed by the public ciphertext coordinate), independent of the coefficient-domain ${\eta }_1$.

Table 12. White-Box Overhead Scaling by ML-KEM Parameter Set.

Parameter	ML-KEM-512	ML-KEM-768	ML-KEM-1024
Module rank k	2	3	4
NIST Level	1	3	5
NTT factors (constant)	128	128	128
Component mult. ($k\times 128$)	256	384	512
Construction-B core (est.)	≈9 MB	≈11 MB	≈14 MB
Decaps overhead	≈30×	≈47×	≈64×
Decaps time (est.)	4–9 ms	7–14 ms	9–18 ms
Target RAM	≥64 MB	≥64 MB	≥64 MB

Projections from the ML-KEM-768 base, anchored on the ≈47× projection of Table 9, using an assumed $k^{1.1}$ superlinear scaling (per-set deployment factors computed directly from the $47\times$ anchor by scaling_analysis.py; computed, not measured). NTT structure (128 factors) is constant across all parameter sets. The decapsulation-time ranges apply a $\pm 35\%$ platform-variance band to the per-set $k^{1.1}$ overhead; the ML-KEM-768 entry (7–14 ms) brackets the ≈10 ms host-anchored estimate ($0.213$ ms × 47) of Table 9; no ARM-device time is claimed. The size row reports the Construction-B core (base multiply plus the $3.41$ MB encoding sublayer), which scales with k; Construction A is k-independent at $25.57$ MB core ($25.58$ MB deployment total) for every parameter set, so with Construction A included the deployment envelope is 11–26 MB for ML-KEM-768, widening to ≈9–26 MB once ML-KEM-512’s smaller Construction-B core is included; the security-level ordering ($512<768<1024$) is carried by the Construction-B core. The footprint scales with the module rank k: Construction B’s q-entry tables are built from the full-range NTT-domain secret (indexed by the public ciphertext coordinate), independent of the coefficient-domain ${\eta }_1$.

6.8. Summary of Results

Table 13. Summary of Formal Results and Verification Methods.

#	Result	Type	Exp.	Verification
1	NTT Factorization	Struct.	✓	SageMath
2	NTT-domain secret range	Obs.	✓	Python
3	Masking Security	Pos.	✓	Python/DCA
4	DCA Complexity	Cor.	–	Analytical
5	Constant-Time Ops	Pos.	✓	Structural
6	Encoding key entropy	Struct.	–	Analytical
7	Cond. algebraic security	Cond.	✓	Premise open (Section 7.2)

Type: Struct. = Structural, Obs. = Observation, Pos. = Positive, Cor. = Corollary, Cond. = Conditional. Exp. = Experimentally validated: a check mark marks a result corroborated by an accompanying experiment, and a dash marks one established analytically. Entry 2 is an observation (Remark 3) reporting a measured rate, not a formal result. Entry 7’s encoding layer is realized and measured (whitebox_encoded.py); its structural-indistinguishability premise is the open problem of Section 7.2, not a verified fact.

and 

Table 14. Experimental Validation Results.

Theorem	Metric	Value	Status
Theorem 2 (share obs.)	3-share ${\rho }_{\max }$ (10 K traces)	0.011	Pass
	Correlation near noise floor ($0.85\to 0.011$)	${\rho }_{\max }<{\rho }_{\mathrm{wrong}}$	Pass
RNG sanity check	Share uniformity (mean ${\chi }^2$ p)	0.50	Pass
Theorem 3 (Timing)	No secret-dependent branch	True	Pass
	No data-dependent division/reduction	True	Pass
Theorem 1 (NTT)	$256\mid (q-1)$	True	Pass
	${\zeta }^{256}=1$	True	Pass
	${\zeta }^{128}=-1$	True	Pass
	128 irreducible factors	True	Pass

The masking block is a scoped share-observation DCA result (Section 6), not a whole-program validation of Theorem 2; the clear product coordinates $p_0,p_1$ formed before masking (Algorithm 1), are outside this result and leak at the unmasked level; the ${\chi }^2$ row is an RNG/share-uniformity sanity check (mask uniformity), not a Theorem 2 validation. Here ${\rho }_{\mathrm{wrong}}$ is the maximum wrong-key correlation (0.031) and ${\rho }_{\max }$ the correct-key correlation. Masking metrics are from dca_simulation.py and share_statistics.py; timing rows were verified structurally by code inspection; NTT identities were verified by ntt_verification.sage. All values trace to results/.

provide comprehensive summaries of our theoretical contributions and experimental validation.

7. Conclusions and Future Work

7.1. Contributions and Practical Limits

We present PQ-WB-KEM, to the best of our knowledge, the first systematic feasibility study of table-based white-boxing for a lattice-based NIST post-quantum standard, specifically ML-KEM-768 (NIST FIPS 203). Our construction correctly handles NTT domain structure (128 degree-2 extensions, not 256 scalars), applies arithmetic masking appropriate for ${\mathbb{Z}}_q$ with a formal masking-independence proof, and achieves measurable DCA resistance of the masked share observations, with no division-timing leakage in the protected base multiply (cache-line constant-time is not claimed). A working reference implementation verifies correct base multiplication over 5000 random inputs across all 128 components and measures a native ≈4.30× overhead for the protected primitive (Construction B), with the base tables occupying a measured $7.67$ MB (Construction A: $22.16$ MB).

In contrast to work by Bicakci et al. [11] (hash-based SPHINCS+) and Galissant–Goubin [12] (multivariate HFE, 256 GB), our 11–26 MB lattice-based approach targets the primary NIST standard with practical deployment feasibility.

In an honest assessment, strong white-box security (incompressibility) has no proof of achievability under standard assumptions for standard ciphers [17]. Our contribution is a systematic exploration of what can be done for lattice cryptography: second-order DCA resistance of share observation (the measured correlation drops from $\rho =0.85$ to the noise floor $\rho =0.011$) and division-timing freedom. Space-hardness is not among them, and we withdraw it on the strength of our own measurement rather than as a hedge: 1536 bytes of Construction B’s tables regenerate all $\mathrm{7,670,016}$ bytes bit-exactly and decapsulate fresh ciphertexts at $Z=1.0$, while Construction A needs no table read whatever, so the 11–26 MB is a deployment cost and mapping a design space includes reporting where its floors turn out not to exist. We explicitly acknowledge that algebraic attacks remain an open threat requiring further investigation.

In terms of practical constraints, the 11–26 MB footprint and the estimated ≈47× deployment overhead—the faithful native-C $4.30\times$ masking cost projected under an embedded ≈11× cache-miss factor, the RNG-excluded harness giving a $17\times$ floor—restrict deployment to gateway-class devices with ≥64 MB RAM and tolerance for an estimated 7–14 ms latency (host-anchored projection; no ARM-device measurement).

In plain terms, an attacker who observes the entire running program does not recover the key from the masked product shares by statistical (DCA) or timing analysis at the measured level, provided the per-decapsulation mask randomness is drawn from an entropy source external to, and unobservable within, that execution state (Theorem 2). However, the product coordinates $p_0,p_1$ are formed by adding clear lookups before masking and encoding, so under the full white-box model, they are observable intermediates that yield linear equations for the secret, and the encoding’s measured protection is only against an adversary restricted to the encoded outputs. Hiding the clear product through an encoded-addition mechanism is foreclosed by the same linearity rather than mere cost: a linear encoding preserves the plain adder but leaves the tables regenerable from a single entry, while the random-bijection encoding we instantiate is not additively homomorphic and would demand a tabulated encoded adder—a different mechanism rather than this one enlarged (Section 6). Whether the table encodings can be algebraically unraveled—the arithmetic-encoding analogue of the AES BGE attack—remains the priority open question for future work.

7.2. Open Problems and Future Work

The central open problem is the structural cryptanalysis of the arithmetic table encodings. The plain NTT-linearity attack is defeated by the secret nonlinear encoding layer of Proposition 1 (measured per-component recovery $0/128$ against the encoding-unaware, mixing-aware attacker) but only under the unproven premise that the encodings are structurally indistinguishable from random bijections; whether a BGE-style structural attack [18]—which refutes exactly this premise for AES—can be re-derived to recover the arithmetic encodings over ${\mathbb{Z}}_q$ is the central unresolved question, and a formal security proof (or an attack) remains open. On higher-order masking trade-offs, the illustrative 6-bits-per-order model of Figure 3 places our 3-share implementation at $\approx 2^{12}$ (a modeled projection at its security order, not a measurement) for an 11–26 MB footprint and ≈47× overhead, whereas 5-share masking would raise the modeled figure to $\approx 2^{24}$ at an estimated ≈2.8× additional performance cost and, as a hypothetical fully gadget-masked upper bound (an ISW [48] $O\left(t^2\right)$ model that stores masked tables), require ≈2.8× additional memory (≈31 MB) over the 3-share configuration (the $4.03\times$-versus-$1.45\times$ performance and $2.78\times$ memory factors, computed from the assumed white-box constants by scaling_analysis.py). The runtime output-masking design of Table 3 stores no masked tables—masks are applied to lookup outputs at decapsulation time—so its true higher-order memory cost grows only in mask-generation randomness and share state, $O\left(t\right)$, not in stored tables; the $2.78\times$ figure is the pessimistic gadget-masked bound. The optimal number of shares t for a given deployment is left to further analysis. Further directions include validation of the projected overheads on physical ARM hardware since every figure reported here is an emulation- or host-derived projection; a dedicated white-box lattice cipher (analogous to SPACE [24] for symmetric ciphers, optimized for table-based implementation from the start); cache-oblivious access for Construction A, whose naive oblivious form is a prohibitive ≈q-fold (≈3329×) full-column scan per lookup (Construction B already avoids the channel by indexing on the public ciphertext); a hardware-assisted hybrid using ARM TrustZone [53] or Intel Software Guard Extensions (SGX) [54] that would allow smaller tables (space-hardness from hardware) while retaining masking-based DCA resistance; an ML-KEM-1024 implementation, projected at a ≈14 MB Construction-B core (≈26 MB deployment total, unchanged from ML-KEM-768 since Construction A is k-independent) and ≈64× overhead for NIST Level 5 (rescaled to the native-C anchor as in Table 12; scaling_analysis.py); and an ML-DSA extension to digital signatures (FIPS 204) [8], which requires protecting the signing key during the rejection loop, a constant-time hash-to-polynomial, and hiding the rejection count [55]. Within the cache-oblivious direction, whether sublinear oblivious-RAM techniques such as Path ORAM [56] can be adapted to the full-observability white-box model, in which their standard $O\left(\log n\right)$ guarantee does not directly hold, is itself an open question.

In summary, the concrete security estimates are as follows. The first-order DCA trace-complexity estimate is $\approx 2^{13}$ ($1/{\rho }^2$ with ${\rho }_{\max }=0.011$ near the ${10}^4$-trace noise floor—about $1.1\times$ the $0.01$ per-test floor, below the $0.031$ wrong-key maximum). This quantity should be read for what it is: because ${\rho }_{\max }$ lies at the sampling-noise floor ($1/\sqrt{N}=0.01$ for $N={10}^4$), $1/{\rho }^2$ recovers the trace budget N rather than any property of the construction, which is why it agrees with the ≳$2^{13}$-trace non-detection floor—it records how far the experiment reached, not a security level, and Theorem 2 in any case puts the true first-order correlation at zero; the deployment footprint is ≈$2^{24.6}$ bytes (Construction A, $25.57$ MB core) or ≈$2^{23.4}$ bytes (Construction B, $11.08$ MB), which is a size and not a security bound of any kind since the measured budget at which an adversary regenerates the tables and decapsulates fresh ciphertexts at $Z=1.0$ is 1536 bytes for Construction B and zero for Construction A, in neither case growing with the tables, and the secret-bearing material is the ∼KB key together with the output encoding, whose $3.41$ MB of storage carries ≈$1.09$ MB $=2^{20.06}$ bytes of entropy; and timing is structurally constant-time in the protected base multiply (no secret-dependent branches or variable-latency arithmetic), although cache-line constant-time is not claimed. These estimates were computed by concrete_security_bounds.py from the experimental measurements.