Instrumented Detection of Low-Amplitude ECDSA Timing Leakage in CVE-2024-13176

2.1 ECDSA and Nonce Sensitivity

ECDSA is a public-key digital signature algorithm used to authenticate data and verify that it was signed by the holder of the corresponding private key. The algorithm is standardized as part of the NIST Digital Signature Standard [6] and is commonly used in cryptographic libraries, protocols, certificates, and authentication systems. At a high level, ECDSA signing uses a long-term private key together with a per-message secret value, often referred to as a nonce or per-message secret number. The resulting signature can then be verified using the signer’s public key.

The nonce is a critical part of ECDSA security. If the same nonce is reused across signatures, or if enough information about the nonce is leaked, the long-term private key may be recoverable. Even partial leakage from repeated signing operations can become security-relevant because an attacker may be able to combine information across many signatures [3].

ECDSA nonces may be generated randomly or deterministically, depending on the implementation. RFC 6979 defines a deterministic method for generating DSA and ECDSA nonces from the private key and message, reducing the risk of failures caused by poor randomness [7]. Deterministic nonce generation still requires side-channel resistance, since later computations during signing may leak information through timing, memory access patterns, cache behavior, or other implementation-level effects.

2.2 Timing Side Channels

A timing side channel occurs when the time required to complete an operation depends on secret data. In cryptographic code, this can happen when branches, loops, arithmetic operations, memory accesses, or error-handling paths vary based on private values. The security issue is not simply that one operation is faster than another, but that the timing difference may be statistically correlated with information an attacker should not know.

In practice, timing measurements are affected by many sources of noise. Operating system scheduling, CPU frequency scaling, cache state, branch prediction, background processes, virtualization, and network jitter can all hide or distort a timing signal. For that reason, timing leakage is often evaluated statistically rather than through individual observations. A single timing measurement may reveal little, while a large set of measurements may show a distributional difference between two classes of operations.

2.3 Constant-Time Implementations and Leakage Detection

A common defense against timing side channels is to write cryptographic code in a constant-time style. In this context, “constant-time” does not mean that every operation always takes exactly the same number of nanoseconds. Instead, it means that the control flow, memory access pattern, and operation sequence should not depend on secret data in a way that creates observable leakage. This is difficult to guarantee in real systems because compiler optimizations, platform behavior, and microarchitectural effects can introduce timing differences even when the source code is written carefully.

Because constant-time behavior is difficult to prove from source code alone, practical testing tools often use statistical methods to detect timing leakage. Tools such as dudect compare timing measurements from different input classes and use statistical tests to determine whether the resulting distributions are distinguishable [8]. These tests are designed to identify observable secret-dependent behavior rather than reproduce a complete attack, making them useful for evaluating implementation-level leakage.

That distinction applies directly to this study. Since CVE-2024-13176 reports a small timing signal whose practical significance depends partly on whether it can be measured reliably, the experiment uses controlled measurements and statistical analysis to evaluate its detectability [4], [5].

6.1 Study Design

This study used instrumented measurements to test whether the nonce-related condition described in CVE-2024-13176 produced distinguishable timing behavior during ECDSA signing. OpenSSL 3.4.0 served as the vulnerable implementation and OpenSSL 3.4.1 as the patched comparison. Both versions were built from source and tested with the same elliptic curve, Linux guest environment, measurement harness, and collection procedure.

Source-level instrumentation classified each signing operation according to the nonce-related condition described by the advisory. The probe recorded the Boolean classification along with the bit length, classification threshold, call count, and timing measurements used in the analysis. It did not record the nonce, private key, or complete intermediate values. Timing was collected at three levels of the signing path: the complete ECDSA signing operation, the nonce-inversion operation, and the downstream Montgomery multiplication that consumes the inverted nonce value. These three timing levels allowed the analysis to separate a localized internal effect from broader variation in full-signature timing.

The experimental work was conducted in two stages. An exploratory development stage validated the harness and classification logic and examined several possible timing boundaries. These runs identified the downstream multiplication as the primary measurement point. Since the instrumentation and analysis decisions were still being developed, the runs remained exploratory.

Once the instrumentation, collection procedure, and primary analysis criteria were finalized, the confirmatory experiment was conducted using the analysis plan specified before collection. The confirmatory dataset consisted of 30 interleaved blocks. Each block contained 10,000 signing observations from OpenSSL 3.4.0 and 10,000 from OpenSSL 3.4.1, producing 300,000 observations per version and 600,000 observations in total. The version measured first alternated between successive blocks, so each version appeared first in 15 blocks. Corresponding vulnerable and patched runs within the same block were treated as a paired experimental unit, reducing sensitivity to gradual system drift and persistent ordering effects.

