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

A SHA-1 chosen-prefix collision attack

zdnet.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: A SHA-1 chosen-prefix collision attack

#31

Post by a1a »

evv wrote: post #26

Can collision attacks provide the same size of data? I suspect it would be dramatically more difficult to produce a collision of equal data-size as the original. So perhaps, the easiest way to defend against a collision attack is to transmit the size of the data alongside the checksum. Like a checksum, it is extremely lightweight and easy to check. In my data framework project (where I use sha1 to identify blocks), I…

Yes, if I interpret your suggestion correctly. How would you know that the attacker have not manipulated the size parameter?

That's the best case. Worst case you end up with a memory vulernability (see heartbleed https://xkcd.com/1354/)

Re: A SHA-1 chosen-prefix collision attack

#32

Post by avar »

pslam wrote: post #11
arkadiyt wrote: post #9

Their attacks are based on previous chosen-prefix work from Marc Stevens, who tweeted this about the attack [1]: "Their $100K figure is based on as-of-yet undisclosed improvements. History shows many claims of low-cost SHA-1 attacks that have not stood up to peer review. I am very sceptical that their attack costs in total less than the $110K building block (SHAttered) that they use." [1]: https://twitter.com/realhas…

Marc Stevens quotes $500K, which is very much still a threat (even an order of magnitude more would be). Plenty of organizations would be willing to spend that much pocket change on a single attack. The game-changer is it's chosen-prefix. A vendor can produce a pair of entirely different binaries with the same hash, but most importantly, they look and behave sane except for the last few blocks of the file. This is ea…

> SHAtter was waived by many because the threat model didn't convincingly apply to them. Example: git.

Git quickly switched to the sha1collisiondetection library[1] by default after the SHAttered attack was published. It's a SHA-1 library written by the authors of the paper which the attack.

Edit: Marc Stevens saying that existing library will mitigate this new attack: https://twitter.com/realhashbreaker/status/11284190295369236...

1. https://github.com/cr-marcstevens/sha1collisiondetection

Re: A SHA-1 chosen-prefix collision attack

#33

Post by orblivion »

evv wrote: post #26

Can collision attacks provide the same size of data? I suspect it would be dramatically more difficult to produce a collision of equal data-size as the original. So perhaps, the easiest way to defend against a collision attack is to transmit the size of the data alongside the checksum. Like a checksum, it is extremely lightweight and easy to check. In my data framework project (where I use sha1 to identify blocks), I…

For what it's worth, Shattered specifically altered a small part of an existing file. Perhaps with chosen-prefix the story is different.

https://shattered.io (check out the two pdfs)

Re: A SHA-1 chosen-prefix collision attack

#34

Post by AnaniasAnanas »

avar wrote: post #32
pslam wrote: post #11

Earlier quoted context omitted.

Marc Stevens quotes $500K, which is very much still a threat (even an order of magnitude more would be). Plenty of organizations would be willing to spend that much pocket change on a single attack. The game-changer is it's chosen-prefix. A vendor can produce a pair of entirely different binaries with the same hash, but most importantly, they look and behave sane except for the last few blocks of the file. This is ea…

> SHAtter was waived by many because the threat model didn't convincingly apply to them. Example: git. Git quickly switched to the sha1collisiondetection library[1] by default after the SHAttered attack was published. It's a SHA-1 library written by the authors of the paper which the attack. Edit: Marc Stevens saying that existing library will mitigate this new attack: https://twitter.com/realhashbreaker/status/11284…

That still does not solve the issue with OpenPGP signatures though, does it?

Re: A SHA-1 chosen-prefix collision attack

#35

Post by avar »

pslam wrote: post #28
gnomewascool wrote: post #23

Earlier quoted context omitted.

Git signatures are designed for cryptographic security, and they (currently) rely on the SHA-1 hashes. When you're signing a commit (or a tag) you're just signing the commit (or tag) message which includes the SHA-1 hash of the relevant "root" tree object (or commit object). The tree object, in turn is (in effect) a list of SHA-1 hashes of the files directly in the directory, along with their file sizes and permissio…

