<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 1, 2017 at 10:55 PM, Peter Gutmann <span dir="ltr"><<a href="mailto:pgut001@cs.auckland.ac.nz" target="_blank">pgut001@cs.auckland.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">Mark Steward <<a href="mailto:marksteward@gmail.com">marksteward@gmail.com</a>> writes:<br>
<br>
>We do, it's all in the report and referenced papers.<br>
<br>
</span>As several people have pointed out, it's not in the report.  Or perhaps more<br>
accurately there is disagreement between the authors of the report and the<br>
people reading it as to what's in there.  From my multiple re-readings it<br>
appears that the 6500 CPU-years is the one-off computation for a given<br>
document and the 100 GPU years (100 GPU years, not 110 GPU hours) is for each<br>
new collision with that document.<br>
<br></blockquote><div><br></div><div>Yep, my reading is that you'd need to repeat all the work of crafting the path, optimising, finding a suitable first block, crafting the second path, optimising again, and then crunching to get a second block, for each different document.</div><div><br></div><div>The first block isn't a one-off for a given document (they found another suitable first block) but there's no point repeating that work if you only want to find more collisions. The second block is the more expensive one, though, so it's not like they fall out like gumballs.</div><div><br></div><div>I realise that USD 110k is a headline number - they point out that the expected time to find a second-stage collision is 2.5 times what it took. But even if you're really unlucky, and the first stage once converted to GPU takes as much processing power as the second stage, we'd still only be looking at an average of USD 550k of processing time per prefix on a universally available resource.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Another thing that the report is insufficiently clear about is that this isn't<br>
about creating a collision with an existing document, it's about creating a<br>
document from scratch that can be manipulated to have two different forms but<br>
the same hash.  So it's more a badly-designed-repository-<wbr>stress-tester than a<br>
signature-forgery attack.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I think the report makes it clear that it's a chosen-prefix attack, and while Web PKI is less vulnerable these days, are people outside that ecosystem as stringent about not signing subverted data? And even a badly-designed repository might be an app store with automated validation, or someone's reimplementation of a docker registry.</div><div><br></div><div><br></div><div>Mark</div></div></div></div>