The primary analysis plan designated the downstream Montgomery multiplication timing as the primary field and defined the block-level hit-versus-non-hit comparison within each OpenSSL version, followed by a paired comparison of the resulting block effects. Full-signature and nonce-inversion timing remained secondary measurements throughout the confirmatory analysis.

After the confirmatory analysis, the completed dataset was reused for a secondary sample-size sensitivity analysis to examine how the primary detection procedure behaved when fewer observations per version and block were retained. Because this analysis was specified after collection, it is reported as exploratory.

6.2 Test Environment

All measurements were collected in an Ubuntu Server 24.04.4 LTS ARM64 virtual machine running in VMware Fusion on a consumer Apple Silicon laptop host. The virtual machine was assigned four virtual CPU cores and 8 GB of memory. It used the server installation without a graphical desktop environment, keeping the guest configuration simple and reducing desktop background activity during collection.

The guest used GCC 13.3.0 and GNU Make 4.3. OpenSSL 3.4.0 and 3.4.1 were built from source in separate installation directories using the same general build procedure. Both instrumented builds identified their platform as linux-aarch64, used 64-bit BIGNUM words through the bn(64,64) configuration, and were compiled with the same build options, including -O3 and NDEBUG. Separate build and installation directories kept each harness linked to its intended OpenSSL build rather than the Ubuntu system library or the other tested version.

All measurements were performed locally within the Linux guest. The harness and internal instrumentation used clock_gettime with CLOCK_MONOTONIC_RAW to record elapsed times in nanoseconds. This clock is monotonic and is not affected by changes to the system wall clock. The same timing source was used for the complete signing operation and the narrower instrumented operations, with each timer surrounding a different part of the signing path. Section 6.4 describes the exact timing boundaries.

6.3 Target Operation and Curve Selection

The experiment targeted ECDSA signature generation because CVE-2024-13176 affects OpenSSL’s ECDSA signing computation [4], [5]. The OpenSSL advisory reports an approximately 300-nanosecond timing signal when the top word of the inverted ECDSA nonce value is zero [4]. It also explains that this condition occurs with significant probability only for some supported curves and specifically identifies NIST P-521 as affected [4].

All experimental measurements therefore used NIST P-521. The same curve was used for OpenSSL 3.4.0 and OpenSSL 3.4.1, keeping curve selection fixed across the vulnerable and patched measurements. Focusing the collection on P-521 also increased the likelihood of obtaining enough observations associated with the nonce-related condition for block-level statistical analysis. No additional elliptic curves were tested, so the measured effects are specific to P-521 in the tested environment.

6.4 Timing Collection Method

A C measurement harness was compiled separately against the instrumented OpenSSL 3.4.0 and OpenSSL 3.4.1 builds. After initializing its P-521 signing context, each harness process performed a short warm-up sequence and then repeatedly called ECDSA_do_sign for the requested number of recorded iterations. The probe state was reset before every recorded signature, keeping the timing and classification metadata tied to a single signing operation.

Using CLOCK_MONOTONIC_RAW, the harness recorded the duration of the complete ECDSA_do_sign call as sign_ns. The OpenSSL instrumentation recorded two narrower measurements. The op_ns field covered the nonce-inversion operation, while kinv_mul_ns covered the downstream BN_mod_mul_montgomery call that consumes the previously computed inverse through ckinv. These three timing fields allowed the analysis to compare complete signing time with the broader inversion operation and the localized downstream multiplication.

The source-level probe also classified each signing operation according to the nonce-related condition. For P-521, the instrumentation recorded the bit length associated with the inversion result and compared it with a 512-bit threshold. An observation was labeled as a hit when the recorded bit length was at or below this threshold. The probe also recorded the number of relevant inversion calls made during the signature. These fields allowed the classification to be validated without storing the nonce or the full intermediate BIGNUM value.

Each CSV row contained the sample index, sign_ns, op_ns, kinv_mul_ns, the Boolean hit classification, the call count, the recorded bit length, and the classification threshold. The harness retrieved these values after the timed signing operation had completed, so CSV output occurred outside the internal timing boundaries. The collection script ran the 30 interleaved blocks described in Section 6.1, alternating which OpenSSL version was measured first and producing 60 separate measurement CSV files. It also recorded the run order, start and completion times, output paths, environment information, and hashes of the relevant source files and binaries.

Automated structural checks were applied before statistical analysis. They verified the required columns and expected row counts, confirmed that the hit classification was binary, required one relevant classification call per observation, and checked that the P-521 threshold was 512 bits. The checks also required op_ns to be no greater than sign_ns and kinv_mul_ns to be no greater than op_ns. Zero-duration kinv_mul_ns values were allowed because sufficiently short calls could receive the same timestamp at both timer reads.

