> In accordance with our conversations to date, prior to 3/7 6:30pm AZ we > utilized raw 64 bit output from CSPRING, with uniqueness and non zero checks. > This new understanding of the rules calls for us to modify our original > disclosure to 0 affected certificates.
"uniqueness and non zero checks" have crippled the effective 64 bit output from the CSPRNG, so, as I can see it, all of your previously generated serial numbers (according to the algorithm you disclosed [1]) could be considered non-compliant to current BRs as explained below: First, according to your algorithm, if the MSB in the fully random 8 octets is 1 you add a leading 00 byte, so until that time you have 64 full bits of entropy, i.e. 18446744073709551616 possible different values. Then, you have to filter out some values. To begin with, you filter out the value 0, leaving you with 18446744073709551615 possible values. Now, you filter the previosly generated serial numbers (known to potential attackers thanks to current CT deployment), let's say 1000000 at a given point in time, so now you are left with 18446744073708551615 possible values. And if we do the math: 18446744073708551615 / 18446744073709551616 * 64 = 63.999999999996530549578599433858 Which is less than the required 64 bits. So any filtering operation (e.g. previously generated serial numbers) actually reduce effective entropy and overall security as illustrated in the fictional and forced scenario in [2]. And finally, we can realize that serial number generation algorithms, among others requirements, have to be foresee the number of certificates intended to be generated all along the CA lifetime. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/7WuWS_20758/mgQaADsCCwAJ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
