Historical OpenSSL 0.9.8 RNG experiment — request for review of CVE-2008-0166 causal interpretation

78 views

Skip to first unread message

Dylan Hernandez

unread,

Sep 23, 2026, 6:13:58 PMSep 23

to openssl-users

Hello all,

I'm looking for technical criticism of a controlled experiment involving the historical Debian OpenSSL CVE-2008-0166 RNG vulnerability.

I compared two treatments:

Vulnerable: Debian OpenSSL 0.9.8c-4etch2
Repaired: Debian OpenSSL 0.9.8c-4etch3

Both were exercised through the same ECDSA signing path under frozen synthetic conditions. The experiment used a fixed synthetic secp256k1 scalar and three ordered synthetic message digests, with fresh processes and controlled runtime coordinates.

The public observable was the ordered ECDSA r sequence.

Across three fresh-process repetitions per treatment:

VULNERABLE_ORDERED_R_SEQUENCE_IDENTICAL_ACROSS_RESTARTS=YES REPAIRED_ORDERED_R_SEQUENCE_IDENTICAL_ACROSS_RESTARTS=NO POSITIVE_CONTROL=PASS NEGATIVE_CONTROL=PASS EXECUTION_ACCOUNTING=PASS TREATMENT_DIFFERENCE_ISOLATION=PASS RNG_ORDERING=PASS

The executed signing/RNG path was:

ECDSA_sign → ECDSA_do_sign → ECDSA_sign_setup → BN_rand_range → RAND_bytes → ssleay_rand_bytes

My source-difference analysis identified the relevant Debian RNG repair in md_rand.c, including restoration of:

MD_Update(&m, buf, j);

My specific question for people familiar with historical OpenSSL RNG behavior is:

Is that vulnerable/repaired treatment isolation sufficient to attribute the observed difference in restart-conditioned ECDSA r reproducibility to the Debian RNG treatment, or is there additional OpenSSL state, initialization behavior, or another relevant confounder that should be considered?

I have a technical dossier with the preregistration, source-difference analysis, controls, hashes, and experimental results that I can provide if useful.

For context, I also froze the resulting vulnerable-treatment public fingerprint before comparing it with a bounded historical public-signature dataset. That separate comparison produced zero intersections. I am not claiming historical vulnerable deployment, wallet identification, or wallet recovery.

This is not a paid request or job posting. I'm looking for voluntary technical criticism from anyone who finds the historical OpenSSL question interesting.