6.5 Measurement Conditions and Noise Handling

The confirmatory experiment used a single controlled local baseline within the ARM64 Linux virtual machine. No synthetic CPU load, interactive host use, native macOS comparison, loopback measurement, or network timing condition was included. Nonessential host applications were closed and the host was kept awake throughout collection.

Even under this baseline, guest and host scheduling, cache state, virtualization, and host processor behavior could influence individual timing observations. These factors remained part of the tested virtualized environment rather than being controlled as separate experimental variables. The collection therefore represents a controlled virtualized baseline rather than noise-free execution.

The block structure and collection order reduced sensitivity to gradual variation during the run. OpenSSL 3.4.0 and 3.4.1 were measured in corresponding block pairs, with the version measured first alternating between successive blocks. The analysis then used within-block hit-versus-non-hit effects and paired vulnerable-versus-patched contrasts, reducing the influence of slow drift and persistent ordering effects.

Individual observations were not removed solely because their timing values appeared unusually high or low. Quality control instead focused on dataset completeness, required metadata, valid classifications, and internal timing consistency. Block-level medians further reduced the influence of isolated extreme values without requiring a separate cutoff for timing outliers.

6.6 Statistical Analysis

The confirmatory analysis treated the interleaved blocks as the primary experimental units rather than treating all individual timing observations as independent. For each timing field and OpenSSL version, observations within a block were separated into hit and non-hit classes using the classification recorded by the instrumentation. The condition-dependent effect for that block was calculated as the median timing of the hit observations minus the median timing of the non-hit observations. A block effect was usable only when both classes were present and the file passed the structural checks described in Section 6.4.

The primary analysis used kinv_mul_ns, which measured the downstream Montgomery multiplication that consumed ckinv. The same block-level calculation was also applied to op_ns and sign_ns, but those fields remained secondary measurements. Medians were used because the timing distributions contained occasional extreme observations and were not assumed to follow a normal distribution. Using medians reduced the influence of isolated large values without requiring a separate rule for removing outliers.

Corresponding OpenSSL 3.4.0 and OpenSSL 3.4.1 blocks were then compared as pairs. For each pair, the OpenSSL 3.4.1 block effect was subtracted from the OpenSSL 3.4.0 block effect. A positive paired contrast therefore indicated a larger condition-dependent timing effect in the vulnerable version. The primary effect estimate was the median of these paired contrasts, while the mean and numbers of positive, negative, and zero contrasts were reported as descriptive summaries.

An exact two-sided sign test evaluated whether the nonzero paired contrasts were equally likely to be positive or negative. Zero contrasts were reported but were not counted as either sign. A 95 percent confidence interval for the median paired contrast was estimated by resampling the paired blocks with replacement [10]. The bootstrap used 20,000 repetitions and a fixed random seed of 20260724 so that the result could be reproduced.

The confirmatory criteria specified before collection required a positive median paired contrast, a 95 percent bootstrap confidence interval that excluded zero on the positive side, and an exact two-sided sign-test result below 0.05. All three criteria had to be met jointly, and no alternative timing field could replace the primary field after the confirmatory dataset was collected.

The analysis also calculated pooled hit and non-hit summaries for each OpenSSL version and timing field, including counts, medians, means, timing ranges, and descriptive area under the receiver operating characteristic curve (AUC). In this context, AUC describes how often a randomly selected hit observation has a greater timing value than a randomly selected non-hit observation, with ties receiving partial credit. These pooled summaries described distributional separation but were not part of the confirmatory decision criteria, since pooling observations can hide differences among collection blocks.

A secondary sample-size sensitivity analysis was performed after the confirmatory analysis. It evaluated target sizes of 500, 1,000, 2,000, 5,000, and 10,000 observations per OpenSSL version and block. For each of 500 Monte Carlo repetitions, observations were sampled uniformly without replacement within every version and block. For reproducibility, the Monte Carlo sampling used 20260725 as a fixed seed, chosen to match the date of the analysis. Samples at the smaller target sizes were nested within the larger samples from the same repetition, while the original hit classifications and vulnerable-versus-patched block pairing were preserved.

The primary block-level and paired analysis procedure was repeated at each target size. A block pair was usable only when both OpenSSL versions contained at least one hit and one non-hit observation. The sensitivity analysis recorded the number of usable block pairs, the median paired contrast, and the exact sign-test result. The exploratory joint criterion required a positive median paired contrast and a sign-test result below 0.05. Results across the 500 repetitions were summarized using medians, fifth and ninety-fifth percentiles, and the proportion of repetitions meeting the criterion.

