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

291–300 of 369 posts

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

#291

Post by __s »

staticassertion wrote: post #187
espadrine wrote: post #99

Earlier quoted context omitted.

Cryptographers rely on precise definitions to make their assessments. In particular, a primitive makes a number of useful promises. Any achievement that describes a way in which a promise is not kept makes that primitive broken , regardless of whether that achievement is theoretical or practical. (They often talk about “theoretically broken” or “practically broken” to distinguish whether it was actually done.) > it's…

Is SHA1 not still faster than 256/512? And Blake2 barely faster? I suspect with some hardware SHA1 is still going to beat all of those out - am I wrong? I would love to learn more.

CRC is faster than SHA1

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

#292

Post by plopz »

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.

NYC here, never have heard it with an 'a'. Its always just 'in shambles'.

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

#293

Post by sofaofthedamned »

ThePowerOfFuet wrote: post #288
femto113 wrote: post #286

Earlier quoted context omitted.

It’s a step on the same path that led to being able to spoof a CA for MD5 signed certs. https://www.google.com/amp/s/techcrunch.com/2008/12/30/md5-c...

Please don't feed the cancer which is AMP. https://techcrunch.com/2008/12/30/md5-collision-creates-rogu...

Please don't overegg the issue with AMP by comparing it to cancer.

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

#294

Post by dickjocke »

nneonneo wrote: post #287
dickjocke wrote: post #282

Earlier quoted context omitted.

Can you give a specific example of the danger here? I understand the principle behind the attack (kinda). I just don't understand what danger being able to pad two documents to make them collide poses? edit: My guess is that it can be abused to make something that I believe to be library X actually be library Y when I download it from the internet. Lets say I want to download something, and I check the signature prov…

Suppose your system uses SHA-1 hashes for codesigning verification (e.g. to load a system driver). I create an innocent-looking device driver and convince a signing authority to sign it. However, secretly I've created a malicious driver (e.g. a rootkit) which collides with my innocent one. Now, I can load the malicious one on your machine - which the signing authority has never seen - using the signing certificate of…

Hey OP,

im not much of a math guy, I'm getting hung up on this part:

SHA1(P1+C1+X) = SHA1(P2+C2+X) for any X.

The example above seems like SHA1(GOOD_DRIVER) == SHA1(BAD_DRIVER+C2+X) somehow.

How does the C1 and X get appended to the signature of the good driver.

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

#295

Post by cjm42 »

dickjocke wrote: post #294
nneonneo wrote: post #287

Earlier quoted context omitted.

Suppose your system uses SHA-1 hashes for codesigning verification (e.g. to load a system driver). I create an innocent-looking device driver and convince a signing authority to sign it. However, secretly I've created a malicious driver (e.g. a rootkit) which collides with my innocent one. Now, I can load the malicious one on your machine - which the signing authority has never seen - using the signing certificate of…

Hey OP, im not much of a math guy, I'm getting hung up on this part: SHA1(P1+C1+X) = SHA1(P2+C2+X) for any X. The example above seems like SHA1(GOOD_DRIVER) == SHA1(BAD_DRIVER+C2+X) somehow. How does the C1 and X get appended to the signature of the good driver.

The good driver consists of P1+C1+X. That's what gets sent to the signing authority. They verify it doesn't do anything bad and return a signature listing SHA1(P1+C1+X). But that signature is also valid for the malicious driver P2+C2+X.

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

#296

Post by jessaustin »

rakoo wrote: post #226
PeterisP wrote: post #95

Earlier quoted context omitted.

What do you mean by "previously assumed to be unbreakable" ? SHA-1 has been known to be unsafe for a dozen years, we just went from "assumed to be breakable" to "yep, definitely breakable, here's how one exact attack will work".

But backups have existed for more than a dozen years. And its replacements today, SHA-256 and SHA-3 will also be broken if you wait long enough.

I can see why backups might be needed for a dozen years, and I can see why encrypted backups might be needed, but outside plainly fake requirements like those of "national security" why would encrypted backups be needed for a dozen years? Aren't we throwing everything sensitive away after seven years? After that isn't it mostly about preserving history? Even things like balance sheets that might be sensitive today will be too out-of-date to be sensitive a dozen years from now.

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

#297

Post by nneonneo »

dickjocke wrote: post #294
nneonneo wrote: post #287

