Dudect: Statistical Timing Leakage Detector

• Dudect is a statistical timing-leakage detector that empirically tests if runtime correlates with secret-derived inputs using repeated cycle measurements and Welch’s t-tests.
• It integrates into an automated toolchain alongside binary-level constant-time analyzers to evaluate cryptographic implementations on real hardware.
• While effective at detecting timing dependencies, dudect does not localize leak sources and relies on careful measurement setups and input class selection.

Searching arXiv for Dudect and closely related timing-leakage analysis papers. Dudect is a statistical timing-leakage detector used to test whether a program’s runtime correlates with secret-derived input classes on real hardware. In the evaluation of NIST PQDSS candidates, it appears as one of two statistical tools in an automated analysis pipeline, alongside RTLF, and complements the binary-level constant-time policy analyzers TIMECOP and Binsec/Rel2. In that setting, dudect is not treated as a formal verifier of constant-time compliance; rather, it provides an empirical “does runtime correlate with secret-derived classes?” test based on repeated cycle measurements and Welch’s t-tests (Adjonyo et al., 4 Sep 2025).

1. Analytical role and conceptual scope

Within the reported toolchain, dudect occupies the statistical end of constant-time analysis. The pipeline assigns distinct roles to four tools:

Tool	Role
TIMECOP	Dynamic taint-style constant-time policy checking at the binary level
Binsec/Rel2	Symbolic binary-level relational checking for constant-time policy violations
dudect	Statistical timing leakage detection on actual hardware
RTLF	Statistical checker used alongside dudect to cross-validate timing behavior with a different hypothesis-testing approach

This division of labor is central to how dudect is interpreted. Binary tools attempt to identify secret-dependent branches or memory accesses that violate a constant-time policy, whereas dudect asks whether execution time actually differs across chosen input classes on the tested platform (Adjonyo et al., 4 Sep 2025).

The distinction is methodologically consequential. A positive dudect result indicates that the binary exhibits measurable timing dependence, but it does not localize the source of the leak, identify a source line, or prove that a specific branch or memory access caused the observed effect. The paper therefore treats dudect as an empirical detector rather than a proof-producing analysis. It is explicitly described as “neither sound nor complete,” and its findings may reflect hardware-induced timing variation as well as software-level defects (Adjonyo et al., 4 Sep 2025).

2. Statistical method and test construction

Dudect is described as measuring the number of CPU cycles taken by repeated executions of the target program and then applying a sequence of Welch’s t-tests to the collected measurements. The null hypothesis is that runtime is independent of which of two input classes is used. This places dudect in a class of tools that do not require the user, or the tool, to carefully model the potential sources of leakage; instead, they compare timing distributions across classes (Adjonyo et al., 4 Sep 2025).

The test design used for PQDSS implementations is concrete. For each scheme, the evaluators measured random private keys, expanded them into the scheme’s mathematical representation, and partitioned them into two classes based on a selected bit of that expanded key. They chose bits “at the beginning,” “in the middle,” and “at the end” of the key in order to obtain roughly balanced groups, while noting that such balancing was not always possible because of the keys’ mathematical structure. This suggests that the efficacy of dudect depends materially on the class-construction strategy, not merely on the timing engine itself (Adjonyo et al., 4 Sep 2025).

The measurements for dudect and RTLF were collected in a one-shot manner, with the statistics computed afterward. The default budget was 210k samples per run so that, for balanced classes, about 100k samples per class would be available. To reduce noise, the experiments were conducted on bare-metal hardware rather than in Docker, with processes pinned to specific CPU cores via taskset and cores reserved through GRUB configuration. The workflow also notes an asymmetry between the two statistical tools: RTLF was configured with a false positive rate of 9% ($\alpha = 0.09$), whereas dudect is presented as not offering a tunable false-positive-rate parameter in that workflow (Adjonyo et al., 4 Sep 2025).