Because the sample-size analysis reused the confirmatory observations and was specified after collection, it is treated as an exploratory sensitivity analysis. Its results describe how the completed dataset behaved when fewer observations were retained rather than establishing a general minimum sample requirement.

6.7 Vulnerable and Patched Comparison

OpenSSL 3.4.0 served as the vulnerable implementation, while OpenSSL 3.4.1 served as the patched comparison. The OpenSSL advisory identifies 3.4.1 as the fixed release for the 3.4 branch, and the associated public fix is commit 77c608f4, titled “Fix timing side-channel in ECDSA signature computation” [4], [9]. Both releases were built from source in separate installation directories using the same compiler, general build configuration, P-521 curve, virtual machine, and collection procedure.

The source-level probe used the same classification rule, timing source, and measurement boundaries in both versions. In particular, the downstream timing wrapper surrounded the same BN_mod_mul_montgomery operation that consumed ckinv. Keeping these measurement details fixed allowed the comparison to focus on the same condition and location in the signing path. The two versions were collected in alternating order and analyzed as corresponding block pairs.

The comparison focused on the condition-dependent effect within each version rather than on overall signing speed. For each block, the median non-hit timing was subtracted from the median hit timing. The resulting OpenSSL 3.4.0 effect was then compared with the corresponding OpenSSL 3.4.1 effect. This reduced the influence of general performance differences between the releases that were unrelated to the nonce condition.

OpenSSL 3.4.0 and 3.4.1 are complete releases rather than source snapshots differing only by commit 77c608f4, so other software changes may also be present between them. The comparison therefore evaluates how the reported condition-dependent behavior changes in the release containing the public fix rather than isolating the causal effect of that commit alone.

6.8 Reproducibility

OpenSSL build materials, measurement harnesses, raw data, analysis results, research notes, and scripts were organized into separate directories. Raw confirmatory measurements were preserved separately from derived tables and figures, allowing the statistical analysis to be repeated without collecting the timing data again.

The confirmatory runset retained the 60 measurement CSV files produced by the 30 interleaved block pairs. It also retained the run configuration, version order, collection log, environment information, source and binary hashes, analysis reports, and a manifest of the files included in the run package. SHA-256 manifests were also generated for later analysis outputs, scripts, figures, and archival packages.

The instrumented OpenSSL builds can be reconstructed from the OpenSSL versions, hashes of the source archives, build commands, and documented source changes used for instrumentation. The repository includes the measurement harness source, instrumentation patches and source differences, collection and quality control scripts, confirmatory analysis code, and scripts used to generate figures. It also includes the frozen confirmatory analysis plan and the later sample-size sensitivity plan, preserving the distinction between decisions made before confirmatory collection and analyses added afterward.

The reproducibility materials include the raw confirmatory data, derived tables of block effects and paired contrasts, statistical reports, and final figures. These materials are distributed with the repository rather than reproduced in full within the paper. An archival analysis package was also transferred to a separate host, where its recorded SHA-256 digest was verified again after transfer.

The repository provides the readable documentation, source materials, raw confirmatory data, and analysis files used for reproducibility. A separate archival record preserves a fixed copy of the report and reproducibility package. The repository documentation describes the required environment, data layout, analysis commands, and expected outputs.

Rerunning the preserved analysis should reproduce the recorded statistical outputs. Collecting new measurements on different hardware or virtualization platforms is a separate replication task, and exact nanosecond values may differ. A replication would instead examine whether the same condition can be classified, whether the localized timing effect has a comparable direction and structure, and whether the patched release reduces or removes that effect.

7.1 Confirmatory Dataset and Classification

The confirmatory collection produced all 60 expected measurement files, and each passed the structural quality control checks. All 30 interleaved block pairs contained both hit and non-hit observations for OpenSSL 3.4.0 and OpenSSL 3.4.1, so no pairs were omitted from the confirmatory analysis. The final dataset contained 600,000 observations, divided equally between the two OpenSSL versions.

The classified condition was rare in both versions, averaging approximately 19.4 hit observations per 10,000-observation block in OpenSSL 3.4.0 and 18.5 in OpenSSL 3.4.1. The similar hit counts gave the paired analysis comparable numbers of classified observations from each release.

7.2 Primary Within-Version Timing Effects

The primary analysis examined kinv_mul_ns, which measured the downstream Montgomery multiplication consuming ckinv. Within each block and OpenSSL version, the condition-dependent effect was calculated as the median timing among hit observations minus the median timing among non-hit observations.

