<div dir="ltr">Corey's previous email at <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001846.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001846.html</a> suggested iterating over 11 platforms was necessary:<br><br>> As stated in my previous messages, you need to check for all 11 platforms supported by Debian at the time of the vulnerability<br><br>> The presentation you linked to in the previous email stated as such on slide 11 ("… and each platform (x86,x64,PPC,…)"). As time goes on and this antiquated hardware becomes increasingly rare, this will be an increasingly onerous requirement. for incumbent --and especially new -- CAs.<br><br>The presentation referred to was <a href="https://trailofbits.files.wordpress.com/2008/07/hope-08-openssl.pdf">https://trailofbits.files.wordpress.com/2008/07/hope-08-openssl.pdf</a> (linked by Ryan in <a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001845.html">https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001845.html</a>).<br><br>The presentation has this text:<br>> As exhaustive as possible:<br>> … and each platform (x86,x64,PPC,…)<br><br>However, I don't think that line was meant to claim that each of the 11 platforms differs. That's made clear later in the presentation by the fact that the researchers simply used Ubuntu VMs on various affected endianness / word size, and only treated endianness / word size, not platform, as a variable in their naming scheme:<br><br>> Amazon provides VMs, including vulnerable Ubuntu<br>> 1. Populate a distributed queue with strings describing which keys to generate<br>> “rsa/1024/65537/le32/0-FF”<br>> 2. Launch 20 VMs (the default limit)<br><br>Also, all contemporary sources, including the Debian Security team generating {openssl,openssh,openvpn}-blacklist, seem to have believed endianness and bit size were the only meaningful variables with regard to platform.<br><br>> <a href="https://www.cs.umd.edu/class/fall2017/cmsc818O/papers/private-keys-public.pdf">https://www.cs.umd.edu/class/fall2017/cmsc818O/papers/private-keys-public.pdf</a><br><br>To avoid any potential confusion: even though "2017" is in the URL, this paper was from 2009 as you can see here: <a href="https://dl.acm.org/doi/10.1145/1644893.1644896">https://dl.acm.org/doi/10.1145/1644893.1644896</a>.<br><br>One other bit of useful information for people following these threads: The previous thread suggested that the rnd / nornd / noreadrnd states are documented at <a href="https://wiki.debian.org/SSLkeys">https://wiki.debian.org/SSLkeys</a>, but that page does not document those states. The best documentation I've been able to find is in <a href="https://packages.debian.org/jessie/openssl-blacklist">https://packages.debian.org/jessie/openssl-blacklist</a>. Download the diff file (<a href="http://deb.debian.org/debian/pool/main/o/openssl-blacklist/openssl-blacklist_0.5-3.diff.gz">http://deb.debian.org/debian/pool/main/o/openssl-blacklist/openssl-blacklist_0.5-3.diff.gz</a>) and find gen_certs.sh. It contains this comment:<br><br>> # There are 3 types of vulnerable moduli:<br><br>> # 1. ~/.rnd does not exist when openssl is run<br>> # 2. ~/.rnd existed, but was not readable when openssl is run<br>> # 3. ~/.rnd is readable and writable when openssl is run<br><br>This is backed up by the 2009 "When Private Keys Become Public" paper:<br><br>> Because the binary representation in memory of certain values is added to the entropy pool, not a canonical representation, our key generation must account for the target platform’s endianness and native word size. In addition, the presence of a file called .rnd in the user’s home directory affects the behavior of OpenSSL’s command-line utilities. If it is present, its contents are added to the entropy pool. Accordingly, we must generate two sets of keys: ones assuming the presence of .rnd, one its absence. (Because of the Debian bug, the contents of the randomness file are not consulted; all 1024-byte files produce the same result.) When .rnd is missing, versions of OpenSSL before and after 0.9.8f have different behavior that we must again account for.6 Debian-derived distributions shipped versions with both behaviors, so we must account for both.<br><br>So I agree with the above posts, that we should parameterize only on endianness and word size (and pid, rnd, modulus length), not full system architecture.<pre style="white-space:pre-wrap;color:rgb(0,0,0)"></pre></div>