<div dir="ltr"><div class="gmail_extra">I think it&#39;s mostly a precaution against future attacks against SHA-2.  I&#39;d like us to act now mainly because we&#39;re thinking about it, and I&#39;d much prefer to be 10 years too early...  </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 5, 2016 at 5:41 AM, Doug Beattie <span dir="ltr">&lt;<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What drove Ben&#39;s initial proposal and the long following debate to mandate at least 64 unpredictable bits?   I haven&#39;t seen any discussions of the issue we&#39;re solving, just technical approaches for adding randomness to the certificate content.<br>
<br>
For SHA-1, sure, I understand this provides solid protection against preimage attacks, but is this necessary for SHA-2 algorithms?  It&#39;s a good idea, we should all be doing long serial numbers, but what&#39;s driving the need to mandate 64+ bit serial numbers and CSPRNG now?<br>
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><span class="im HOEnZb"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of Fotis Loukos<br>
Sent: Wednesday, May 4, 2016 2:53 AM<br>
To: Jacob Hoffman-Andrews &lt;<a href="mailto:jsha@letsencrypt.org">jsha@letsencrypt.org</a>&gt;<br>
Cc: <a href="mailto:public@cabforum.org">public@cabforum.org</a>; Tim Hollebeek &lt;<a href="mailto:thollebeek@trustwave.com">thollebeek@trustwave.com</a>&gt;<br>
Subject: Re: [cabfpub] Pre-Ballot 164 - Certificate Serial Number Entropy<br>
<br>
<br>
</span><span class="im HOEnZb">There are hardware devices that use cryptographic hash functions in order to unbias the biased input by the RNG. However, a cryptographic hash function is not a CSPRNG.<br>
<br>
I agree that the most common approach is to use the output from the true random source to seed a CSPRNG (as done for example by the linux kernel for the /dev/urandom device), however in the future true RNGs that are able to provide random bytes in high speed may be much more common.<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div></div>