OpenSSL 3.4.0 showed a positive condition-dependent effect in every confirmatory block. The pooled non-hit observations had a median timing of 83 nanoseconds, while the pooled hit observations had a median of 208 nanoseconds. This produced a pooled median difference of 125 nanoseconds. Across the 30 blocks, the median block effect was also 125 nanoseconds, with a mean of 122.9 nanoseconds and a range from 84 to 125 nanoseconds. All 30 block effects were positive.

OpenSSL 3.4.1 showed essentially no corresponding within-version effect. The pooled hit and non-hit observations both had median timings of 83 nanoseconds, producing a pooled median difference of zero. The median block effect was also zero. Twenty-nine blocks had an effect of exactly zero, and the remaining block had an effect of 0.5 nanoseconds. No block had a negative effect.

The descriptive AUC for OpenSSL 3.4.0 was 0.9999, indicating near-complete pooled rank discrimination between hit and non-hit observations. A small number of timing values were shared between the two classes, and rare non-hit observations extended into the hit timing range, so the AUC reflects very strong rank ordering rather than perfect sample-by-sample separation.

By comparison, the OpenSSL 3.4.1 AUC was 0.5076, close to the 0.5 value expected when the two classes have little useful rank separation. The within-version results show that the classified condition was consistently associated with increased downstream multiplication timing in OpenSSL 3.4.0, while the corresponding effect was essentially absent in OpenSSL 3.4.1.

7.3 Paired Vulnerable and Patched Comparison

The primary confirmatory comparison paired the OpenSSL 3.4.0 and OpenSSL 3.4.1 effects from corresponding interleaved blocks. For each pair, the OpenSSL 3.4.1 block effect was subtracted from the OpenSSL 3.4.0 block effect. A positive contrast therefore indicated that the nonce-related condition was associated with a larger downstream timing effect in the vulnerable release.

All 30 paired contrasts were positive. The median paired contrast was 125 nanoseconds, and the mean was 122.9 nanoseconds. Individual contrasts ranged from 84 to 125 nanoseconds. No paired contrast was negative or zero. The positive direction was consistent across all 30 collection blocks.

The paired-block bootstrap produced a 95 percent confidence interval of 125 to 125 nanoseconds for the median contrast. The narrow interval reflects the concentration of the observed contrasts at 125 nanoseconds.

The exact two-sided sign test produced a result of p = 1.86265 × 10⁻⁹. The observed median contrast was positive, the bootstrap interval excluded zero on the positive side, and the sign-test result was below 0.05. The three prospectively specified confirmatory criteria were therefore satisfied jointly.

The paired results show the same pattern as the within-version analysis, with a consistently larger condition-dependent effect in OpenSSL 3.4.0 than in OpenSSL 3.4.1.

7.4 Secondary Timing Measurements

The hit-versus-non-hit block analysis was also applied to op_ns and sign_ns. These measurements covered broader portions of the signing path than the primary kinv_mul_ns field. They remained secondary measurements throughout the confirmatory analysis.

For op_ns, OpenSSL 3.4.0 had a median block effect of 52.2 nanoseconds. Twenty blocks had positive effects, nine had negative effects, and one had an effect of zero. The effects ranged from −3,291 to 354.5 nanoseconds, and the exact two-sided sign-test result was 0.0614. OpenSSL 3.4.1 had a median block effect of −11 nanoseconds, with nine positive, eighteen negative, and three zero effects. Its sign-test result was 0.1221. The descriptive AUC values were 0.5209 for OpenSSL 3.4.0 and 0.4862 for OpenSSL 3.4.1.

For the full-signature measurement, OpenSSL 3.4.0 had a median block effect of 3,958.2 nanoseconds. Twenty effects were positive and ten were negative, with values ranging from −41,959 to 21,833 nanoseconds. The sign-test result was 0.0987. OpenSSL 3.4.1 had a median block effect of 229 nanoseconds, with seventeen positive and thirteen negative effects. Its values ranged from −3,959 to 5,500 nanoseconds, and its sign-test result was 0.5847. The descriptive AUC values were 0.5191 and 0.4864 for OpenSSL 3.4.0 and 3.4.1, respectively.

Neither secondary timing field produced a within-version sign-test result below 0.05 in either OpenSSL release. Their block effects also varied substantially in direction and magnitude, and their pooled AUC values remained close to 0.5. The broader measurements therefore did not show the stable condition-dependent separation observed in kinv_mul_ns.

7.5 Sample-Size Sensitivity

The exploratory sample-size sensitivity analysis examined how the primary paired procedure behaved when fewer observations from the confirmatory dataset were retained. Target sizes of 500, 1,000, 2,000, 5,000, and 10,000 observations per OpenSSL version and block were evaluated across 500 Monte Carlo repetitions.

