My (admittedly superficial) knowledge about blur reversibility is that an attacker may know what kind of stuff is behind the blur.

I mean knowledge like "a human face, but the potential set of humans is known to the attacker" or even worse "a text, but the font is obvious from the unblurred part of the doc".

▲

jonathanlydall 8 hours ago | parent | next [-]

This was also my understanding.

It's essentially like "cracking" a password when you have its hash and know the hashing algorithm. You don't have to know how to reverse the blur, you just need to know how to do it the normal way, you can then essentially brute force through all possible characters one at a time to see if it looks the same after applying the blur.

Thinking about this, adding randomness to the blurring would likely help.

Or far more simply, just mask the sensitive data with a single color which is impossible to reverse (for rasterized images, this is not a good idea for PDFs which tend to maintain the text "hidden" underneath).

▲

swiftcoder 6 hours ago | parent | next [-]

> mask the sensitive data with a single color which is impossible to reverse

You note the pitfall of text remaining behind the redaction in PDFs (and other layered formats), but there are also pitfalls here around alpha channels. There have been several incidents where folks drew not-quite-opaque redaction blocks over their images.

▲

yetihehe 6 hours ago | parent | prev [-]

> just mask the sensitive data with a single color which is impossible to reverse (for rasterized images, this is not a good idea for PDFs

Also not a good idea for masking already compressed images of text, like jpg, because some of the information might bleed out in uncovered areas.

▲

johnmaguire 5 hours ago | parent [-]

Interesting - does a little extra coverage solve this or is it possible to use distant pixels to find the original?

	▲	wheybags 3 hours ago \| parent \| next [-]
		I'm not super familiar with the jpeg format, but iirc h.264 uses 16x16 blocks, so if jpeg is the same then padding of 16px on all sides would presumably block all possible information leakage? Except the size of the blocked section ofc. E.g If you know it's a person's name, from a fixed list of people, well "Huckleberry" and "Tom" are very different lengths.
	▲	sebastianmestre 3 hours ago \| parent \| prev [-]
		yep, some padding fixes this JPEG compression can only move information at most 16px away, because it works on 8x8 pixel blocks, on a 2x down-sampled version of the chroma channels of the image (at least the most common form of it does)

▲

oulipo2 7 hours ago | parent | prev [-]

The parade is easy: just add a small amount of random noise (even not visible to the human eye) to the blurred picture, and suddenly the "blur inversion" fails spectacularly

▲

sebzim4500 7 hours ago | parent [-]

Does this actually work? I would have thought that, given the deconvolution step is just a linear operator with reasonable coefficients, adding a small amount of noise to the blurred image would just add similarly small amount of noise to the unblurred result.

	▲	srean 7 hours ago \| parent [-]
		To reconstruct the image one has to cut off those frequencies in the corrupted image where the signal to noise is poor. In many original images, the signal in high frequencies are sacrificable, so get rid of those and then invert. https://en.wikipedia.org/wiki/Wiener_deconvolution If one blindly inverts the linear blur transform then yes, the reconstruction would usually be a complete unrecognisable mess because the inverse operator is going to dramatically boost the noise as well.