

When Will We See Collisions for SHA-1? - mikegerwitz
http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

======
notaddicted
AFAIK GPUs are far more cost effective. I've just produced this estimate.

    
    
      2xAMD 7970 : 8000Mhash/s ~= 2^33
      Seconds per year ~= 2^24
      Total Hashes ~= 2^57
    
      1kW * $0.15/kWh * 1 year ~= $1315
      Rig cost (guess)  ~= $2000
      Total cost ~= $3315
    

Price for 2^60 hashes in a year: 2^60 / 2^57 * $3155 ~= $25000

If you assume a 6X discount in 2021, then it will be <5k. Still, it takes a
year, or more money for machines. Corrections welcome. Trying to run sixteen
7970s for a year straight is probably a total crap shoot.

The hash rate is from <http://www.codinghorror.com/blog/2012/04/speed-
hashing.html> .

[EDIT: I wouldn't be shocked if FPGAs could do it with 1/10th the power and
heat, with the same variable cost (hardware & power) but with an additional
fixed cost to build the devices; I'm basing this estimate on bitcoin mining
boards like these: <https://en.bitcoin.it/wiki/Mining_hardware_comparison> ]

~~~
thechut
I think this is the correct way to look at. a CPU is vastly slower at
performing rainboow attacks than a GPU. Many of the largest bitcoin rigs could
probably find a SHA-1 collision in a matter of months.

~~~
notaddicted
Yeah, I haven't made any provision for the other calculations required by the
attack, so maybe those take a lot of resources, maybe they don't.

------
tptacek
Worth mentioning here that practical collision attacks do not automatically
jeopardize all security protocols that depend on the hash. For instance, MD5
is totally broken, but there are no known practical attacks against HMAC-MD5.
I hope it goes without saying that this stuff generally does not apply to
password hash constructs either.

~~~
beagle3
I need a "digital public notary" service, where I send some hash to the
notary, they sign it and give me back a signed copy (with the notary's system
or public key of choice, e.g. 4096 RSA or 256 bit ECDSA or whatever)

If I want it to be considered reasonable valid proof that I did, indeed, have
the data leading to the hash when the notary signed it, and I want stuff I
sign today to be acceptable 10 years from now, would you consider HMAC-MD5
viable? How about HMAC-SHA1? I guess plain MD5 and SHA1 are out of the
question according to this article.

Speed is not a concern here, so I would be happy with HMAC-SHA3 or anything
else... Also, I keep reading that multiple signatures (MD5 + SHA1) are only as
strong as the strongest one, but that does not make any sense to me - If you
have two differently seeded (initial internal state) MD5 hashes, it should
already be much harder to exploit (perhaps not double the number of bits, but
surely a large load factor)?

~~~
pbsd
You can hedge your bets with hash combiners:
<http://homepages.cwi.nl/~pietrzak/publications/FLP08.pdf>

C_{4P}(SHA-2-512, SHA-3-512) should remain solid for a long long time. Your
point of failure is, now, the signature scheme. To last for decades, do not
use RSA or DSA. Use elliptic curve DSA or similar (EdDSA comes to mind).

~~~
AnthonyMouse
What's the reasoning for why RSA/DSA with a sufficient key length would be
vulnerable sooner than elliptic curve?

~~~
tptacek
Mathematicians are making progress with the multiplicative groups used by RSA
and DSA, which indicates that the security margins for RSA and DSA are lower
than they are for elliptic curve groups. I can't pretend to be literate here
but Daniel Bernstein would point out the numeric field sieve as an example of
something that threatens RSA and DSA but not ECC.

As I understand it, ECC is also significantly faster.

~~~
beagle3
Does anyone know of a smart card that implements ECC? Accessible from Linux is
a plus.

(And in a related issue - does anyone know why smart card deployment in the US
is so far behind Europe? Why is it that I need to get a PGPcard from germany
and can't find anything comparable in the US?)

------
jwatte
The fallacy of "A 32-core server is fast, and I can rent servers for 4 cents
an hour, so I can rent a 32-core server for 4 cents" is unfortunaltely more
common than I'd wish. If that simple error is in this analysis (and affects
the cost analysis by at least 2^6), what other errors are in the math that I'm
not as qualified to catch?

------
FootballMuse
GPU's are obviously more cost efficient than general purpose x86 CPUs. But as
we are learning, specialty hardware using very little power can be an
extremely effective hashing device hash as butterfly labs is doing with
SHA-2[1]. If a similar device were developed for SHA-1, I'm not crypto-
proficient enough to know the difference, but I imagine it would be extremely
efficient as well.

[1]: [http://news.yahoo.com/butterfly-labs-announces-next-
generati...](http://news.yahoo.com/butterfly-labs-announces-next-generation-
asic-lineup-054626776.html)

------
SilasX
Crypto-newb question: is there any reason it takes the "number of
computations" difficulty as a given, rather than estimating the rate at which
attacks will get smarter and require fewer computations?

The analysis that's given includes estimates of decreasing computation cost
from Moore's law, but no corresponding estimate of decreasing cost from
patterns found in the SHA-1 hash function.

Also, why does the cost estimate focus on commodity CPUs, rather than GPUs,
which are much better at the (parallel) computations that hash attacking
involves?

~~~
jpablo
He's only providing a lower bound for this numbers, he specifically spells
your concerns. He mentions that any improvement on:

* number of cores per CPU

* number of CPUs per server

* any improvements in cryptanalysis

* instruction set improvements (arm sha1, gpus)

Will only make his number even scarier.

------
rb2k_
I wonder how the upcoming generations of Bitcoin mining hardware will change
this calculation. They are all SHA1 FPGAs/ASICs that implement SHA1. It would
also be interesting to see how GPUs perform.

~~~
marshray
Bitcoin is SHA-2-256 I believe.

~~~
rb2k_
oops, close enough :)