An easy example with git would be to create a pair of read-only repositories: one public-facing which is cloned by the general public, and one with (potentially entirely) different contents which can be selectively pulled depending on the client. There's a complication with the few appended trailing blocks being invalid data, but the format might allow it, and git doesn't verify its integrity recursively.

> git doesn't verify its integrity recursively

Yes it does. On clone the entire history is recursively hashed, and incrementally on fetch.

There isn't even any place in the protocol to transfer pre-hashed content, it must be hashed to make it addressable.

Re: A SHA-1 chosen-prefix collision attack

#36

Post by avar »

AnaniasAnanas wrote: post #34
avar wrote: post #32

Earlier quoted context omitted.

> SHAtter was waived by many because the threat model didn't convincingly apply to them. Example: git. Git quickly switched to the sha1collisiondetection library[1] by default after the SHAttered attack was published. It's a SHA-1 library written by the authors of the paper which the attack. Edit: Marc Stevens saying that existing library will mitigate this new attack: https://twitter.com/realhashbreaker/status/11284…

That still does not solve the issue with OpenPGP signatures though, does it?

It does, because a tag pointing to the malicious content wouldn't hash with sha1collisiondetection's modified SHA-1, just like you can't add the SHAttered PDFs to git.

Re: A SHA-1 chosen-prefix collision attack

#37

Post by eternalban »

blurbleblurble wrote: post #13

Last night I was pondering about future "compression" schemes that relied on hyper-powerful quantum computers that can resolve hash collisions very, very quickly, so that rather than literally compressing the data, you'd just share a hash and then this hyper-powerful computer will enumerate possible strings of data that give that hash, and then check them against some secondary condition (another hash?) to find the r…

It may turn out that finding those additional 'hint' bits ("another hash") that dramatically reduce the search space of your computer for a given input is NP hard.

Re: A SHA-1 chosen-prefix collision attack

#38

Post by aeneasmackenzie »

CiPHPerCoder wrote: post #5
ChrisSD wrote: post #3

It must be about time for SHA-4.

Nope. SHA-2 (known to developers as SHA224, SHA256, SHA384, and SHA512) was the replacement for SHA-1. SHA-3 was created as an insurance policy in case the SHA-2 family was broken too. So far, it hasn't been. We won't need a SHA-4 any time soon. SHA-2 is fine, BLAKE2 is fine (and faster), SHA-3 is fine.

Is there any reason not to just use SHA-3? It sounds like it's a real swiss army knife to hear the authors talk about it.

Re: A SHA-1 chosen-prefix collision attack

#39

Post by mehrdadn »

anderskaseorg wrote: post #29

“Everyone should switch to (in order of preference): • BLAKE2b / BLAKE2s • SHA-512/256 • …” You know, SHA-512/256 was a terrible name. For someone who’s not a cryptographer, it’s way too easy to confuse the single algorithm SHA-512/256, which resists length extension attacks, with the pair of algorithms SHA-512 / SHA-256, which do not.

Damn, I knew this and I'd forgotten it. Thanks for pointing it out.

Re: A SHA-1 chosen-prefix collision attack

#40

Post by mehrdadn »

optimiz3 wrote: post #8
CiPHPerCoder wrote: post #5

Earlier quoted context omitted.

Nope. SHA-2 (known to developers as SHA224, SHA256, SHA384, and SHA512) was the replacement for SHA-1. SHA-3 was created as an insurance policy in case the SHA-2 family was broken too. So far, it hasn't been. We won't need a SHA-4 any time soon. SHA-2 is fine, BLAKE2 is fine (and faster), SHA-3 is fine.

Also, SHA-2 underpins Bitcoin; it's the ultimate billion dollar pot of gold. SHA-2 is perhaps the most exhaustively researched (both publicly and privately) cryptographic hash because of this.

Do you know why it's said to be last-resort in the article?
Post reply on HN