RNGGuard: Secure Randomness in ML

• RNGGuard is a security layer that defines and enforces trusted randomness in ML by replacing insecure RNG calls with implementations that meet strict security policies.
• It employs static analysis to identify core random functions and runtime interposition to intercept and secure randomness-dependent processes in frameworks like PyTorch.
• The system integrates statistical auditing and optimized operational modes to detect tampering, mitigate vulnerabilities, and ensure privacy, fairness, and robustness.

RNGGuard is a runtime-enforced security layer for randomness in machine-learning frameworks. It is designed around the claim that randomness in ML is not merely an implementation detail, but a security-relevant substrate that influences data order, augmentation, weight initialization, dropout, randomized smoothing, and differential privacy noise. In the formulation introduced in "One RNG to Rule Them All: How Randomness Becomes an Attack Vector in Machine Learning" (Prabhu et al., 9 Feb 2026), RNGGuard combines static analysis, policy generation, and Python-level interposition to identify core random functions, trace the functions that depend on them, and replace insecure calls with implementations that satisfy security specifications.

1. Conceptual scope and motivation

RNGGuard is motivated by the observation that machine-learning software stacks use heterogeneous randomness layers spanning framework APIs, third-party dependencies, compiler/runtime subsystems, and hardware-specific backends. In this setting, weaknesses in PRNG choice, seed sourcing, distribution transformation, or dependency implementations create a broad attack surface. The work argues that this surface is largely unprotected because ML ecosystems often treat randomness as a reproducibility or convenience issue rather than a security primitive (Prabhu et al., 9 Feb 2026).

The paper maps randomness to multiple stages of the ML pipeline: random train/validation/test partitioning, random minibatch selection or permutation, random crop/flip/color jitter/blur, Xavier/Kaiming initialization, dropout and fractional max-pooling, randomized smoothing, and DP-SGD batch sampling and noise generation. The significance of this mapping is that different uses impose different requirements. Ordinary augmentation or initialization may only require the correct target distribution, whereas DP mechanisms require cryptographically secure randomness and proper seeding. The paper reproduces the standard differential-privacy definition,

