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."
The first chosen-prefix collision for SHA-1
351–360 of 369 posts
Re: The first chosen-prefix collision for SHA-1
#352Earlier 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... 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
#353Earlier 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
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
#354> Responsible Disclosure We have tried to contact the authors of affected software before announcing this attack, but due to limited resources, we could not notify everyone. Is there a list of affected software out there?
Re: The first chosen-prefix collision for SHA-1
#355Earlier 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.
Re: The first chosen-prefix collision for SHA-1
#356Earlier 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?
https://link.springer.com/chapter/10.1007/978-3-540-28628-8_...
Re: The first chosen-prefix collision for SHA-1
#357Earlier 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.
Re: The first chosen-prefix collision for SHA-1
#358Re: The first chosen-prefix collision for SHA-1
#359Re: The first chosen-prefix collision for SHA-1
#360Earlier 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