471–480 of 524 posts
" Today, 10 years after of SHA-1 was first introduced, we are announcing the first practical technique for generating a collision." Huh? It's been around a lot longer than 10 years.
Earlier quoted context omitted.
The writing has been on the wall for a long time, but Linus has been dead against it. > And we should all digitally sign every single object too, and we should use 4096-bit PGP keys and unguessable passphrases that are at least 20 words in length. And we should then build a bunker 5 miles underground, encased in lead, so that somebody cannot flip a few bits with a ray-gun, and make us believe that the sha1's match wh…
At least in the current discussion, Linus says that eventually moving away from SHA1 in Git is a "no brainer," but that this announcement isn't a "sky is falling" moment. (e.g. https://public-inbox.org/git/CA+55aFz98r7NC_3BW_1HU9-0C-HcrF... )
So good timing to have just started working on a sha3 version of git I guess...
Funny, just yesterday I thought about what would be necessary to change and deploy this. Apparently the SHA1 hash wasn't designed as a security feature, but I would not be surprised if it is being abused as one today.
Earlier quoted context omitted.
So if one were hashing data or a document format that also contained a bit of self-referential integrity data, e.g. the end of the data has a CRC of the rest of the block, or maybe a cryptographic signature using some other hash, wouldn't that further constrain the search space? Then not only would one need to back out the random bits needed to complete the SHA-1 collision, it would also have to satisfy a some other…
It's a good thought, but if the functions have bounded-length outputs (as with all major hash functions), then your combined hash value is still a bounded length. A collision must therefore exist because there are many more potential messages than potential hash values. If your functions produce unbounded-length hashes, then you may as well just be compressing your input to guarantee there are no collisions in your "…
Earlier quoted context omitted.
With many image formats, you can just concatenate whatever you want at the end of the file, and the OS and programs will obliviously read and copy the whole file, while the image libraries will happily ignore the extra data.
And then you put PHP tags in that content at the end, and change the .htaccess file to process *.jpeg as PHP scripts, and your webshell looks benign until someone has that in mind looking through the account.
The visual description of the colliding files, at http://shattered.io/static/pdf_format.png , is not very helpful in understanding how they produced the PDFs, so I took apart the PDFs and worked it out. Basically, each PDF contains a single large (421,385-byte) JPG image, followed by a few PDF commands to display the JPG. The collision lives entirely in the JPG data - the PDF format is merely incidental here. Extract…
So if one were hashing data or a document format that also contained a bit of self-referential integrity data, e.g. the end of the data has a CRC of the rest of the block, or maybe a cryptographic signature using some other hash, wouldn't that further constrain the search space? Then not only would one need to back out the random bits needed to complete the SHA-1 collision, it would also have to satisfy a some other…
Of course, it would probably make more sense just to use one of the recommended replacements in the first place, e.g. SHA-256.
Earlier quoted context omitted.
I was a bit surprised to see this because I thought there might be more constraints on it, but I tried adding arbitrary strings to the end of both PDFs and re-hashing, and the hashes continue to be the same after appending arbitrary arbitrary-length strings. I guess this is indeed a consequence of the length-extension attack; we can argue that if -- for this kind of hash -- H(X∥Y) always depends only on H(X), len(X),…
I suspect you would see the same behaviour even with a hash function that is not vulnerable to length extension attacks. My understanding is that protecting against length extension is about hiding the internal state of the cipher in the result hash, for the purposes of protecting a secret in the plaintext. But if the state is the same between each document, and you have access to the whole plaintexts, I don't see wh…
I think there are engineering reasons why this isn't typically the case for the hashes we normally use, but I'm just hypothesizing a way that this could be different.
I wish there were sample documents, but if one had two computed hashes would this mitigate this SHA1-shattered flaw ? e.g. good_doc.pdf sha1=da39a3ee5e6b4b0d3255bfef95601890afd80709, md5=d41d8cd98f00b204e9800998ecf8427e ? With the sample project I'm looking at (GraphicsMagick) on Sourceforge for example, it provides both SHA-1 and MD5 hashes...
host$ sha1 ./Downloads/shattered-*
SHA1 (./Downloads/shattered-1.pdf) = 38762cf7f55934b34d179ae6a4c80cadccbb7f0a
SHA1 (./Downloads/shattered-2.pdf) = 38762cf7f55934b34d179ae6a4c80cadccbb7f0a
host$ md5 ./Downloads/shattered-*
MD5 (./Downloads/shattered-1.pdf) = ee4aa52b139d925f8d8884402b0a750c
MD5 (./Downloads/shattered-2.pdf) = 5bd9d8cabc46041579a311230539b8d1
host$Earlier quoted context omitted.
Edit: Nevermind, I misinterpreted something in the report. Collisions between malicious and non-malicious documents are indeed most likely feasible. Original comment: While theoretically possible, I don't really see that particular attack as being an actual, practical problem anytime soon. In order for that to work not only would you have to find _a_ collision, but you'd have to find one with the additional constrain…
I really don't see why anyone would go through all this trouble when you can still just put Star_Wars_XIII.exe out there and get 10k downloads.