At 500 observations per version and block, the median number of usable block pairs was 11, with 5th and 95th percentiles of 7 and 16. The median paired contrast across repetitions was 124.5 nanoseconds, with 5th and 95th percentiles of 103.5 and 125 nanoseconds. Every repetition produced a positive median contrast, and 99.6 percent also produced an exact sign-test result below 0.05, so 99.6 percent met the exploratory joint criterion.

Increasing the target to 1,000 observations raised the median number of usable block pairs to 22, with 5th and 95th percentiles of 18 and 25. The median paired contrast remained 124.5 nanoseconds, with 5th and 95th percentiles of 104.5 and 125 nanoseconds. All 500 repetitions met the joint criterion.

At 2,000 observations per version and block, the median number of usable block pairs was 29, with 5th and 95th percentiles of 27 and 30. The median paired contrast was 124.5 nanoseconds, with 5th and 95th percentiles of 124 and 125 nanoseconds. All repetitions again met the joint criterion. At both 5,000 and 10,000 observations, every repetition retained all 30 block pairs and produced a median paired contrast of 125 nanoseconds.

The target size refers to observations retained for each OpenSSL version within each of the 30 blocks. The 500-observation setting therefore retained 15,000 observations per version across the experiment, or 30,000 observations in total. The 500 value is therefore a per-version, per-block target rather than the total number of observations in the analysis.

The reduction in usable block pairs at the smaller target sizes resulted from the rarity of the classified condition. A paired comparison could not be calculated when the retained sample for either OpenSSL version lacked a hit observation in that block. Even so, the median paired contrast remained positive in every repetition, and the joint criterion was met in 99.6 percent of repetitions at the smallest evaluated target.

These findings show that the paired contrast remained detectable when substantially fewer observations from the completed dataset were retained. Because the analysis reused the confirmatory observations and was designed after collection, it describes the sensitivity of this dataset and procedure rather than a general minimum sample requirement. The sampling procedure is described in Section 6.6.

8.1 Interpretation of the Primary Finding

The primary research question asked whether the nonce-related condition was associated with statistically distinguishable timing behavior in OpenSSL 3.4.0 under the tested ARM64 virtualized Linux environment. The confirmatory results show a statistically distinguishable effect at the localized kinv_mul_ns measurement boundary. OpenSSL 3.4.0 showed a positive hit-versus-non-hit effect in every confirmatory block, while the corresponding effect in OpenSSL 3.4.1 was zero in 29 of the 30 blocks.

Each block was analyzed independently before the vulnerable and patched effects were paired. All 30 paired contrasts were positive, and the three criteria specified before confirmatory collection were satisfied jointly. This repeated pattern across block pairs shows that the primary finding was consistent throughout the confirmatory collection.

The median vulnerable-versus-patched contrast was 125 nanoseconds. The approximately 300-nanosecond signal described by the OpenSSL advisory and the 125-nanosecond contrast measured here refer to different timing measurements [4]. The advisory summarizes the reported timing behavior of the vulnerability, while this experiment measured one specific downstream multiplication on a different architecture and within a virtualized environment. The timing boundary, clock behavior, compiler output, processor architecture, and block-level effect calculation can all influence the measured magnitude.

The vulnerable build’s descriptive AUC of 0.9999 showed near-complete pooled rank discrimination. Some timing values overlapped between the two classes, and rare non-hit observations extended into the hit range, so the result reflects highly consistent separation at the selected internal boundary rather than perfect classification of every individual observation.

8.2 Localization of the Timing Behavior

The clearest condition-dependent effect appeared in the downstream Montgomery multiplication consuming ckinv. The broader op_ns and sign_ns measurements did not show similarly stable hit-versus-non-hit separation. Their block effects varied in direction and magnitude, their sign-test results remained above 0.05, and their descriptive AUC values were close to 0.5.

This contrast across timing boundaries suggests that the measurable effect was localized within a narrow part of the ECDSA signing path. The multiplication represented only a small portion of the nonce-inversion interval and an even smaller portion of the complete signing operation. As the measurement boundary widened, variation from surrounding arithmetic, memory behavior, scheduling, virtualization, and other execution costs could make the localized difference harder to distinguish.

Source-level instrumentation made this localization possible by connecting each signing operation with its classification and timing the specific downstream multiplication. The same stable separation was not detected in the broader full-signature measurement. An ordinary uninstrumented signing interface would also not provide the internal classification or direct timing at the selected boundary, so the strongest evidence from this experiment concerns localized internal detectability.

8.3 Meaning of the Patched Comparison

