Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The first chosen-prefix collision for SHA-1

sha-mbles.github.io

Post reply on HN
Print view View original

131–140 of 369 posts

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

#131

Post by CiPHPerCoder »

Ajedi32 wrote: post #117
timdumol wrote: post #71

Earlier quoted context omitted.

You're probably confused by "SHA-512/256", which does not mean SHA-512 or 256, but rather a truncated version of SHA-512: https://en.wikipedia.org/wiki/SHA-2 in the third paragraph.

So why would a truncated version of SHA-512 be better than SHA-512? And why is SHA-512 = SHA-256?

Truncated hash functions are not vulnerable to length-extension attacks.

Length-extension attacks are relevant when you design a MAC by passing a secret and then a message to a hash function, where only the message is known.

Truncating the hash (which is what SHA-512/256 and SHA-384 do to SHA-512) removes the ability to grab an existing hash H(k || m) (where k is unknown and m might be known) and append junk because a truncated hash does not contain sufficient information to recover the full state of the hash function in order to append new blocks.

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

#132

Post by colanderman »

timdumol wrote: post #71
colanderman wrote: post #69

Earlier quoted context omitted.

I'm super confused. Are SHA-256 and SHA256 different , and if so, why in the world would this be considered a sane naming scheme? If not, I completely do not understand the inequation you wrote, which seemingly lists SHA-256 (and -512) multiple times.

You're probably confused by "SHA-512/256", which does not mean SHA-512 or 256, but rather a truncated version of SHA-512: https://en.wikipedia.org/wiki/SHA-2 in the third paragraph.

Ah! Makes sense now, thanks.

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

#133

Post by newscracker »

General questions:

(edit: these are indeed general questions, not just about SHA1)

Has anyone else been worried about data deduplication done by storage and/or backup systems, considering that they usually use hashes to detect data blocks that are "the same" (without additional metadata) and avoid storing those "duplicate data blocks" again? Doesn't this seem far worse when you also consider that systems like Dropbox deduplicate data across all their users (expanding the footprint for collisions)? Are there any research papers/articles/investigations about this?

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

#134

Post by tptacek »

nvartolomei wrote: post #130

I assume there was a lot of work (read money) put in those collision attacks rather than it being discovered by accident. I'm wondering who is sponsoring this work and for what purpose? The argument about proving that an algorithm is broken and working on better cryptography wouldn't suffice in this case, as issues were shown before that. Here the purpose was to make the attack cheaper?

That is not how cryptographic research works, at all.

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

#135

Post by flatiron »

FactolSarin wrote: post #121
jlokier wrote: post #102

Just a curiosity, since people are talking about Git still using SHA-1 (despite work on SHA-256 since 2017). I see that Git doesn't actually use SHA-1 any more, it uses "hardened SHA-1": https://stackoverflow.com/questions/10434326/hash-collision-...

How would an attack on a git repo work? You create a repo with identical hashes but different content and next time the user clones from scratch they get your modified version?

yeah my thoughts about git are similar. look at the two messages they have an an example:

Key is part of a collision! It's a trap!yE'NsbK#ދW]{1gKmCx's/vr| -pJO_,1$)uB1qXv#U)9ESU;p~0G:Y ݕbBIjFra눰3&t'lB_!h5M([,˴QMK#|o5pv|i,+yYpݍD7_Rf\'GUZ,ϵdvAYAugV=Lk8_E 2 +nolBtxXoQt&+?Y3LP:'Qt(,ۛuԪWJm:A"M6and

Practical SHA-1 chosen-prefix collision!'lka}vbI3,·W]Ǟ+gK}Cxs/v&r| }-hRJO_ rO̳;bzC ,1&uRP-MXrU3aO;pr0:sY'2 l&r7#(A{oNyCJ_W,8 əbحBYީpFr2a8#&t+n_15q(_,ˤQMW#hzYMgVV=L,kO0E*N +oc@BpXoᯖd&?+?[{3LвP&'U t ( WJÏm\:A"6>>|SB(k;Vv̨ޠ^A=Y ;om%j-|cUAAۜEТ&@o@:La3psH^eXf0QJm ݶd

they have the same sha1sum, but in all practicality its nonsense since both messages are pure trash. you couldn't have malicious C code that would have the same hash as non malicious C code in this example

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

#136

Post by hannob »

tambourine_man wrote: post #76

This kind of thing always brings me down a bit. It's not rational, but it does. I mean I truly admire these folks skills, the math involved is obviously remarkable. But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text. It's not security only, nothing seems to work in t…

> Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text.

That is an absurd statement. Every backup you encrypted 10 years ago with then up-to-date security is still well encrypted. The SHA1-thing came coming over a timespan of 15 years. It still doesn't threaten past usage, only active attacks are really relevant.

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

#137

Post by umvi »

kps wrote: post #92
School-Cotton wrote: post #68

Earlier quoted context omitted.

"a shambles" is not used (or quite rarely used) in North America, in my experience. Which was what the OP was asking about. You are of course right that "a shambles" is perfectly fine British English, but that's beside the point.

I'm in North America and have never heard ‘in shambles’, without ‘a’. If I did, I'd probably take it as uneducated sociolect.

Fascinating. I'm guessing it's a regional thing where certain parts of the US say "in shambles" vs. "a shambles" vs. "in a shambles".

Not sure how it would be measured, but I think a /r/dataisbeautiful map would be interesting to see.

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

#138

Post by MichaelMoser123 »

newscracker wrote: post #133

General questions: (edit: these are indeed general questions, not just about SHA1) Has anyone else been worried about data deduplication done by storage and/or backup systems, considering that they usually use hashes to detect data blocks that are "the same" (without additional metadata) and avoid storing those "duplicate data blocks" again? Doesn't this seem far worse when you also consider that systems like Dropbox…

are there any systems that do sha-1 for dedup? I am only aware of sha-256.

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

#139

Post by hannob »

mehrdadn wrote: post #84

> SHA-1 has been broken for 15 years, so there is no good reason to use this hash function in modern security software. Why are cryptographers always exaggerating things and so out of touch with reality? The first actual collision was like 3 years ago. It's not like the world has been on fire in the meantime, and it's not like SHA-1 is broken for every single possible usage even now. And why the nonsense with "no goo…

Performance is the worst argument you could choose.

a) There's hardly an application where hash-performance matters. These things are fast.

b) For precisely that reason that people may still complain about performance cryptographers invented a hash function that is faster than all the old choices like md5/sha1 and still secure (it's called blake2).

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

#140

Post by thenewnewguy »

FactolSarin wrote: post #121
jlokier wrote: post #102

Just a curiosity, since people are talking about Git still using SHA-1 (despite work on SHA-256 since 2017). I see that Git doesn't actually use SHA-1 any more, it uses "hardened SHA-1": https://stackoverflow.com/questions/10434326/hash-collision-...

How would an attack on a git repo work? You create a repo with identical hashes but different content and next time the user clones from scratch they get your modified version?

You'd probably be most successful modifying the original repo - either by being the creator of the software or gaining their trust. However, it would have to be a rather powerful SHA1 attack for the commit to still be valid syntax, hard to detect, and make a meaningful malicious change.
Post reply on HN