7 ms·

You have two primary misunderstandings AFAICT. (1) You're assuming it's a "traditional" hash, as opposed to a perceptual hash. The former is purely based off f

You have two primary misunderstandings AFAICT. (1) You're assuming it's a "traditional" hash, as opposed to a perceptual hash. The former is purely based off file contents and thus any transformations applied on an image will lead to a new pseudorandom hash. By contrast, perceptual hashes are made to be able to still return a positive when a photo is resized, accumulated artifacts etc. This proposal is to use phashes, not hashes (2) You have a subtle misunderstanding of how a traditional cryptographic hash function works. Such a function maps an infinite number of possible inputs to a finite number of possible outputs. To your point, flipping even a single bit will basically give you a completely new pseudorandom hash. However, given the infinite inputs and finite outputs, for every output (every hash) there is a countably infinite number of possible inputs that would hash to that value. Thus it's entirely possible to change the file contents and end up with the same hash, although (to your point) without doing any magic to intentionally cause a collision, effectively you will never get one because of just how many damn buckets there are

maerF0x0 5y ago
irrc a cryptosecure hash is computationally infeasible to generate a new sample that has the same hash. that is if you know hash (or reasonably small, ie only a percent of the total bit space), it's improbable bordering on impossible to generate a false positive .
- __blockcipher__ 5y ago
  Agreed. From my comment: > although (to your point) without doing any magic to intentionally cause a collision, effectively you will never get one because of just how many damn buckets there are
- gpm 5y ago
  Repeating that this process doesn't appear to be using cryptographic hash functions in the first place, so this conversation isn't relevant, but: Only in the sense that "we don't know of a way to generate a new sample that has the same hash, yet". Unless we can prove P!=NP, we can't even prove that there exist hash functions that are actually infeasible to generate a sample with the same hash - so far we are no where close to knowing whether P!=NP or P=NP. Even if we assume P!=NP, that doesn't mean that it is infeasible to generate collisions for our current cryptographic hash functions. They're not backed by some mathematical proof of correctness assuming <assumptions>, just the fact that so far no one has publicly figured out a way to break them, and the people who spend time trying think that their design is one that is unlikely to be broken in the near future. We have managed to find collisions against hash functions that we previously considered cryptographically secure, that were designed with the same sort of standard in mind: E.g. md5 (https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities) and sha1 (https://en.wikipedia.org/wiki/SHA-1#Birthday-Near-Collision_Attack_%E2%80%93_first_practical_chosen-prefix_attack https://en.wikipedia.org/wiki/SHA-1#Birthday-Near-Collision_...). There's no great reason to think that private groups could not have an attack against current hash functions [1], and there's definitely no reason to think that they won't find one in the future. [1] There sort of is for SHA2, and that's that bitcoin has effectively created a giant bounty for breaking it.

maerF0x0 5y ago

irrc a cryptosecure hash is computationally infeasible to generate a new sample that has the same hash. that is if you know hash (or reasonably small, ie only a percent of the total bit space), it's improbable bordering on impossible to generate a false positive .

__blockcipher__ 5y ago
Agreed. From my comment: > although (to your point) without doing any magic to intentionally cause a collision, effectively you will never get one because of just how many damn buckets there are
gpm 5y ago
Repeating that this process doesn't appear to be using cryptographic hash functions in the first place, so this conversation isn't relevant, but: Only in the sense that "we don't know of a way to generate a new sample that has the same hash, yet". Unless we can prove P!=NP, we can't even prove that there exist hash functions that are actually infeasible to generate a sample with the same hash - so far we are no where close to knowing whether P!=NP or P=NP. Even if we assume P!=NP, that doesn't mean that it is infeasible to generate collisions for our current cryptographic hash functions. They're not backed by some mathematical proof of correctness assuming <assumptions>, just the fact that so far no one has publicly figured out a way to break them, and the people who spend time trying think that their design is one that is unlikely to be broken in the near future. We have managed to find collisions against hash functions that we previously considered cryptographically secure, that were designed with the same sort of standard in mind: E.g. md5 (https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities) and sha1 (https://en.wikipedia.org/wiki/SHA-1#Birthday-Near-Collision_Attack_%E2%80%93_first_practical_chosen-prefix_attack https://en.wikipedia.org/wiki/SHA-1#Birthday-Near-Collision_...). There's no great reason to think that private groups could not have an attack against current hash functions [1], and there's definitely no reason to think that they won't find one in the future. [1] There sort of is for SHA2, and that's that bitcoin has effectively created a giant bounty for breaking it.