OpenSSL 3.4.1 showed essentially no corresponding condition-dependent effect at the primary measurement boundary. Its hit and non-hit observations had the same pooled median, its median block effect was zero, and its descriptive AUC remained near chance. This behavior contrasts sharply with the consistent positive effects observed in OpenSSL 3.4.0.

The vulnerable-versus-patched pattern is consistent with the OpenSSL advisory and the public fix for CVE-2024-13176 [4], [9]. The same classification logic and timing boundary were applied to both versions, and their measurements were collected in alternating order within paired blocks. Since the comparison used the condition-dependent effect within each release rather than overall signing speed, the observed difference aligns closely with the behavior described for the vulnerability.

OpenSSL 3.4.0 and 3.4.1 are complete releases and may differ in ways beyond the individual security fix. The comparison therefore supports a release-level vulnerable-versus-patched interpretation rather than isolating the causal effect of commit 77c608f4 alone.

8.4 Sample-Size Sensitivity

The exploratory sample-size sensitivity analysis showed that the paired procedure remained stable after substantial subsampling of the confirmatory dataset. At 500 observations per version and block, the median repetition retained 11 of the 30 possible block pairs, and 99.6 percent of repetitions met the exploratory joint criterion. At 1,000 or more observations per version and block, every repetition met that criterion.

The reduction in usable block pairs at smaller target sizes followed from the rarity of the classified condition. A paired block required at least one hit and one non-hit observation for each OpenSSL version. When the retained sample for either OpenSSL version lacked a hit observation in that block, the pair could not contribute to the analysis. Larger samples made it more likely that both classes were retained, which explains the rapid increase in usable block pairs as the target size increased.

Each target size was applied separately to both OpenSSL versions within all 30 blocks. The smallest setting therefore represented 15,000 observations per version and 30,000 observations overall, rather than 500 observations across the entire analysis.

These findings indicate that the primary paired contrast was robust when substantially less of the completed dataset was retained. Because the sensitivity analysis reused the confirmatory observations and was added after collection, the results describe the behavior of this dataset and block design rather than a general detection threshold. Different hit rates, timer behavior, hardware, environmental noise, or block structures could produce different sample requirements.

8.5 Practical Security Implications

The experiment shows that the reported nonce-related condition has a repeatable localized timing effect under the tested internal measurement setup. The effect was clear at the downstream multiplication in OpenSSL 3.4.0 and substantially reduced in OpenSSL 3.4.1. This provides empirical evidence of the implementation-level behavior described for CVE-2024-13176.

Practical exploitation would require additional steps beyond detecting this internal timing difference. An attacker would need to observe useful timing information through a broader interface, extract useful nonce-related information from those observations, collect enough signatures, and convert the resulting leakage into private-key recovery [3]. The broader full-signature measurements in this experiment were much noisier, and no uninstrumented API or network measurements were collected.

These results address only one part of the broader security assessment. OpenSSL rates the issue as Low because measuring the timing signal requires either local access to the signing application or a very fast network connection with low latency [4]. Within that larger picture, this study contributes a controlled measurement of the underlying localized timing behavior and its change in the patched release. External observability, practical key recovery, and behavior on other systems remain questions for further study.

9.1 Platform and Environmental Scope

The experiment represents one empirical result from a single ARM64 Linux virtual machine running on one consumer host. Timing behavior may differ on other ARM64 processors, x86-64 systems, native Linux installations, cloud systems, or different virtualization platforms. The measured effect magnitude should therefore not be assumed to transfer directly to another environment.

The confirmatory dataset was collected during one continuous collection session. Dividing the run into 30 interleaved blocks and alternating which OpenSSL version was measured first reduced sensitivity to gradual drift and persistent ordering effects. However, the experiment did not measure variation across different days, host reboots, guest restarts, or independent collection sessions. Repeating the collection in separate sessions would provide stronger evidence about how stable the measured effect is over time.

The virtualized environment was controlled but not noise-free. Host and guest scheduling, placement on physical processor cores, cache state, processor-frequency behavior, and virtualization could still influence individual timing measurements. The study also did not collect separate datasets under deliberate CPU load, interactive host use, native macOS execution, loopback communication, local-area networking, or remote networking. As a result, the experiment does not show how the localized timing distinction changes as additional environmental or communication noise is introduced.

9.2 Instrumentation and Timing Measurement

Source-level instrumentation was required to classify the nonce-related condition and measure the downstream multiplication directly. The added probe state, classification logic, function calls, and timer reads may have affected instruction layout, cache behavior, compiler decisions, or operation timing. The same general instrumentation was applied to both OpenSSL versions, which helps keep instrumentation-related effects comparable, although the absolute timings may differ from an unmodified build.

