Live data from Hacker News

The first chosen-prefix collision for SHA-1

sha-mbles.github.io

31–40 of 369 posts

Re: The first chosen-prefix collision for SHA-1

#31
post #23

Earlier quoted context omitted.

Further details as to why Torvalds is not concerned: From the email... "I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header." [...] "I haven't seen the attack detail…

That first quote is misleading. git's special hashing scheme doesn't make the attack "much harder". First there is no difference in length in the original shattered collision already: $ curl https://shattered.io/static/shattered-1.pdf | wc -c 422435 $ curl -s https://shattered.io/static/shattered-2.pdf | wc -c 422435 Second, the length is already being hashed into the content during computation of a SHA-1 hash. Look…

But even if the lengths are same, the resulting SHA1 will be different since you prefix the length before hashing

Re: The first chosen-prefix collision for SHA-1

#32
post #29

> By renting a GPU cluster online, the entire chosen-prefix collision attack on SHA-1 costed us about 75k USD. So they just decided to try their attack and spend two years worth of salary on it?? That's crazy.

You can see their emails at the bottom: those are universities/research institutes domains. You can be sure _they_ did not actually spend that themselves.

I'm just amazed that they were willing to take the risk that there was a bug in the code and they wouldn't find a collision.

Re: The first chosen-prefix collision for SHA-1

#33

Earlier quoted context omitted.

That's dirt cheap for a government actor, and we can be sure that the big governments have been doing this sort of attack for years.

It's a lot of money for an academic researcher.

Researchers in applied fields other than CS spend this kind of money on a regular basis. eg. https://www.quora.com/What-are-the-costs-for-lab-rat-testing...

Re: The first chosen-prefix collision for SHA-1

#34
post #23

Earlier quoted context omitted.

Further details as to why Torvalds is not concerned: From the email... "I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header." [...] "I haven't seen the attack detail…

That first quote is misleading. git's special hashing scheme doesn't make the attack "much harder". First there is no difference in length in the original shattered collision already: $ curl https://shattered.io/static/shattered-1.pdf | wc -c 422435 $ curl -s https://shattered.io/static/shattered-2.pdf | wc -c 422435 Second, the length is already being hashed into the content during computation of a SHA-1 hash. Look…

Yeah, that quote doesn't exactly make me confident about Linus's understanding of this particular issue.

Re: The first chosen-prefix collision for SHA-1

#35
post #23

Earlier quoted context omitted.

Further details as to why Torvalds is not concerned: From the email... "I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header." [...] "I haven't seen the attack detail…

That first quote is misleading. git's special hashing scheme doesn't make the attack "much harder". First there is no difference in length in the original shattered collision already: $ curl https://shattered.io/static/shattered-1.pdf | wc -c 422435 $ curl -s https://shattered.io/static/shattered-2.pdf | wc -c 422435 Second, the length is already being hashed into the content during computation of a SHA-1 hash. Look…

The point is that the hashed data must follow a specific data format, and can’t just be arbitrary data. This means that the collision data MUST contain the length at some specific offset in the data, which makes it harder to find a collision.

The more restrictive the serialization format of the hashed data, the harder it is to find a collision that’s valid in the given application context.

Re: The first chosen-prefix collision for SHA-1

#37
post #14
post #7

Quick question about the "What should I do" section. It says " use instead SHA-256 ". Isn't SHA-512 both better and faster on modern hardware?

Depends on your definition of 'better'. Theoretically SHA-512 is harder to brute force than SHA-256, but 256 bits is already extremely strong, so really there is no practical safety benefit of SHA-512 over SHA-256. On 64-bit capable processors SHA-512 has a slight performance gain over SHA-256, but only on larger inputs. However, the digest of SHA-512 is twice the size, so what you gain in processing time, you loose…

You can truncate the SHA-512 digest down to 256 bits though. Cryptographic hash functions mix well and don't suffer from the truncation (except to the extent that the truncated digest is shorter, of course). You don't necessarily need more storage (after hashing completes) just because you're using a new hash function.

Re: The first chosen-prefix collision for SHA-1

#39
post #24
post #20

Is "a Shambles" British or something? I've always heard it as "in Shambles"

AFAICT ”a shambles” is correct usage. See https://brians.wsu.edu/2016/05/24/in-shambles-a-shambles/

Neat, but don't know if I can switch because of how it rolls off the tongue.

Re: The first chosen-prefix collision for SHA-1

#40
post #24
post #20

Is "a Shambles" British or something? I've always heard it as "in Shambles"

AFAICT ”a shambles” is correct usage. See https://brians.wsu.edu/2016/05/24/in-shambles-a-shambles/

Downvoted. There's no ISO standard for English, since language is a social phenomenon. "Correct" language is whatever the community of speakers uses in practice, not what someone claims is correct in a blog post (or even a book).
Post reply on HN