$$\text{An algorithm } \mathcal{M} \text{ satisfies } (\epsilon,\delta)\text{-DP if for all neighboring datasets } \mathcal{D},\mathcal{D'}$$

$$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$

to emphasize that the guarantee presupposes a trustworthy randomness source. If DP noise is predictable or reconstructible, the semantic privacy guarantee can collapse even when the accountant remains formally correct (Prabhu et al., 9 Feb 2026).

The paper also treats distribution transformation as part of the security surface. It gives a uniform-sampling transformation from $u \sim \mathcal{U}(0,2^{64})$ to $z \sim \mathcal{U}(a,b)$, an integer-valued uniform transformation $z = u \bmod (b-a) + a$, the Box–Muller transform

$$z_0 = \sqrt{-2\ln(u_0)} \cdot \cos(2\pi u_1), \qquad z_1 = \sqrt{-2\ln(u_0)} \cdot \sin(2\pi u_1),$$

followed by

$x = \sigma z + \mu ,$

and a Laplace-sampling rule

$z = \mu - b \, \mathrm{sgn}(u)\ln(1+|u|).$

These formulas are presented to show that correctness must hold both at the primitive RNG layer and in the higher-level transformations that produce ML-relevant distributions (Prabhu et al., 9 Feb 2026).

A plausible implication is that RNGGuard should be understood less as a single-purpose PRNG replacement and more as an enforcement layer over the semantics of randomness use in ML software.

2. Randomness as an attack surface in machine learning

RNGGuard is grounded in a threat model that divides randomness compromise into two broad classes: existing vulnerabilities and supply-chain attacks. Existing vulnerabilities include system-time seeding, constant or limited-range seeds, user-supplied seeds without safeguards, and non-CSPRNGs used for differential privacy. Supply-chain attacks involve tampering with the framework, a dependency, or a lower-level randomness source (Prabhu et al., 9 Feb 2026).

The paper organizes attack targets into three levels. At the seed-source level, an attacker predicts or manipulates seeds. At the dependency level, a compromised lower-level library can alter or weaken randomness invisibly to the application developer. At the ML-framework level, a malicious implementation can alter higher-level operators such as dropout or initialization while preserving API compatibility. The stated attack objectives include performance degradation, privacy compromise, fairness degradation, integrity compromise or backdoors, and false robustness guarantees (Prabhu et al., 9 Feb 2026).

The most concrete example concerns differential privacy in TensorFlow Federated via TF Privacy. There, central DP aggregation uses system-time-derived seeds incremented each round. The paper quantifies one scenario in which, at $1\,\mu s$ precision within a $10\,s$ time window, the entropy is only about 23 bits. The intended consequence is that an attacker can brute-force the seed space offline, reconstruct the DP noise, and remove it from updates. This example is important because it shows that RNG attacks need not target model weights or training data directly; compromising seed entropy can be sufficient (Prabhu et al., 9 Feb 2026).

Other attack vectors discussed include data-ordering attacks that manipulate SGD and fairness, dropout attacks that exclude classes or bias learning, adversarial initialization that degrades convergence or accuracy, augmentation backdoors that preserve overall accuracy while misclassifying attacker-chosen inputs, randomized-smoothing attacks that inflate robustness certificates, and DP-noise attacks that enable denoising and data reconstruction. The paper’s broader claim is that randomness manipulation is especially dangerous because it is covert: unlike overt poisoning or malicious serialization, it can silently alter behavior while leaving most of the pipeline unchanged (Prabhu et al., 9 Feb 2026).

This framing places RNGGuard in a distinct category from source-oriented RNG research. Hardware and physical-source papers focus on whether an entropy source is genuinely unpredictable or statistically sound, such as parity-symmetric radioactive RNGs with composable security proofs (Tsurumaru et al., 2019), chaos-based analog entropy sources that remain incomplete without extraction and monitoring (Abzhanova et al., 2018), or adaptive variation-resilient embedded TRNGs that track threshold drift (Zahoor et al., 7 Jul 2025). RNGGuard instead assumes that ML systems often fail before any such source-level question arises, because the software stack already exposes manipulable or insecure randomness paths.

3. Architecture, static analysis, and runtime interposition

RNGGuard has two phases: policy generation via static analysis, and runtime secure enforcement via function replacement or interposition. The static component uses CodeQL to analyze the target framework’s source code. The first step is to identify core random functions using the authors’ ecosystem study, prior framework knowledge, and name-based heuristics. For PyTorch, the paper identifies torch.rand, torch.randint, torch.randperm, torch.normal, torch.randn, and the in-place variants torch.Tensor.normal_ and torch.Tensor.uniform_ as core primitives (Prabhu et al., 9 Feb 2026).

Once these roots are identified, RNGGuard uses CodeQL transitive analysis to compute all functions that directly or indirectly depend on them. This design choice is central: the system is not limited to hand-patching a small number of public APIs, but instead aims to recover the dependency closure of randomness-consuming functions. That closure is then associated with policy metadata describing expected output distributions, required parameter ranges, seeding rules, and whether a regular PRNG is acceptable or a CSPRNG is required (Prabhu et al., 9 Feb 2026).

At runtime, RNGGuard relies on Python’s module caching semantics. If it is imported before the target framework, it can replace functions in the loaded module objects before application code uses them. The paper emphasizes that this avoids source modification, avoids a custom framework rebuild, and permits drop-in instrumentation of existing applications. The practical deployment model is therefore: import RNGGuard first, let it modify cached module objects, and allow subsequent imports to see the wrapped or replaced versions (Prabhu et al., 9 Feb 2026).

This interposition model is deliberately scoped to the framework boundary. A useful contribution of the paper is its explicit distinction between framework-level, dependency-level, and hardware/backend-level randomness. Framework examples include PyTorch CPU with MT19937, PyTorch GPU with Philox, TensorFlow with Philox by default and ThreeFry via XLA, and JAX with ThreeFry or Philox and user-supplied seeds. Dependency examples include TensorFlow’s reliance on TSL and XLA, Keras or TF.Keras use of Python random, scikit-learn’s reliance on NumPy, and DP libraries inheriting framework PRNGs. Hardware/backend distinctions include PyTorch using different PRNGs on CPU and GPU, and the notable exception that 32-bit Windows uses system time for seeding in PyTorch (Prabhu et al., 9 Feb 2026).

A plausible implication is that RNGGuard’s strongest leverage lies at the Python-exposed framework interface, where lower-level choices surface as callable APIs, even if binary-level compromise remains out of scope.

4. Operating modes and enforced security specifications

RNGGuard supports two runtime modes: static mode and dynamic mode. Static mode enforces the policies derived from the ecosystem study and static analysis. For PyTorch, this means that if no generator is provided to a random call, RNGGuard injects one seeded from /dev/urandom; for DP-related operations, it replaces standard PRNGs with a CSPRNG; and it enforces secure noise generation in Opacus via the API. This mode is described as policy-driven and relatively lightweight (Prabhu et al., 9 Feb 2026).

Dynamic mode adds runtime statistical auditing. It uses the Kolmogorov–Smirnov test for continuous distributions and Pearson’s $$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$0 test for discrete distributions. The paper also reproduces the $$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$1-test statistic,

$$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$2

the KS statistic,

$$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$3

and the Pearson statistic,

$$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$4

In dynamic mode, RNGGuard uses a sample size of 100 for both tests, maps continuous observations to $$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$5 or $$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$6, and raises a warning if deviation is detected with $$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$7. The paper also notes validity constraints: Pearson $$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$8 requires at least 5 observations per bin and a minimum sample size of 13, while the SciPy KS implementation requires a minimum sample size of 20 (Prabhu et al., 9 Feb 2026).

From the design and examples, the effective policy set includes secure seed sourcing, CSPRNG use in privacy-sensitive contexts, distribution correctness, primitive-function correctness, and runtime detection of tampering. The system’s intended guarantees are explicitly practical rather than fully formal. RNGGuard does not claim to prove full cryptographic security of every ML randomness use. Instead, it aims to enforce practical policies with low engineering effort and to restore secure behavior when a higher-level function no longer depends on the correct primitive or no longer emits the expected distribution (Prabhu et al., 9 Feb 2026).

The paper demonstrates this soundness claim with an attack that replaces torch.nn.init.kaiming_normal_ so that it returns uniformly distributed weights instead of Kaiming-normal ones. RNGGuard detects the attack because the malicious function no longer follows the expected primitive RNG path, and in dynamic mode it fails the KS test for normality. After enforcement, the initialization again passes the normal distribution test (Prabhu et al., 9 Feb 2026).

This suggests a useful distinction between RNGGuard and standard DP auditors. The paper evaluates DeltaSiege and argues that such auditors can detect privacy violations empirically but do not inspect whether noise came from a CSPRNG or from a predictable PRNG. RNGGuard therefore operates one layer lower: it audits and enforces the randomness source itself.

5. Prototype implementation and empirical evaluation

The prototype implementation targets the PyTorch ecosystem, including Opacus, and is evaluated in an environment with Python 3.12, PyTorch 2.8, CUDA 12.6, Opacus 1.5.4, manually built torchcsprng 0.3.a, and an NVIDIA A30 GPU. The DP training setup uses ResNet20 on CIFAR10 with clipping norm 1.2 and target privacy budget

$$\text{and all measurable } \mathcal{S}, \quad P(\mathcal{M}(\mathcal{D}) \in \mathcal{S}) \le e^\epsilon P(\mathcal{M}(\mathcal{D'}) \in \mathcal{S}) + \delta ,$$9

Statistical tests use SciPy implementations (Prabhu et al., 9 Feb 2026).

The first evaluation studies whether DeltaSiege can distinguish secure and insecure randomness in Opacus Gaussian noise. Across six $u \sim \mathcal{U}(0,2^{64})$0 settings and ten runs per setting, the number of violations remains roughly similar regardless of whether a CSPRNG is used. For example, at $u \sim \mathcal{U}(0,2^{64})$1 the reported counts are 3, 1, 9, and 10 for CSPRNG with floating-point mitigation, non-CSPRNG with mitigation, CSPRNG without mitigation, and non-CSPRNG without mitigation, respectively. The interpretation given is that existing DP auditors do not meaningfully diagnose the RNG-security issue (Prabhu et al., 9 Feb 2026).

Microbenchmark results average over 1000 calls on CPU and measure generation and testing of 1000 samples. Baseline versus static versus dynamic latency per call is reported as follows: rand 0.015/0.022/1.266 ms, randn 0.016/0.024/1.581 ms, randint 0.025/0.032/1.014 ms, randperm 0.010/0.017/0.506 ms, normal 0.016/0.025/1.455 ms, Tensor.uniform_ 0.008/0.016/0.864 ms, and Tensor.normal_ 0.008/0.017/1.000 ms. Static-mode overhead is reported as 46–112%, primarily due to creating and injecting generators, while dynamic mode costs about 0.5–1.6 ms per call because every generated sample sequence is statistically tested (Prabhu et al., 9 Feb 2026).

The end-to-end training results distinguish non-DP and DP workloads. For non-DP training, one epoch takes 15 s in the baseline, 22 s in static mode, and 132 s in dynamic mode, corresponding to about 47% overhead for static mode. Data batching dominates runtime in all three cases, reaching up to 98%. For DP training, static mode incurs 16.5% overhead, while dynamic mode incurs 650% overhead. In the static DP case, data batching takes 80% of training time and DP-SGD up to 19%; in the dynamic case, data batching takes 70% and DP-SGD 29% (Prabhu et al., 9 Feb 2026).

Because dynamic mode is expensive, the paper proposes two optimizations. In the unoptimized setting, a CPU auditor thread tests random values copied from GPU once enough samples accumulate; DP one-epoch runtime is 571 s, with 163 s in data shuffling and 390 s in DP-SGD. In ASN mode, the main process continues training while the auditor tests in parallel, reducing runtime to 374 s, with 107 s in data shuffling and 254 s in DP-SGD. In RASN mode, only every tenth random sequence is audited, reducing runtime further to 108 s, with 43 s in data shuffling and 48 s in DP-SGD (Prabhu et al., 9 Feb 2026).

The soundness demonstration using the attacked Kaiming initializer also includes a functional-correctness check over 25 epochs of training. The original initialization yields 21.09% accuracy, and the secured initialization yields 21.37% accuracy. The paper’s point is not absolute accuracy, but that RNGGuard restores intended probabilistic semantics without degrading the function’s expected role in training (Prabhu et al., 9 Feb 2026).

The methodology is also said to generalize beyond the evaluated prototype. The ecosystem study covers PyTorch, TensorFlow, JAX, Keras, TF.Keras, NumPy, scikit-learn, Opacus, TensorFlow Privacy, Diffprivlib, JAX Privacy, FedML-AI, and TensorFlow Federated, though the implemented evaluation focuses on PyTorch, Opacus, and one discussion-level integration with FedML-AI (Prabhu et al., 9 Feb 2026).

6. Position within randomness-security research, limitations, and significance

RNGGuard occupies a software-framework layer that is orthogonal to most hardware or physical-source RNG research. Studies of parity-symmetric radiations derive secrecy from physically checkable invariants and universal hashing (Tsurumaru et al., 2019). Work on memristive chaos sources explores whether analog chaotic behavior can serve as an entropy source but does not provide extraction or online health testing (Abzhanova et al., 2018). Adaptive embedded TRNGs based on stochastic MTJs use moving analog thresholds to suppress variation-induced bias (Zahoor et al., 7 Jul 2025). Hardware-rooted randomness for generative AI replaces deterministic software randomness with STT-MTJ true randomness and shows reductions in insecure outputs under an LPIPS-based metric (Bao et al., 2 Oct 2025). RNGGuard differs from all of these by treating the principal security problem as one of insecure software use, seed handling, dependency composition, and distributional transformation in ML pipelines rather than of source physics itself (Prabhu et al., 9 Feb 2026).

The paper is explicit about its limitations. Manual identification of core RNG functions is not yet fully automated. Dynamic mode is expensive even after ASN and RASN. The prototype focuses on PyTorch. Static analysis assumes source availability, although dynamic auditing helps when source is limited. Statistical tests are not a full security proof, since an insecure or malicious PRNG can pass some tests. Python-level enforcement is strongest for Python-exposed framework functions and weaker against lower-level binary or runtime compromise. The need to manually build torchcsprng 0.3.a is presented as evidence of ecosystem friction (Prabhu et al., 9 Feb 2026).

These limitations matter because RNGGuard deliberately aims for practical security policies rather than universal formal guarantees. A plausible implication is that the system should be read as a framework-hardening mechanism, not as a complete cryptographic certification layer. It secures seed sourcing, enforces CSPRNG use where policy demands it, checks distributional behavior, and can detect or repair certain classes of tampering. It does not, by itself, solve adversarial compromise below the framework boundary, nor does it replace the need for trustworthy entropy sources when the framework genuinely requires them.

Within the ML security literature, the significance of RNGGuard lies in the shift of emphasis from model behavior to randomness infrastructure. The paper’s bottom-line synthesis is that machine-learning randomness has consequences for performance, fairness, privacy, robustness, and integrity, and that these consequences can be exploited covertly if randomness is weakly seeded, insecurely transformed, or silently altered in dependencies or framework code. RNGGuard’s contribution is to make that layer explicit, analyzable, and enforceable at runtime (Prabhu et al., 9 Feb 2026).