The timing wrapper surrounded the individual BN_mod_mul_montgomery call that consumed ckinv. This boundary was intentionally narrow and was selected before the confirmatory collection. It allowed the localized effect to be measured directly, but it is narrower than the timing available through an ordinary signing interface. An external observer would normally measure a broader API call and would not have access to the internal hit classification used by the analysis.

CLOCK_MONOTONIC_RAW reported elapsed times in nanoseconds, but using nanoseconds as the unit does not imply an effective timer resolution of one nanosecond. Timer overhead and quantization were visible in the concentration of primary measurements at repeated values. The repeated 125-nanosecond block effects and the bootstrap interval of 125 to 125 nanoseconds therefore reflect the timer and analysis procedure used in this environment rather than physical precision to the nearest nanosecond.

The saved dataset contains the classification, bit length, threshold, and call count, but not the nonce or complete intermediate BIGNUM values. These fields were sufficient for structural validation, but the complete intermediate values cannot be reconstructed from the CSV files after collection. Rechecking the classification from those intermediate values would require rebuilding and rerunning the instrumented implementation.

9.3 Software, Curve, and Workload Scope

The software comparison was limited to OpenSSL 3.4.0 and OpenSSL 3.4.1. Other affected OpenSSL branches, earlier releases, later patched releases, and alternative cryptographic libraries were not evaluated. The findings therefore apply to the tested release pair rather than every software version associated with CVE-2024-13176.

OpenSSL 3.4.0 and 3.4.1 are complete releases rather than two source trees differing only by the security patch. Unrelated software changes may therefore contribute to differences between them. The shared classification rule, timing boundary, and general build procedure kept the measurements comparable, but the design does not isolate commit 77c608f4 as the sole cause of the observed difference.

All measurements used NIST P-521 because the reported condition occurs with sufficient probability on this curve to support repeated classification and block-level analysis. Other elliptic curves were not tested, so the presence or magnitude of a comparable timing effect on them remains unknown.

The harness used the low-level ECDSA_do_sign interface with a controlled signing workload. Higher-level EVP interfaces, provider and FIPS configurations, hardware acceleration, and application-specific wrappers were not tested. The experiment also did not vary application messages or usage patterns. These choices reduced experimental variation, but the resulting workload represents a controlled test harness rather than a complete production application.

The builds used one compiler version, one optimization configuration, and the Linux AArch64 OpenSSL build target. Different compiler versions, optimization levels, link options, assembly implementations, or debugging features could change instruction selection and timing behavior.

9.4 Statistical and Sampling Limitations

The nonce-related hit condition was rare, averaging about 19 hits per 10,000-observation block for each OpenSSL version. As a result, each block’s hit-class median was based on far fewer observations than its non-hit median. Although all 30 vulnerable blocks produced positive primary effects, individual block estimates can still be influenced by the relatively small number of hit observations in that block.

The confirmatory analysis treated the 30 paired blocks as its experimental units. The 600,000 timing rows provided the observations within those units but were not 600,000 independent experimental replications. The sign test and paired-block bootstrap therefore describe consistency across the 30 observed block pairs. Variation across separately collected sessions, machines, or other environments was not estimated by this dataset.

The 95 percent bootstrap interval was unusually narrow because most paired contrasts were concentrated at 125 nanoseconds and the timer produced a discrete measurement pattern. The interval reflects uncertainty from resampling the observed block pairs. It does not imply that the underlying physical effect is known exactly to 125 nanoseconds or that the same interval would apply on other hardware.

The sample-size sensitivity analysis reused the confirmatory dataset, so its 500 Monte Carlo repetitions were repeated subsamples of existing observations rather than independently collected experiments. The high rates of meeting the joint criterion therefore show robustness to retaining less data within this dataset and block design. At the smallest target, 500 observations were retained for each version within each of 30 blocks, for 30,000 observations in total. However, different block counts, hit rates, classification rules, or measurement environments could lead to different sample requirements.

9.5 Scope of the Security Conclusion

The study measured localized timing leakage but did not perform private-key recovery. It did not estimate nonce values, construct a lattice attack, quantify the information leaked by each observation, or determine how many signatures would be needed for key recovery.

The experiment also did not establish that the primary effect is visible through an uninstrumented signing interface. The broader op_ns and sign_ns measurements were substantially noisier, and no network measurements were collected. The evidence therefore supports localized internal detectability rather than a claim of practical local or remote exploitation.

OpenSSL’s Low severity rating reflects the difficulty of measuring the timing signal without local access or a very fast, low-latency network connection [4]. This study addresses one part of that broader security assessment rather than independently determining the overall severity.