Live data from Hacker News

The first chosen-prefix collision for SHA-1

sha-mbles.github.io

351–360 of 369 posts

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

#351

Earlier quoted context omitted.

I wonder what the intended meaning is. I presume it has to do with a presumed eventual urge to confess.

In context, it appears to be saying "you can't keep secrets from God."

Ok but it implies/states that the secrets will be broadly divulged.

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

#352

Earlier quoted context omitted.

The internet brings a much bigger attack surface than local people who can reach a front door, and home users access the same openssh as companies do, but companies (can) afford stronger doors. "Most people's home doors can't withstand a hit from a sledgehammer" -> "we shouldn't talk about cryptographic weaknesses in case someone abuses them" is a stretch, the comparison does break down. [1] is a fun YouTube video ab…

"The internet brings a much bigger attack surface than local people who can reach a front door" "Local people", huh. My front door is visible to everyone on the internet, and I have no practical way to prevent that. Some obscure company went by with their mapping vehicle and... Now, some people do live in big buildings where less is exposed to the outside, but millions don't.

> and...

and... what? Unless telekinesis has been invented, a photo of your door doesn't increase the amount of people who are able to try opening your door. If you're about to say "someone might choose to come a long way just for my door" then that seems like an argument in favour of what I'm saying - in that case, wouldn't you like to know about any vulnerabilities your door has which you could address, before they arrived, instead of relying on silence and hoping they won't know about them?

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

#353
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

> it's very hard to make a "bad" variant of the code [...] looking like sane code

That is very hard, but not what was quoted above. The length has no part in it. The core part needed for the shattered collision attacks involves basically binary data.

    $ curl -s https://shattered.io/static/shattered-1.pdf | hexdump -C > s1
    $ curl -s https://shattered.io/static/shattered-2.pdf | hexdump -C > s2
    $ diff s1 s2
    13,20c13,20
     000000c0  7f 46 dc 93 a6 b6 7e 01  3b 02 9a aa 1d b2 56 0b  |.F....~.;.....V.|
    > 000000d0  45 ca 67 d6 88 c7 f8 4b  8c 4c 79 1f e0 2b 3d f6  |E.g....K.Ly..+=.|
    > 000000e0  14 f8 6d b1 69 09 01 c5  6b 45 c1 53 0a fe df b7  |..m.i...kE.S....|
    > 000000f0  60 38 e9 72 72 2f e7 ad  72 8f 0e 49 04 e0 46 c2  |`8.rr/..r..I..F.|
    > 00000100  30 57 0f e9 d4 13 98 ab  e1 2e f5 bc 94 2b e3 35  |0W...........+.5|
    > 00000110  42 a4 80 2d 98 b5 d7 0f  2a 33 2e c3 7f ac 35 14  |B..-....*3....5.|
    > 00000120  e7 4d dc 0f 2c c1 a8 74  cd 0c 78 30 5a 21 56 64  |.M..,..t..x0Z!Vd|
    > 00000130  61 30 97 89 60 6b d0 bf  3f 98 cd a8 04 46 29 a1  |a0..`k..?....F).|
An ASCII formatted file only has text data. Also, with the shattered attack you can't choose what the two versions should be so you are required to cross reference the different looking binary data to turn on/turn off some functionality. So the attack is mostly interesting when you include binary data. With the chosen prefix attack, you can have two arbitrary components, even textual ones, but they still have to be followed by such a binary component.

Also now git has collision detection code from sha1collisiondetection [1], making attacks even harder.

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

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

#355
post #243

Earlier quoted context omitted.

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

bup does. Even worse: rsync relies on md5 for finding duplicate blocks.

at least rsync does that only when --checksum is specified as option; otherwise it assumes that files with the same date/time/size are the same (which is probably not too bad as a default).

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

#356
post #241

Earlier quoted context omitted.

Concatenating two hashes is an algorithm. Mathematically concatenating two 128 bit hashes is not any stronger than a single 256 bit hash (and is likely weaker), but if it’s all you have (or all you can afford to compute) two weak hashes is definitely much better than one.

Why is concatenating two 128 bit hashes (each with a different algorithm) not stronger than a single-algorithm 256 bit hash?

Check out this paper:

https://link.springer.com/chapter/10.1007/978-3-540-28628-8_...

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

#357
post #341

Earlier quoted context omitted.

Truncating a hash function to 224 bits put it at the 112-bit security level, which is roughly equivalent to 2048-bit RSA under today's understanding of the costs of distributed cracking attacks. There are a lot of standards organizations all over the world with various recommendations. https://www.keylength.com collates quite a few of them. Pick the one most closely relevant for your jurisdiction. Most of them recomm…

"Cryptographic hash functions with output size of n bits usually have a collision resistance security level n/2 and preimage resistance level n." Depending on what you're doing, "SHA-512/128" could have a 128-bit security level. But I guess it's safer to assume n/2 when making a general recommendation.

[deleted]

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

#359

Earlier quoted context omitted.

> To be excessively pedantic This is the best, most delicious, type of pedantry friend!

You're the best kind of pedantry friend! (Just some more pedantry, friend.)

Ok man, now that's just over the top.

/s

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

#360
post #179

Earlier quoted context omitted.

No, the bridge collapsed because it was never touched again after initial deployment, for 10 years. How are buildings doing in Chernobyl? Don’t neglect your data, if you want to keep it safe always. :P

A counter example are roman aqueducts

Concrete is pretty resilient and even if it cracks it can still hold up quite well but when it does, the rebar gets exposed and starts to oxidize until the building finally crumbles.
Post reply on HN