But, come on. Here&#x27;s the process they used:<p><i>We begin with 17 natural constants: π, e, Euler gamma, √2, √3, √5, √7, log(2), (1 + √5)&#x2F;2, ζ(3), ζ(5), sin(1), sin(2), cos(1), cos(2), tan(1), and tan(2). We extend this list by including reciprocals. We then convert to constants between 0 and 1 in three different ways: take the fractional part; divide by 256 and discard any minus sign; or take all bits starting from the most significant (i.e., divide by an appropriate power of 2), again discarding any minus sign. Removing duplicates produces 73 starting seeds.</i><p><i>For the hash function, we are using the 10 variants of Keccak listed above. As length for each seed, we use either 20, 32, 48, 64, or 128 bytes, or the block size of the Keccak configuration (6 choices). The seed is either stored in big-endian or little-endian format (2 choices). In order to update the seed during the generation procedure, we are using a counter of length either 0 (i.e., the seed itself is incremented), 2, 3, 4, or 8 bytes (5 choices), either at the beginning or at the end of the seed (2 choices). We either truncate the seed to the right length or round it to the right length (2 choices); note that in many cases these are identical. Finally, we are using several different ways to update the counter between generation of a and b and to choose the order of generating a and b (8 choices). All in all, we have 73 · 10 · 6 · 2 · 5 · 2 · 2 · 8 = 1401600 possible configurations, mostly different, with a high probability to find a procedure that produces the desired vulnerability.</i><p>They ended up using picky encoding of cos(1) and a counter that ticked 184 times, and they got <i>a = 0x7144BA12CE8A0C3BEFA053EDBADA555A42391AC64F052376E041C7D4AF23195EBD 8D83625321D452E8A0C3BB0A048A26115704E45DCEB346A9F4BD9741D14D49</i>.<p>It&#x27;s not like they simply got a=BADA55... from pi.