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

301–310 of 369 posts

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

#301

Post by joeyh »

jlokier wrote: post #124
rst wrote: post #118

Earlier quoted context omitted.

Well, according to that reference, it's hardened against a specific, previously known attack. Do you have any information on whether that also protects against the different, new attack which was just published?

I was wondering the same thing, and hoping someone else would answer that.

Hardened sha1 does detect this new attack. Easy to test: Check their pair of files into a git repo and see that they have different checksums, while sha1sum(1) generates the same for both.

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

#302

Post by edwintorok »

> security level 2 (defined as 112-bit security) in the latest release (Debian Buster); this already prevents dangerous usage of SHA-1

FWIW this doesn't apply to Fedora currently, because it has a patch that re-enables SHA-1 in security level 2 in non-FIPS mode: https://src.fedoraproject.org/rpms/openssl/blob/master/f/ope...

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

#303

Post by andrewstuart2 »

sofaofthedamned wrote: post #293
ThePowerOfFuet wrote: post #288

Earlier quoted context omitted.

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.

Don't make cancer anything it's not, either. Cancer is just growth of abnormal cells, unconstrained, to the point that it causes harm to the host.

That said, maybe AMP is more like a virus. A non-living organism that spreads by infecting living organisms and repurposing them to replicate itself instead of sustaining the organism they were a part of.

The more sites adopt AMP, the more everyone else says "well I guess we have to now." Seems pretty viral.

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

#304

Post by moyix »

WorldMaker wrote: post #279
CobrastanJorji wrote: post #205

Earlier quoted context omitted.

The point about archeologists is a good one because it speaks to motive. In general, we should be very supportive of the efforts of distant historians who want to understand what humanity used to be like. We should not WANT to hide secrets from a sufficiently far future. I can't think of any secret that deserves to be hidden from them for any reason besides perhaps modesty.

Relatedly, that is a part of why I love the term "cryptoarcheology" in general, as a reminder that digital spaces will need archeologists too. There's it's somewhat shortened form "cryptarch", generally more used as a title ("cryptoarcheologist"), which was used in places in the Quantum Thief trilogy of books and is most probably already burned into your brain if you have played any of the Destiny series of videogame…

Hmm, I thought cryptarch was just crypt + arch with the arch part meaning “leader” (i.e. this sense https://www.etymonline.com/word/arch-), not archaeologist. Is there something about this in the Quantum Thief trilogy I’ve forgotten?

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

#305

Post by dickjocke »

nneonneo wrote: post #297
dickjocke wrote: post #294

Earlier quoted context omitted.

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…

thank you OP and everyone. I have that shaky initial understanding but makes much more sense.

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

#306

Post by wbl »

rakoo wrote: post #223
baddox wrote: post #198

Earlier quoted context omitted.

> Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text. When has that happened? Public key cryptography and symmetric key cryptography are still doing fine as far as I'm aware, and the latter doesn't even seem to be vulnerable to quantum computing. Moreover, SHA-1 has been considered insecure for, what, at least 10 years? The fact that a cryptographic ha…

"Public/symmetric key cryptography" is just the name of the practice, of course it's doing fine. What's not doing fine is picking a particular set of ciphers/hash functions/signature scheme and expecting to not fail in 40 years.

Triple DES remains as secure today as in 1975.

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

#307

Post by dickjocke »

air7 wrote: post #298
dickjocke wrote: post #294

Earlier quoted context omitted.

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.

that makes a lot more sense, thank you

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

#308

Post by wbl »

magicalhippo wrote: post #178
est31 wrote: post #61

Earlier quoted context omitted.

> It's not about it being the same length, but the length of the data being part of the hashed data As I tried to point out, the length is already part of what the SHA-1 function hashes: https://tools.ietf.org/html/rfc3174#section-4 As a summary, a "1" followed by m "0"s followed by a 64- bit integer are appended to the end of the message to produce a padded message of length 512 * n. The 64-bit integer is the length…

> But it doesn't make mounting a novel shattered attack "much harder" as Linus claims. From what I understood the core of Linus' argument[1] is that it's very hard to make a "bad" variant of the code which has the same length _and_ the same hash while still looking like sane code. For random data files, sure those are more at risk. [1]: https://marc.info/?l=git&m=148787287624049&w=2

A good thing no one checks binary assets into source control

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

#309

Post by gowld »

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…

> you'd need to convince a signing authority to sign the code.

Not necessarily. You can also self-sign or just announce the hash, let the public inspect and test your good driver for a year, and then ship the bad driver to people who only check the hash

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

#310

Post by gowld »

nneonneo wrote: post #284
RickHull wrote: post #275

Earlier quoted context omitted.

Actually, the website does cover this in the '''Q&A''' section: > What is a chosen-prefix collision? > A classical collision (or identical-prefix collision) for a hash function H is simply two messages M and M’ that lead to the same hash output: H(M) = H(M’). Even though this security notion is fundamental in cryptography, exploiting a classical collision for attacks in practice is difficult. > A chosen-prefix collis…

The confusing thing is that the team behind SHAttered did choose a prefix - they just had to choose a common prefix rather than two different prefixes (choosing a common prefix simply changes the initial state used by SHA-1). So I'm hoping that my post clarifies this point a bit. The SHAttered attack (classical collision) can be used in practice - for example, my project https://github.com/nneonneo/sha1collider explo…

Is any practical application safe from Shattered but not Shambles?
Post reply on HN