Binsec/Rel2: Binary Constant-Time Checker

• Binsec/Rel2 is a binary-level constant-time policy checker that uses relational symbolic execution to verify cryptographic code against timing leaks.
• It compares pairs of executions to ensure that secret-dependent behaviors, such as branching and memory accesses, do not lead to observable differences.
• The tool achieves high precision with a 0% false positive rate against dynamic taint approaches, though its bounded analysis faces scalability challenges.

Binsec/Rel2 is a binary-level constant-time policy checker used for systematic timing-leakage analysis of compiled cryptographic code. In the evaluation of NIST PQDSS round 1 and round 2 implementations, it is one of the two tools selected for binary-level constant-time policy checking, alongside TIMECOP, while dudect and RTLF are used instead as statistical timing-leak detectors on real hardware (Adjonyo et al., 4 Sep 2025). Within that toolchain, Binsec/Rel2 occupies the high-precision, relational symbolic-analysis role: it is used to provide precise, actionable confirmations of constant-time violations at the compiled binary level, motivated by the observation that constant-time properties can be broken during compilation and therefore must be checked on the final binary (Adjonyo et al., 4 Sep 2025).

1. Position in binary constant-time verification

In the PQDSS analysis workflow, the tools are divided into two functional classes. The first class comprises constant-time policy checkers at binary level, namely TIMECOP and Binsec/Rel2. The second class comprises statistical timing-leak detectors on real hardware, namely dudect and RTLF (Adjonyo et al., 4 Sep 2025). Binsec/Rel2 therefore is not used to measure runtime statistically and not used as a real hardware oracle; its purpose is to verify whether a binary respects a specified constant-time policy.

The selection rationale reported for Binsec/Rel2 is popularity, successful prior application, and development status. More specifically, it is described as a symbolic analysis tool at the binary level that performs relational symbolic execution and can detect constant-time violations more precisely than dynamic taint tools, generate a witness of violation, and, when no violation is found within bounds, provide a bounded proof of correctness (Adjonyo et al., 4 Sep 2025). This places it between lightweight dynamic tracing and more proof-oriented verification: more precise than dynamic tracing, but bounded and less scalable than lightweight dynamic tools.

A plausible implication is that Binsec/Rel2 should be understood less as a timing-measurement instrument than as a verifier for a relational security policy over compiled code. That characterization aligns with the earlier Binsec/Rel line, which formalized binary-level constant-time verification as relational symbolic execution over pairs of executions and emphasized both bug-finding and bounded verification at the binary level (Daniel et al., 2019).

2. Security property and leakage model

The background policy checked in the PQDSS study is the usual constant-time policy: no secret-dependent branching conditions and no secret-dependent memory accesses, with the goal of preventing path-timing differences and cache-based leakage (Adjonyo et al., 4 Sep 2025). For Binsec/Rel2, the authors additionally enabled alerts for secret-dependent operands of multiplication and division instructions because of recent attacks such as KyberSlash and the relevance of variable-time arithmetic instructions.

Accordingly, the property Binsec/Rel2 is intended to verify is a binary-level relational non-interference style property for constant-time observables: two executions of the same binary that differ only in secret inputs should not differ in observables such as control-flow decisions, memory-access patterns, and selected arithmetic operations of concern (Adjonyo et al., 4 Sep 2025). The paper does not give a formal LaTeX semantics for Binsec/Rel2 itself, nor does it reproduce relational formulas from the Binsec/Rel2 literature. The policy specification is given in prose rather than in symbolic proof rules.

This suggests continuity with the leakage model formalized for Binsec/Rel, where constant-time is defined by equality of leakage traces across low-equivalent executions, with loads and stores leaking memory access indices or addresses and conditionals or dynamic jumps leaking control-flow observations (Daniel et al., 2019). However, the PQDSS study itself frames Binsec/Rel2’s checked property operationally, in terms of branches, memory accesses, and flagged multiplication and division operands, rather than through a reproduced semantics.