------
wcoenen
The bitcoin network does >20 terahashes per second now in total (but SHA-2,
not SHA-1). Those 2^60 hashes would take only 16 hours at that speed.

------
ben0x539
> Since this argument only takes into account commodity hardware and not
> instruction set improvements (e.g., ARM 8 specifies a SHA-1 instruction),
> [...] the need to transition from SHA-1 for collision resistance functions
> is probably more urgent than this back-of-the-envelope analysis suggests.

So the ARM 8 SHA-1 instruction contributes to making itself obsolete? :-)

------
ChuckMcM
It is sad to see an Intel engineer misstate/misuse Moore's Observation. The
actual observation was that the number of transistors you could put on a chip
doubled every 18 months, _not_ performance. For a long time more transistors
meant more performance but now that isn't the case. So people put more 'cores'
on to a chip to use up those transistors.

That said, the ARM threat is under estimated since the power budget is so much
lower and the cost per CPU is also lower. So 10,000 ARM8 cores with SHA
hardware are cheaper than 10,000 x86 cores doing the calculation in software.

~~~
wtallis
When talking about embarrassingly parallel problems, it _is_ okay to equate
more transistors with more performance.

~~~
marshray
Especially when we're talking about something like SHA-1 that was designed to
be efficiently implemented in hardware.

------
mjs
From the Varnish documentation, addressing an assumption of the Varnish source
code that unique inputs will produce a unique SHA-1 hash: "The risk of
collision is very small however, and I can all but promise you, that you will
be fully offset in fame and money for any inconvenience a collision might
cause, because you will be the first person to find a SHA256 collision."

[https://www.varnish-
cache.org/docs/trunk/phk/varnish_does_no...](https://www.varnish-
cache.org/docs/trunk/phk/varnish_does_not_hash.html)

------
zvrba
Not everybody agrees that Moore's law will continue, see for example "Dark
silicone and end of multicore scaling"

<http://dl.acm.org/citation.cfm?id=2000108>

ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf

They use existing data to model CPU perofrmance increase and conclude with
"Through 2024, only 7.9 average speedup is possible across commonly used
parallel workloads, leaving a nearly 24-fold gap from a target of doubled
performance per generation."

~~~
DanWaterworth
I imagine "dark silicone" would be quite different than "dark silicon".

------
zdw
What is the use case for this? At best, I could see replacing data with
something with the same hash but is gibberish. Why would a "crime syndicate"
want this?

Also wouldn't an n-tuple of multiple hash methods and the file size be even
more impossible to replicate than a single hash, but not be that much harder
to generate initially?

~~~
beagle3
There are humorous examples from the past, where there 20 PDF files prepared
in advance, all having the same MD5 hash, where each one of them says "We
hereby predict X is going to be president".

You publish the hash in advance, and after elections you only publish the
right PDF file, thereby "proving" your clairvoyance.

More seriously: You can get a notary (e.g. Microsoft Authenticode) to sign one
file, and then provide another with the same hash.

For now, it only helps you with planned fraud, not after-the-fact forgery.

~~~
VMG
md5? I think you mean md4. There are few examples of md5 collisions:
<http://stackoverflow.com/a/1224282/92493>

~~~
gjm11
No, MD5. See, e.g., <http://www.win.tue.nl/hashclash/Nostradamus/>

------
AnotherBanned
I think we can assume that governments are capable of cracking SHA-1 today,
and all common internet encryption protocols like AES-128 last year. The costs
of building such a facility would be trivial and could be hidden within almost
any TLA agency's budget.

~~~
tedunangst
You obviously know something about AES that I do not.