Earlier quoted context omitted.

Suppose your system uses SHA-1 hashes for codesigning verification (e.g. to load a system driver). I create an innocent-looking device driver and convince a signing authority to sign it. However, secretly I've created a malicious driver (e.g. a rootkit) which collides with my innocent one. Now, I can load the malicious one on your machine - which the signing authority has never seen - using the signing certificate of…

Hey OP, im not much of a math guy, I'm getting hung up on this part: SHA1(P1+C1+X) = SHA1(P2+C2+X) for any X. The example above seems like SHA1(GOOD_DRIVER) == SHA1(BAD_DRIVER+C2+X) somehow. How does the C1 and X get appended to the signature of the good driver.

Most executable file formats (including drivers) put the code first followed by the data. So you could construct your drivers thusly:

GOOD_DRIVER = P1 (good code and some data) + C1 (data) + X (more data)

BAD_DRIVER = P2 (bad code and some data) + C2 (data) + X (more data)

You'd disguise the random-looking block of C1 data in the middle of the good driver as e.g. a cryptographic key to avoid suspicion. The "more data" part couldn't be modified in the bad driver, but since you can arbitrarily modify P2 this wouldn't be a severe restriction.

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

#298

Post by air7 »

dickjocke wrote: post #294
nneonneo wrote: post #287

Earlier quoted context omitted.

Suppose your system uses SHA-1 hashes for codesigning verification (e.g. to load a system driver). I create an innocent-looking device driver and convince a signing authority to sign it. However, secretly I've created a malicious driver (e.g. a rootkit) which collides with my innocent one. Now, I can load the malicious one on your machine - which the signing authority has never seen - using the signing certificate of…

Hey OP, im not much of a math guy, I'm getting hung up on this part: SHA1(P1+C1+X) = SHA1(P2+C2+X) for any X. The example above seems like SHA1(GOOD_DRIVER) == SHA1(BAD_DRIVER+C2+X) somehow. How does the C1 and X get appended to the signature of the good driver.

He said "innocent-looking device driver".

The good driver is actually padded so that it can be later replaced with the bad driver. I.E This doesn't allow the attacker to replace any driver, but only one they prepared in advance to look innocent but have the right structure.

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

#299

Post by jVinc »

racingmars wrote: post #264
jVinc wrote: post #262

So how would someone go about gaining more than 45k USD in profit from a single case of using the chosen-prefix collision? Not being candid here, I am honestly curious here. I'd guess that even in situations where you somehow get a signed e-mail sent off spoofing a CEO saying "Please pay these guys 50k$" the actual payout seems unlikely and that puts the attacker 45k in the red. But maybe there are some obvious avenu…

I'm familiar with an organization that lost about $750,000 because someone spoofed an email from the CEO to the CFO asking to wire money to an account. The CFO fell for it. AFAIK, the money was never recovered (nor was the CFO fired... it was all just chalked up to 'the cost of doing business'). That was with NO crypto/signature spoofing involved... if the CFO has now been trained to not act on large dollar amount re…

$750,000 is a lot of money, but seeing as some people will act on emails without signature, and that you would effectively have to invest that amount up front in order to attempt this attack on 15 individuals, and then hope that at least one falls for it just to make it even, I can't really see this being a viable attack vector. Maybe if the cost goes down significantly to the $100-$1000 range it might be something you would see in the wild.

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

#300

Post by jessaustin »

gist wrote: post #234
SAI_Peregrinus wrote: post #214

Earlier quoted context omitted.

We typically assume that organizations like the NSA, FSB, Mossad, MSS, and the like already know of such attacks.

The percentage of people that are impacted by NSA et al is exceedingly small compared to the pain and impact on everyday citizens and companies by disclosures. Not all disclosures and for sure an upside but it's out of control and has been for a long time. The government (in the US) does not have the resources to go after everyone who commits a crime and that would assume they are actually scooping up info and know o…

The government (in the US) does not have the resources to go after everyone...

In point of fact, since Snowden's revelations we know not only that the USA state actually does have the resources to monitor everyone, but also that it does so. Furthermore, the state is not a monolith. While it may not be in the interest of the state as a whole to capriciously victimize individual humans, it is often in the interest of particular officers and organizations that comprise the state to do so. Cf. "parallel construction".

Post reply on HN