A common misconception is to treat such a tool as an end-to-end timing oracle. The study is explicit that Binsec/Rel2 checks a policy, not end-to-end real-time behavior on hardware: it does not directly measure execution time, and thus may miss leaks due to hardware effects outside its modeled observables, such as frequency scaling or microarchitectural timing effects not reducible to branch, address, or multiplication and division observables in the model (Adjonyo et al., 4 Sep 2025).

3. Operational workflow in the PQDSS campaign

The automated toolchain generates configuration files and test harnesses, compiles the binary with tool-specific flags, and runs the tool for each candidate and tool combination (Adjonyo et al., 4 Sep 2025). The analysis targets the compiled implementation of crypto_sign(). For all tests, the private key is treated as the only secret, and all other inputs are treated as public. Because Binsec/Rel2 depends on explicit secret/public modeling, this partition is a central input to the analysis.

The setup burden is described as difficult. Initializing Binsec/Rel2’s symbolic engine is said to be notoriously tedious because the initial state must include consistent values for pointers, code addresses, dynamically linked libraries, and related process state (Adjonyo et al., 4 Sep 2025). The practical solution adopted in the study is to run the generated harness under GDB up to the call to crypto_sign(), dump the process state, and use that core dump as the concrete initial state for symbolic analysis. The dumped state is then modified so that public buffer contents are overwritten with symbolic/public variables and secret buffer contents are overwritten with symbolic/secret variables.

The paper also reports a deliberately narrowed bug-finding setup. Although public and secret buffer variables are overwritten with symbolic variables of the corresponding taint in the general method, the practical configuration removes nondeterminism from public data by keeping public data concrete and limits the private taint to a single byte of the key (Adjonyo et al., 4 Sep 2025). This improves tractability but weakens completeness. The authors explicitly present this as a bug-finding targeted setup rather than a full proof setup over all secrets and publics.

The same section identifies additional assumptions introduced for tractability. Allocation functions were stubbed, and AES instructions were stubbed (Adjonyo et al., 4 Sep 2025). The paper explicitly warns that absence of reported violations does not imply absence of constant-time violations under this setup. A plausible implication is that the PQDSS campaign used Binsec/Rel2 primarily as a high-confidence violation confirmer within a larger multi-tool workflow rather than as a standalone completeness argument.

4. Relational symbolic execution and bounded reasoning

The study states that Binsec/Rel2 performs relational symbolic execution (Adjonyo et al., 4 Sep 2025). Even though the paper does not explain its internals in depth, the intended operational meaning is clear: the tool reasons about two executions of the binary under different secret values and checks whether secret differences can induce different observations under the constant-time leakage model. When a violation is found, a witness is generated; otherwise the program is proved correct up to a given instruction-count bound.

SMT reasoning is central to this precision. The study states that Binsec/Rel2 may require SMT queries to decide path feasibility and whether a branch or memory access actually depends on secret data (Adjonyo et al., 4 Sep 2025). This is presented as the main reason it is more precise than TIMECOP: TIMECOP taints values along one concrete execution, whereas Binsec/Rel2 reasons about constraints and can avoid false positives when secret-tainted values are actually constrained to a single observable outcome.

This account closely matches the foundational Binsec/Rel methodology, which represents paired executions relationally, treats constant-time as a 2-hypersafety property over synchronized same-path executions, and reduces leakage checks to disequality queries under the current path predicate (Daniel et al., 2019). The predecessor work also formalized the dual role of such an engine: if a satisfiable insecurity query is found, it corresponds to a real counterexample; if exhaustive symbolic exploration within bounds completes without such a query, it yields bounded verification.

In the PQDSS study, however, path exploration is a dominant practical limitation. For all tested instances, exploration was not completed, and the analysis ended either by timeout or memory exhaustion (Adjonyo et al., 4 Sep 2025). Timeouts commonly occurred while waiting for SMT solver answers, and memory exhaustion was attributed to formula representation and simplification strategies that did not handle some patterns well, especially matrix-heavy code such as SNOVA. In that campaign, Binsec/Rel2 therefore functioned mostly as partial bug-finding with high precision, not as a source of complete proofs over the whole code base.

5. Precision, coverage, and comparison with TIMECOP

