On Friday, 29 April 2016 02:22:14 UTC+1, Man Ho (Certizen) wrote: > Hi Rob, > > I know that there is a discussion regarding "bits of entropy" or > "unpredictable bits" in certificate serial number. I do not familiar > with this topic, but my gut feeling is that "unpredictable bits" is > relatively subjective.
Both are subjective in the sense that mathematicians have never developed, and don't expect to be able to develop a method to assure ourselves that a list of numbers, much less an individual number exhibits this property of being unpredictable. Instead we only have statistical tests, for which we can say that a list of inputs which fails the tests is too predictable. There is an absolutely objective test, but it is negative. If anyone can predict N-bits of your next serial number then those N-bits were by definition predictable. To give a concrete example if you issued with 16 digit serial numbers, but the first 8 are YYYYMMDD from the actual date, any bad guy can predict those numbers in the next certificate, thus they don't constitute entropy / unpredictable bits, so your serial numbers have no more than 8 digits of entropy in this scenario. In the payment industry a specification was developed in which the consortium were uncomfortable with this idea of "unpredictable" values in cryptography and so they simply defined for conformance purposes that the values should not repeat. Unsurprisingly some implementations of their specification chose to use a simple counter, meaning bad guys could in fact trivially predict the next "unpredictable" value and attack that way. We don't know for sure how much fraud was incurred as a result. Today's public key systems rely extensively on cryptographically secure random numbers and on statistical rather than absolute assurances already, so this is not really new territory, even aside from the BRs having previously required 20-bits and Microsoft requiring 64-bits. > What is your definition of "bits of entropy" used in crt.sh? Could you > elaborate a bit more on how "bits of entropy" is verified? I'm sure Rob can give a more technical answer, but my understanding is that crt.sh doesn't (and probably can't) detect that individual certificates have enough entropy, instead it flags certificates based on the length of the serial numbers. So it's neither sufficient nor necessary that every certificate from an issuer should pass the test in crt.sh, but it is very suspicious if many or all certificates from a particular issuer fail this test. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
