3 ms·

Don't know why you are downvoted because I think this is still true for the most part that you should be able to trivially create another hash for the same imag

Don't know why you are downvoted because I think this is still true for the most part that you should be able to trivially create another hash for the same image with unintrusive operations. You might need to put some efforts in it and reverse engineer the hashing algorithm a bit and see what causes rolling a new hash value. A lot of research went into classifying images, mostly from the side that wanted visible or invisible watermarks in pictures. It is a cold war against image cropping, compression and modification that tends to not favor the classification side. But here you only want to have a different hash, the operations for that are numerous and probably indeed often trivial. I don't think you could just have a completely different picture create a collision though. Maybe they can because it is their hash-function, but that would be quite unusual and I doubt this is the case.

nullc 5y ago
> I don't think you could just have a completely different picture create a collision though. Allow me to introduce you to my posts on github: https://github.com/AsuharietYgvar/AppleNeuralHash2ONNX/issues/1#issuecomment-903094036 https://github.com/AsuharietYgvar/AppleNeuralHash2ONNX/issue... Where I post good looking examples of standard test images altered fairly subtly to give the specific hashes. The apple neuralhash is broken as a 'hash function'. It's much much easier to modify images to just have a different hash. A simple blemish on the image-- or, with whiteboxing using the hash function, no visually noticeable change is required at all.
- raxxorrax 5y ago
  That is seriously the hash function they used? I assumed a competent hash function, hell, any common hash function is better even if they fail at resize/compression. This one would too.
  - nullc 5y ago
    Apple 'neuralhash' usually survives resize (the first step it does is resize the image to 360x360) or minor compression lossy changes. But the price of that is that it's not secure against generating arbitrary preimages based on fairly arbitrarily targets, with results that look nothing like the original image you're matching (if one even exists). They could do some downsample, transform, quantize, sha256 approach that would still survive some tiny amount of differences. ... but apple favors easily constructed false positives over false negatives, even though its trivial for anyone trying to avoid their function to get a false negative. Their scheme only protects against accidental false negatives. It's just a symptom of systematically favoring factors other than the privacy and security of the actual owner and user of the computer.
    - raxxorrax 5y ago
      Wow, that is seriously a naive approach. Honestly, I would have expected much more here. That makes the libraries of hashes for content almost useless. Hope they extracted features that could be used in a more sophisticated approach.

nullc 5y ago

> I don't think you could just have a completely different picture create a collision though. Allow me to introduce you to my posts on github: https://github.com/AsuharietYgvar/AppleNeuralHash2ONNX/issues/1#issuecomment-903094036 https://github.com/AsuharietYgvar/AppleNeuralHash2ONNX/issue... Where I post good looking examples of standard test images altered fairly subtly to give the specific hashes. The apple neuralhash is broken as a 'hash function'. It's much much easier to modify images to just have a different hash. A simple blemish on the image-- or, with whiteboxing using the hash function, no visually noticeable change is required at all.

raxxorrax 5y ago
That is seriously the hash function they used? I assumed a competent hash function, hell, any common hash function is better even if they fail at resize/compression. This one would too.
- nullc 5y ago
  Apple 'neuralhash' usually survives resize (the first step it does is resize the image to 360x360) or minor compression lossy changes. But the price of that is that it's not secure against generating arbitrary preimages based on fairly arbitrarily targets, with results that look nothing like the original image you're matching (if one even exists). They could do some downsample, transform, quantize, sha256 approach that would still survive some tiny amount of differences. ... but apple favors easily constructed false positives over false negatives, even though its trivial for anyone trying to avoid their function to get a false negative. Their scheme only protects against accidental false negatives. It's just a symptom of systematically favoring factors other than the privacy and security of the actual owner and user of the computer.
  - raxxorrax 5y ago
    Wow, that is seriously a naive approach. Honestly, I would have expected much more here. That makes the libraries of hashes for content almost useless. Hope they extracted features that could be used in a more sophisticated approach.