Because the method depends on timing distributions over chosen classes, dudect’s conclusions are inherently statistical rather than formal. A plausible implication is that failure to observe a significant effect under one class partition does not exclude timing dependence under another partition or under other internal intermediates.

3. Integration into the automated PQDSS toolchain

The paper embeds dudect in a Python-driven toolchain designed to automate configuration, execution, and result analysis across many NIST PQDSS implementations. For every candidate and tool, the driver generated the needed harness and config files, compiled the target, and ran the analysis. This automation was introduced because each tool has distinct expectations regarding build configuration, instrumentation, and target API (Adjonyo et al., 4 Sep 2025).

For dudect specifically, the integration follows the same API-centric harness used by the other tools and focuses exclusively on the NIST-required crypto_sign() entry point from api.h. Across all tools, the private key is treated as the only secret input and everything else as public. Unlike TIMECOP and Binsec/Rel2, dudect does not require tainting or symbolic annotations; the harness instead supplies inputs from the two chosen classes and records execution times (Adjonyo et al., 4 Sep 2025).

The coupling between dudect and RTLF is also operational rather than merely conceptual. In the described setup, both statistical tools use the same measurement data, and RTLF can export measurement results that were gathered for dudect. This emphasizes that dudect is used as part of a reusable measurement infrastructure rather than as an isolated stand-alone check (Adjonyo et al., 4 Sep 2025).

The resulting workflow gives dudect a pragmatic place in large-scale assessment. Its black-box nature makes it broadly applicable to many implementations, but its usefulness depends on a carefully engineered surrounding harness and measurement environment.

4. Evaluation over NIST PQDSS candidates

The automated evaluation covered 302 instances of 15 primitives from NIST PQDSS round 1 and round 2 and was applied to the optimized implementations submitted to the NIST process. In the results matrix, dudect appears as one of the columns used to mark whether a given instance produced a statistically significant timing dependency. The matrix spans round-1 schemes such as SNOVA and Preon and round-2 schemes such as LESS, Mirath, MQOM, PERK, RYDE, SQIsign, MAYO, SDitH, QR-UOV, UOV, and FAEST (Adjonyo et al., 4 Sep 2025).

Because dudect is a whole-program statistical tool, its outputs are interpreted at the instance level. An alert indicates that runtime differs across the selected input classes, but it does not specify where the leak occurs. Accordingly, the results are recorded at instance granularity rather than source-location granularity. This differs from the binary-level tools, which can often provide precise locations for secret-dependent branches or memory accesses (Adjonyo et al., 4 Sep 2025).

The broader study reported 26 issues to developers, with 5 already fixed. The paper does not attribute those confirmations to dudect alone. Instead, exploitability judgments are said to come from manual review and developer feedback. Dudect’s contribution is to indicate whether a suspected issue manifests as a measurable timing signal on actual hardware (Adjonyo et al., 4 Sep 2025).

5. Interpretation of findings and relation to exploitability

The paper repeatedly characterizes dudect and RTLF as complements to, rather than replacements for, binary policy checkers. Binary tools can often localize policy violations, but dudect reveals whether those or other effects translate into observable timing differences on the test platform. This is particularly relevant when symbolic or dynamic tools either flag a policy violation later judged non-exploitable or fail to reach a relevant path because of scalability limits (Adjonyo et al., 4 Sep 2025).

Several confirmed issues involved classic timing or cache side-channel patterns, including secret-derived indexing in SNOVA, an AES S-box table lookup keyed by secret-dependent data in Preon, secret-dependent permutation access in LESS, and secret-dependent table access in finite-field matrix multiplication in Mirath. In these cases, the paper presents binary policy tools as especially well suited to localization, while dudect’s role is to determine whether the implementation’s measured runtime behavior is distinguishable on hardware (Adjonyo et al., 4 Sep 2025).

A substantial nuance concerns rejection sampling. The authors state that many interesting false positives for policy tools came from rejection-sampling patterns, where execution time depends on secret-derived values but the discarded values do not themselves create a practical attack surface. In LESS and QR-UOV, the resulting timing differences are reported as true constant-time violations under a strict policy, but not necessarily as practical vulnerabilities. Dudect remains relevant in such cases because it may still report measurable timing dependence even when the leaked information is judged useless to an attacker (Adjonyo et al., 4 Sep 2025).

