SHAttering 2 - The second SHAppening

From Collisions to Chosen-Prefix Collisions - Application to Full SHA-1

A chosen-prefix collision attack is a stronger variant of a collision attack, where an arbitrary pair of challenge prefixes are turned into a collision. Chosen-prefix collisions are usually significantly harder to produce than (identical-prefix) collisions, but the practical impact of such an attack is much larger. While many cryptographic constructions rely on collision-resistance for their security proofs, collision attacks are hard to turn into a break of concrete protocols, because the adversary has limited control over the colliding messages. On the other hand, chosen-prefix collisions have been shown to break certificates (by creating a rogue CA) and many internet protocols (TLS, SSH, IPsec).

In this article, we propose new techniques to turn collision attacks into chosen-prefix collision attacks. Our strategy is composed of two phases: first, a birthday search that aims at taking the random chaining variable difference (due to the chosen-prefix model) to a set of pre-defined target differences. Then, using a multi-block approach, carefully analysing the clustering effect, we map this new chaining variable difference to a colliding pair of states using techniques developed for collision attacks.

We apply those techniques to MD5 and SHA1, and obtain improved attacks. In particular, we have a chosen-prefix collision attack against SHA1 with complexity between 266.9
and 269.4 (depending on assumptions about the cost of finding near-collision blocks), while the best-known attack has complexity 277.1. This is within a small factor of the complexity of the classical collision attack on SHA1 (estimated as 264.7). This represents yet another warning that industries and users have to move away from using SHA1 as soon as possible.

eprint.iacr.org/2019/459

Post yfw Bittorent and Git still use SHA1

Other urls found in this thread:

github.com/dstein64/LC4
github.com/skeeto/elsiefour
github.com/Gavin-Song/elsie-four-cipher
github.com/tonetheman/golang_lc4
iacr.org/archive/fse2011/67330244/67330244.pdf
github.com/oconnor663/bao
en.wikipedia.org/wiki/Length_extension_attack
ehash.iaik.tugraz.at/wiki/ECHO
ehash.iaik.tugraz.at/wiki/Blue_Midnight_Wish
eprint.iacr.org/2013/467.pdf
esat.kuleuven.be/cosic/publications/article-2705.pdf
eprint.iacr.org/2015/698.pdf
tosc.iacr.org/index.php/ToSC/article/view/574/516
tosc.iacr.org/index.php/ToSC/article/view/574/7470
pdfs.semanticscholar.org/39d7/76628be96c58e2fc2580ab1a2552b2978b3f.pdf
darkmatter.ae/media/1527/aaraj_caullery_manzano_nisk_2017.pdf
twitter.com/NSFWRedditVideo

its going to break if they change it for torrents. so many run very old clients

IPFS > Torrents
Torrents on suicide watch

Life is like a downloaded torrent. You never know what you're going to get.

Makes you wonder if most of the encryption we use is already broken, or waiting to be broken soon.

no

i dont really trust this new popular thing that is ed25519. a big part of the beginning of the key is always same and i would expect that a secure key has a completely random value

People already know SHA1 is shit as 2004, just that it was not practical to break.
But now, with GPUs, it is possible.
The thing is that AES, Serpent, Twofish, Camellia, SEED and ARIA are all made to be relatively GPU-proof.


Same goes for RSA if you did it wrong.

Considering it's implemented by humans, more than likely.

Aren't files in torrents divided into pieces? Wouldn't that make it impractical to forge files in a torrent, not just due to the fact that you'd have to ensure that all the pieces had the "correct" checksum, but that whatever result you were trying to achieve still worked within the context of the file as a whole, and that other people would be contributing correct pieces. Unless you're just trying to send garbage, I guess.

but whats the checksum.. some attacks could probably work if you could generate a identical hash for another torrent and try to seed it to the swarm

no

Well you've convinced me.

ok

this might be the end of many p2p things. they would have to make a big breaking change to fix this and its unlikely that everyone would update to the new version.

No. eMule worked mostly fine, despite broken hashing.

I can see you, CIA nigger. You glow in the dark theme.

Nah he is just a chink who can't into IPFS lol.

Just Use LC4 as a hash
github.com/dstein64/LC4
github.com/skeeto/elsiefour
github.com/Gavin-Song/elsie-four-cipher
github.com/tonetheman/golang_lc4
t. Anprim Gang

LC4 isn't even cryptographically secure. Fuck off, retard.

there are still people that use it

I don't see how a single torrent is better than torrents.

I call bullshit.

How about this, OP, we use BMW512, that is one of the fastest hashes in the SHA competition that nearly got to the finalist, which is faster than BLAKE2b.

noob here. is globally changing hash algo from SHA1 to lets say SHA256 this fucking problem?

who?
lol
iacr.org/archive/fse2011/67330244/67330244.pdf
BLAKE2bp is also faster than BLAKE2b.
Using BLAKE2s in a parallel tree hashing mode is also faster than BLAKE2bp. github.com/oconnor663/bao
You very seldomly have to go really fast though because you're most of the time limited by IO speed.


Yes. Changing something costs time/money/resources. Why do you thing we are still dealing with UNIX braindamage or Cnility?
en.wikipedia.org/wiki/Length_extension_attack
Just use SHAKE128/SHAKE256.

Well, what exactly are the risks?
As I understand it, hashing the data in Bittorrent is for ensuring the message integrity. Now, can an attacker actually corrupt data in a meaningful way? Like, if we're seeding software, can it be backdoored that way? Or is data corruption everything we got here?

Thanks SHA1!

That's meaningful data corruption you're talking about here.

You might as well use KangarooTwelve if that is the case.
Blue Midnight Wish 512 FTW

Thinking that shit is any better than Skippidy Doo Dah 69 or HoRSEPUSSYn512

Any technological progress we are experiencing now already existed in secret 30 years ago.

iacr.org/archive/fse2011/67330244/67330244.pdf


based


kys

Okay then, ECHO256 from SHA3 competition round 2. Get me a whitepaper on it vs Blue Midnight Wish 512 and BLAKE2b

lol

Okay, compare these
ehash.iaik.tugraz.at/wiki/ECHO (256-bit is 7.4% faster than BLAKE2b)
ehash.iaik.tugraz.at/wiki/Blue_Midnight_Wish (512-bit is 13.2% faster thank BLAKE2b)
to BLAKE2b's cryptanalysis
eprint.iacr.org/2013/467.pdf
esat.kuleuven.be/cosic/publications/article-2705.pdf
(ChaCha is used in BLAKE2)
eprint.iacr.org/2015/698.pdf
tosc.iacr.org/index.php/ToSC/article/view/574/516
tosc.iacr.org/index.php/ToSC/article/view/574/7470
pdfs.semanticscholar.org/39d7/76628be96c58e2fc2580ab1a2552b2978b3f.pdf
darkmatter.ae/media/1527/aaraj_caullery_manzano_nisk_2017.pdf