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

141–150 of 369 posts

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

#141

Post by kemitche »

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…

It depends on how the deduplication is configured, and the risk tolerance of the organization running it, I suppose.

ZFS, for example, has a dedup setting option that forces the file system to do a byte-for-byte verification for any deduped data: https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/g...

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

#142

Post by tptacek »

fireflash38 wrote: post #62
CiPHPerCoder wrote: post #15

Earlier quoted context omitted.

SHA-256 and SHA-512 are both in the same family (SHA-2). Latacora says to use SHA-2. If you can get away with it, SHA-512/256 instead of SHA-256. But they're all SHA-2 family hash functions. https://latacora.micro.blog/2018/04/03/cryptographic-right-a... No need to bikeshed this. But if you must: SHA-512/256 > SHA-384 > SHA-512 = SHA-256 If you're wondering, "Why is SHA-384 better than SHA-512 and SHA-256?" the answe…

I read the blog, but it doesn't really expand on why SHA224/384 aren't vulnerable to that attack, can you explain (or link to some place that does?)

A length-extension attack works by taking the output of a hash and using it as the starting point for a new hash; you can do this even for hashes of messages you haven't seen, minting new related hashes. Truncated SHA-2 hashes don't output the whole hash, and so you aren't given enough information to start a new related hash.

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

#143

Post by suixo »

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…

Last part of this comment made me laugh, trying to imagine someone shouting over Slack "PATCH YOUR BRIDGE, NOW!!"

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

#144

Post by saalweachter »

flatiron wrote: post #135
FactolSarin wrote: post #121

Earlier quoted context omitted.

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"M6 and 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…

Isn't that like incredibly simple?

Dump your garbage string behind a // or inside an #if 0, restrict the garbage string character set to characters which will not disturb that, and your compiler will whistle while it works.

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

#145

Post by dward »

bjornsing wrote: post #43

> We note that classical collisions and chosen-prefix collisions do not threaten all usages of SHA-1. In particular, HMAC-SHA-1 seems relatively safe, and preimage resistance (aka ability to invert the hash function) of SHA-1 remains unbroken as of today. Nice to see this bit of intellectual honesty. Would be even nicer if they had explained what that means in terms of PGP keys.

HMACs do not require collision resistance from the underlying hash to provide secure message authentication. HMAC-MD5 is still considered "secure", although that doesn't mean you should use it.

http://cseweb.ucsd.edu/~mihir/papers/hmac-new.pdf

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

#146

Post by umvi »

OGWhales wrote: post #39
cpach wrote: post #24

Earlier quoted context omitted.

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.

It got easier for me once I learned that "shambles" is a noun that is a synonym of "slaughterhouse". Once I learned that, I emphasized shambles slightly differently as I rolled the phrase off my tongue.

"SHA-1 is a slaughterhouse"

"SHA-1 is a shambles"

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

#147

Post by femto113 »

While a meaningful accomplishment, suggesting the algorithm is in a "shambles" seems hyperbolic to me. For one thing there's a non-trivial practical leap between formulating two colliding identities and forging an existing one, and for another this was only modestly better than a pure brute force attack. If anything I'm somewhat reassured by the idea that it still costs $40,000+ of GPU time to pull something like this off while doing the same with MD5 is feasible on a mobile phone.

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

#148

Post by jbverschoor »

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…

Yep, I'm afraid of that. I have no idea how they are mitigating this, and I doubt they'll ever disclose.

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

#149

Post by upofadown »

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…

SHA1 isn't broken for hashes.

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

#150

Post by [deleted] »

MichaelMoser123 wrote: post #138
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.

[deleted]
Post reply on HN