<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 23, 2016 at 5:41 PM, Erwann Abalea <span dir="ltr"><<a href="mailto:eabalea@gmail.com" target="_blank">eabalea@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>(Sending from my personal email, so this may not go to public).</div><div><br></div>Bonsoir,<div><br></div><div>On the intent:</div><div>- Basic collisions of hash functions have always been resistant up to a 2^(n/2) work effort, n being the digest size (replace "what is should be" by "its output size").</div><div>- Adding random bits at the very beginning of the hashed data changes the necessary attack from a chosen-prefix collision into a random-prefix collision (not a preimage yet, not even a second preimage). It's important for the random bits to be at the beginning and not at the end of the tbsCertificate (random-prefix).</div><div>- This is not a solution against a completely failing hash function, just a mitigation against an aging hash func that sees its collision resistance weaker than expected (only works when collision resistance is affected, doesn't work against preimage or second preimage attack). See it as an additional margin time to move away from this hash, and facts prove again today that this move can be very hard to do (SHA1 discussions).<br></div></blockquote><div><br></div><div>Excellent corrections, thank you.</div><div><br></div><div>Amended intent:</div><div><br></div>As demonstrated in <a href="https://events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf">https://events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf</a>, hash collisions can allow an attacker to forge a signature on the certificate of their choosing. The birthday paradox means that, in the absence of random bits, the security level of a hash function is half its output size. Adding random bits to the very beginning of issued certificates mitigates changes the necessary attack from a chosen-prefix collision into a random-prefix collision. For a long time the BRs have encouraged adding random bits to the serial number of a certificate, and it is now common practice. This ballot makes that best practice required, which will make the Web PKI much more robust against all future weaknesses in hash functions, buying additional time to transition away from failing hash functions in the future. Additionally, this ballot replaces "entropy" with "CSPRNG" to make the requirement clearer and easier to audit, and clarifies that serial number must be positive.</div></div></div>