511–520 of 524 posts
Earlier quoted context omitted.
Thanks! What tools did you use to analyse the JPEG?
I used Hachoir ( https://github.com/haypo/hachoir3 ), a Python library that I've contributed to. Hachoir disassembles files using a library of parsers, with the intent of describing the function of every single bit in the file. You can see the resulting disassemblies (rendered with the hachoir-wx GUI) here: http://imgur.com/a/F1cnV
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…
> The best thing would be if one could prove a mathmatically incompatible set of counter functions where data colliding in the hash of one function would prevent the other function from validating correctly. I'm a rank amateur, so this is completely outside of my wheelhouse, but this sounds suspect. I don't think you can make hash collision impossible, even with multiple functions, unless the combined hashes contain…
For Git, Linus basically says the validation function is a prepended type/length. https://news.ycombinator.com/item?id=13719368
Earlier quoted context omitted.
You are correct: by the pigeonhole principle, if the sum of the lengths of all the hashes/checksums is less than the length of the checksummed data, then collisions exist. (A detail: If checksums are included into the input of other checksums, their length doesn't count towards the amount of checksummed data, because they are not free to vary.)
Wouldn't this imply that all hash functions (other than one-to-one mappings) must have collisions? Why does the pigeonhole principle hold?
Earlier quoted context omitted.
> in fact on average they have to have gazillions of pre-images each pretty sure "on average" they have at least a few gazillion orders of magnitude more than a few gazillion pre-images each ;)
You're saying the average of infinities is a gazillion gazillion? For any hashcode, there are an infinite number of documents that would result in that hashcode.
(key words are "at least")
Now I really wonder what will happen to Git we all know and love.
Nothing: the risk of a fucked up rebase is still much higher than a hash collision.
Forgive my ignorance, but it seems a solution to collision worries is to just use two hashing algorithms instead of one. We have two factor authentication for logins, why not the equivalent for hashed things? Give me the sha1 and md5, rather than one or the other. Am I wrong in thinking even if one or both are broken individually, having both broken for the same data is an order of magnitude more complex?
Once you have the sha1 collision, making the md5 collide should only take a few seconds of CPU time.
So from a security standpoint if my hash was a sha-1 concatenated to an MD5, how long would it be before they found a collision?
One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't. Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've g…
Both Installer.py and Installer-evil.py result in the same piece hashes, with piece size chosen as 512. The only difference between the files is the shattered pdf fragment, encapsulated in a variable. This fragment starts exactly at the piece boundary, resulting in identical hashes.
Earlier quoted context omitted.
You don't really need to talk to anybody about this except people who torrent both illegal and legal torrents. Torrent poisoning is the most ripe for exploitation and the one with the highest return for a malicious attacker. So when you talk to someone who torrents, just tell them that the way the torrents verify a file is the correct one is no longer secure, and they have to keep an eye out for the next software upd…
wont an easy fix be to just hash it again with sha256? Sure that will take time to bake it into software, but wont they just be able to put a text label next to the description and say "sha256: abc...123" ?
Earlier quoted context omitted.
That's not the attack on git -- it's the commit ID. You can have two patches that have the same commit. Apply one now, and in the future replace it with the second one, without affecting any other commits IDs afterwards.
But I thought files in git were also identified by the sha1 of their contents? Why isn't there a conflict/de-duplication happening when committing one file over the other? I must be misunderstanding something, but I thought the commit points to a hash of a tree (file list) which has a list of blobs (file referenced by their sha1 sum), how does it know which of the two pdf file blobs to pick out of the blob store?