The paper also notes that coarse secret modeling can generate irrelevant warnings in the binary tools, since the whole secret-key buffer is often treated as secret even if some portions are public or derived metadata. Dudect avoids that specific modeling burden, but it introduces a different interpretive problem: it can detect timing variation caused by the underlying hardware architecture or environmental effects rather than by code-level constant-time violations (Adjonyo et al., 4 Sep 2025).

6. Strengths, limitations, and recommended workflow position

The reported strengths of dudect are practical. It is simple in concept, requires no formalization of a constant-time policy, and does not require secret-flow annotations. Because it operates on real hardware, it can validate that a suspicious implementation exhibits measurable timing differences in practice. The paper explicitly describes it as useful as a “last line of defense” after policy-based tools, particularly because it can expose leakage sources beyond the precise secret-dependent branches and memory accesses targeted by symbolic and dynamic checkers (Adjonyo et al., 4 Sep 2025).

Its limitations are equally explicit. Dudect cannot localize the source of a leak. Its results depend heavily on the choice of input classes, and the generic strategy of selecting bits from the expanded private key may miss leaks correlated with other bits or with internal intermediates. The paper also identifies a multiple-testing problem if too many bits are tested and notes that standard corrections such as Bonferroni would make the test conservative. Because the measurements are performed on actual hardware, dudect can report timing variation arising from microarchitectural or environmental effects. Finally, for asymmetric black-box schemes, classical TVLA-style approaches comparing a fixed secret and random secret are said not to be straightforward, because public-key-dependent behavior and rejection sampling can create false positives (Adjonyo et al., 4 Sep 2025).

The practical lesson drawn from the evaluation is that statistical timing tools are valuable only when the measurement harness is carefully controlled. The need for bare-metal execution, core pinning, and a large number of measurements shows that dudect is sensitive to noise and setup quality. Even so, the study concludes that dudect is practical and worthwhile because it helps determine whether a suspected constant-time issue has a real timing footprint on deployed hardware (Adjonyo et al., 4 Sep 2025).

The recommended workflow is staged. First, use symbolic or dynamic policy tools to localize suspicious code. Second, use dudect and RTLF to verify whether the implementation exhibits measurable timing behavior on actual hardware. Third, manually inspect and disclose confirmed issues. The authors specifically recommend using Binsec/Rel2 first where possible because it is more precise, then relying on TIMECOP and the statistical tools on code regions not fully explored or too difficult for the symbolic engine (Adjonyo et al., 4 Sep 2025).

7. Terminological ambiguity: dudect and DUDE

The name “dudect” can be confused with “DUDE,” but the two refer to different systems. The paper “Don’t Click That: Teaching Web Agents to Resist Deceptive Interfaces” introduces DUDE, short for Deceptive UI Detector & Evaluator, a two-stage defense for vision-language-model web agents against deceptive interface elements such as fake download buttons, misleading pop-ups, camouflaged ads, and other dark patterns (Zhang et al., 10 May 2026).

That framework formalizes deception-aware web agent defense as a click-evaluation problem, defines an evaluator $\mathcal{E}:(I,P,C)\mapsto(\hat{L},\gamma)$, uses hybrid-reward learning and experience summarization, and is evaluated on the RUC benchmark of 1,407 scenarios. It is not a cryptographic timing-analysis tool and is explicitly distinguished from the “dudect”-style statistical detector used in the PQDSS timing-leakage study (Zhang et al., 10 May 2026).

In the cryptographic context, therefore, dudect denotes a statistical timing-leakage detector whose value lies in empirical confirmation of measurable timing dependence on real hardware, especially when used in conjunction with binary-level constant-time analysis rather than as a substitute for it (Adjonyo et al., 4 Sep 2025).