<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 1, 2017 at 2:52 AM, Kevin W. Wall <span dir="ltr"><<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</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-">On Tue, Feb 28, 2017 at 9:18 AM, Theodore Ts'o <<a href="mailto:tytso@mit.edu">tytso@mit.edu</a>> wrote:<br>
> On Sun, Feb 26, 2017 at 09:04:45PM -0600, Nikita Borisov wrote:<br>
>> On Sat, Feb 25, 2017 at 5:06 PM, Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>><br>
>> wrote:<br>
>><br>
>> > They announced an attack that requires a nation-state's worth of resources<br>
>> > and<br>
>> ><br>
>><br>
>> The cost estimates were around $500K at normal EC2 prices and $100K at spot<br>
>> prices. I'd have imagined that nation states command rather more resources<br>
>> than that!<br>
><br>
> If I'm not mistaken, those are the costs for the *second* phase of the<br>
> attack (110 GPU years).  However, you have to first carry out the<br>
> *first* phase of the attack, which takes 6200 CPU years.<br>
><br>
> Aside from throwing out numbers which are much scarier, which make for<br>
> good headlines and scaring clients to score more consulting time, is<br>
> there a reason why people are fixated on the 110 GPU year "second<br>
> phase" number, and not the 6200 GPU years "first phase" number?<br>
<br>
</span>I've wondered that as well, unless somehow it is expected that the<br>
first phase produces results that can somehow be reused for multiple<br>
collisions.<br>
<br>
But more specifically, a question that I've tried to get an answer to and<br>
so far have been unable to turn up is:<br>
    What exactly type of CPU / GPU is Google basing these ill-defined<br>
    "CPU year" and "GPU years" terms on?<br><br></blockquote><div><br></div><div>It's all in the report PDF [1]:</div><div><br></div><div>> Theory predicts the first near-collision attack to be at least a factor 6 faster than the second attack</div><div><br></div><div>> run on a heterogeneous CPU cluster hosted by Google, spread over 8 physical locations...</div><div><br></div><div>> There was a variety of CPUs involved in this computation, but it is reasonable to assume<br></div><div>> that they all were roughly equivalent in performance. On a single core of a 2.3 GHz Xeon</div><div>> E5-2650v3...</div><div><br></div><div><div>> a GPU being far more powerful, it is actually much more efficient</div><div>> to run it on the latter: the attack of [18] takes only a bit more than four days to run on</div><div>> a single GTX 970, which is much less than the estimated 150 days it would take using a</div><div>> single quad-core CPU.</div><div><br></div></div><div>> We did not write a CPU implementation of our own attack for the search</div><div>> of the second block... it is reasonable to assume that the gap would be of the same order.</div><div><br></div><div>If you invest in dedicated hardware you'd probably be able to provide a hash collision service right now. The estimated global Bitcoin hash rate[2] is currently 3-4 * 10^18 SHA-256 hashes per second, while the estimated work for this collision is 9 * 10^18 SHA-1 hashes in total.</div><div><br></div><div><br></div><div>Mark</div><div><br></div><div>[1] <a href="http://shattered.it/static/shattered.pdf">http://shattered.it/static/shattered.pdf</a></div><div>[2] <a href="https://blockchain.info/charts/hash-rate">https://blockchain.info/charts/hash-rate</a> </div></div></div></div>