The most important comparative result in the study is Binsec/Rel2’s precision relative to TIMECOP. On a manually checked subset, the false positive rate of Binsec/Rel2 alerts is reported as 0%, whereas TIMECOP’s false positive rate is 67.1% (Adjonyo et al., 4 Sep 2025). This is the empirical basis for the tool’s role as the high-confidence binary verifier in the pipeline.

The study also reports strong differences in alert volume. TIMECOP produced 10247 unique binary alerts across 191 source locations, whereas Binsec/Rel2 produced 598 unique binary alerts across 25 source locations; when multiplication alerts are excluded, Binsec/Rel2 produced 267 binary alerts across 13 source locations (Adjonyo et al., 4 Sep 2025). The paper notes that TIMECOP reports about 17 times more alerts than Binsec/Rel2, but stresses that this should not be read as proportionally more real issues because much of the excess is noise.

The explanation offered is methodological. TIMECOP uses dynamic taint tracking on one concrete execution trace using Valgrind; it marks secret data as uninitialized and reports branches or memory accesses influenced by tainted data. Binsec/Rel2 instead performs symbolic relational binary analysis using SMT reasoning (Adjonyo et al., 4 Sep 2025). Because it reasons about feasibility and equality under constraints, it can discharge cases where a value is secret-derived but the actual branch or memory outcome is invariant. The study gives Ryde examples in which TIMECOP flags secret dependence syntactically, while Binsec/Rel2 proves that the branch condition or derived quantity cannot vary observably.

Coverage and scalability, however, cut in the opposite direction. TIMECOP reaches more code because it executes one trace to completion, whereas Binsec/Rel2 often stops early due to SMT or memory limits (Adjonyo et al., 4 Sep 2025). The paper explicitly says that TIMECOP found additional true positives only in parts of code unreached by Binsec/Rel2. The practical trade-off is therefore precision against reach: Binsec/Rel2 yields far fewer, higher-confidence alerts, but its bounded symbolic exploration often terminates before whole-function coverage is achieved.

6. Assumptions, blind spots, and relation to adjacent approaches

Several limitations in the PQDSS use of Binsec/Rel2 arise directly from the chosen configuration. Because secret taint was limited to one byte of the key, public data were concretized, stubs were used, and exploration ended by timeout or memory exhaustion, absence of alerts is not evidence of global constant-timeness (Adjonyo et al., 4 Sep 2025). The tool can also miss violations that depend on multiple secret bytes jointly, specific public-triggered paths, broader combinations of symbolic inputs, unreached code, or late-program behaviors.

The secret/public partition is itself a source of interpretation difficulty. The study notes that many secret-key structures mix truly secret and public fields, such as public seeds or public key hashes packed into the secret key (Adjonyo et al., 4 Sep 2025). A tool that treats the whole secret-key buffer as uniformly secret can therefore report violations that are not meaningful under a more refined policy. Similarly, the toolchain does not automatically understand semantic declassification inside analyzed functions, so values developers regard as already effectively public may still be treated as sensitive.

The paper also remarks that some reported branches arise from rejection-sampling patterns that formally violate the constant-time policy but may be considered non-exploitable because they only reveal discarded randomness or hash outputs with no practical attack value (Adjonyo et al., 4 Sep 2025). This does not negate the correctness of the alert with respect to the targeted policy; it clarifies that policy violation and exploitable leakage are not identical categories.

In the broader design space of binary constant-time analysis, DALC-CT offers a complementary point of comparison. It is a dynamic binary instrumentation approach that compares instruction-mix vectors across concrete executions and treats any mismatch as evidence of secret-dependent execution variation, but it checks only sampled inputs and abstracts traces to class-count vectors (Njungle et al., 18 Apr 2026). Relative to that approach, Binsec/Rel2 remains the symbolic, relational, proof-oriented end of the spectrum. A plausible implication is that mixed workflows pairing relational verification with dynamic falsification are structurally well motivated: the PQDSS study already combines Binsec/Rel2 with both a dynamic policy checker and hardware-level statistical detectors for precisely this reason (Adjonyo et al., 4 Sep 2025).