On Friday, 8 March 2019 04:28:17 UTC+1, Matt Palmer wrote: > On Thu, Mar 07, 2019 at 09:03:22PM -0600, Matthew Hardeman via > dev-security-policy wrote: > > On Thu, Mar 7, 2019 at 8:54 PM bif via dev-security-policy < > > [email protected]> wrote: > > > But BRs are not to be interpreted, just to be applied to the letter, > > > whether it makes sense or not. When it no longer makes sense, the wording > > > can be improved for the future. > > > > Indeed. But following BR 7.1 to the letter apparently doesn't get you all > > the way to compliance, by some opinions. > > No, *misinterpreting* BR 7.1 doesn't get you all the way to compliance. > > > After all, nothing in 7.1 > > requires anything as to the quality of the underlying CSPRNG utilized. > > The "CS" is "CSPRNG" stands for "cryptographically secure", and "CSPRNG" is > defined in the BRs. > > > It > > does not specify whether the 64-bits must be comprised of sequential bits > > of data output by the CSPRNG, > > Nor does it need to. > > > nor does it specify that one is not permitted > > to discard inconvenient values (assuming you seek replacement values from > > the CSPRNG). > > If you generate a 64-bit random value, then discard some values based on any > sort of quality test, the end result is a 64-bit value with > less-than-64-bits of randomness. The reduction in randomness depends on the > exact quality function employed. > > - Matt
Could be me but when I read this spec as a programmer, I would probably decide that the serial number needs to be bigger than 64 bits. After all the specs require you to exclude the value zero. Because of that the entropy of the serial number can only be at least 64 bits if its size is actually larger than 64 bits. And if you need more than 64 bits anyway... having a bit more entropy than required is not going to hurt, so I'd probably go for 128 bits. ;-) CU Hans _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
