Tracking these details is a bit tedious, so I'm trying to make sure. The related discussion on mozilla.dev.security.policy was titled [Pre-Incident Report - GoDaddy Serial Number Entropy](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/F8AS4MNVCAAJ) * On [2019-03-12](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/Wnt4QSO9BwAJ), and in Comment #0, Daymion stated that "We are looking to scope and roadmap upgrading our certificate serial number to a minimum of 128-bit, or the max possible." * On [2019-03-12](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ), Daymion described the algorithm as: ``` 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a CSPRNG with at least one bit in the highest byte set to 1 CheckForDuplicate(64bits_entropy)//Verifies the serial is unique, otherwise repeat GetRandom64Bits() Cert.SetSerialNumber(64bits_entropy) //The ANS.1 encoding will either write this number as 8 or 9 octets. ``` * It was pointed out that same day that the described algorithm results in [63.994353](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/VArvVlv0BgAJ) bits of entropy * Clarifications were requested on [2019-03-15](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/s9NCJDypCwAJ) regarding the described algorithm * A [statistical analysis](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/epoLNYh3CgAJ) of the (known) certificates was performed, resulting in the [following spreadsheet](https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing). In this, GoDaddy's two primary issuing CAs were https://crt.sh/?caid=904 and https://crt.sh/?caid=797 , with a respective distribution of 49.99450631% / 50.00549369% and 49.98069428% / 50.01930572% The area I'm concerned about is that clarifications to the psuedo-code were not provided, and thus the described algorithm is not compliant - but close enough to look compliant for such analysis. I'm hoping that GoDaddy will provide the necessary clarifications as to how it generated serial numbers during the period of time in question. As described, requiring 1 bit in the high byte results in 255 values, rather than 256 (since an all zero value is excluded), along with 2^56 other possible values. lg((2^8 - 1) * 2^56) is 63.9943534369 bits of entropy.
Bug 1533774 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Tracking these details is a bit tedious, so I'm trying to make sure. The related discussion on mozilla.dev.security.policy was titled [Pre-Incident Report - GoDaddy Serial Number Entropy](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/F8AS4MNVCAAJ) * On [2019-03-12](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/Wnt4QSO9BwAJ), and in Comment #0, Daymion stated that "We are looking to scope and roadmap upgrading our certificate serial number to a minimum of 128-bit, or the max possible." * On [2019-03-12](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ), Daymion described the algorithm as: ``` 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a CSPRNG with at least one bit in the highest byte set to 1 CheckForDuplicate(64bits_entropy)//Verifies the serial is unique, otherwise repeat GetRandom64Bits() Cert.SetSerialNumber(64bits_entropy) //The ANS.1 encoding will either write this number as 8 or 9 octets. ``` * It was pointed out that same day that the described algorithm results in [63.994353](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/VArvVlv0BgAJ) bits of entropy * Clarifications were requested on [2019-03-15](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/s9NCJDypCwAJ) regarding the described algorithm * A [statistical analysis](https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/epoLNYh3CgAJ) of the (known) certificates was performed, resulting in the [following spreadsheet](https://docs.google.com/spreadsheets/d/1K96XkOFYaCIYOdUKokwTZfPWALWmDed7znjCFn6lKoc/edit?usp=sharing). In this, GoDaddy's two primary issuing CAs were https://crt.sh/?caid=904 and https://crt.sh/?caid=797 , with a respective distribution of 49.99450631% / 50.00549369% and 49.98069428% / 50.01930572% The area I'm concerned about is that clarifications to the psuedo-code were not provided, and thus the described algorithm is not compliant - but close enough to look compliant for such analysis. I'm hoping that GoDaddy will provide the necessary clarifications as to how it generated serial numbers during the period of time in question. As described, requiring 1 bit in the high byte results in 255 values, rather than 256 (since an all zero value is excluded), along with 2^56 other possible values. lg((2^8 - 1) * 2^56) is 63.9943534369 bits of entropy.