On 12 May 2016 at 04:48, Michele Orrù <li...@tumbolandia.net> wrote: > I also gave a look at letsencrypt/boulder[2], and as far as I've > been able to understand there is a in64 counter, and 7 bytes of > randomness that determine the nonce. Am I wrong to say that there > are less than 128 bits of entropy here then?
Yes, that is less than 128 bits, and maybe lower still if you were talking about predictability, but it's still probably plenty (depending on how that counter is set and reset). I believe that the important point here is not predictability in the crypto sense, but uniqueness. The nonce needs to be generated such that an attacker has very low odds of being able to find and use a collision. Of course, having very low odds of collision is a good way of managing that (128 bits of randomness gives pretty low odds). I'll bet that boulder is doing that so that they good space efficiency when the nonce is encoded in base64. The last octet in a 128 bit value takes a whole extra byte to encode. A 32 bit counter and 11 bytes of randomness would better meet the above goals, or just 15 octets of randomness. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
