A nice Gaussian blur would probably be fine, it's specifically the pixelation technique that's leaking data.
Why blurring sensitive information is a bad idea (2007)
11–20 of 131 posts
Re: Why blurring sensitive information is a bad idea (2007)
#12A nice Gaussian blur would probably be fine, it's specifically the pixelation technique that's leaking data.
You think the technique mentioned in the article doesn't leak data? It actually leaks more data than a gaussian blur. Gaussian blur suffers from exactly the same problem, although a different difference function is needed for it.
Re: Why blurring sensitive information is a bad idea (2007)
#13In some cases even blurring faces might be a bad idea. Just because we are unable to unblur a face today doesn't mean we are unable in 10 years or 100 years. In many cases this might not be a problem but in some cases this might lead to trouble later on which can be avoided just as easily.
You cannot unblur mosaic blurring. It's the equivalent of a hash. The best you can do is brute force possible input vectors. There will be many collisions. This technique only works because digits/numbers limit the input space for a credit card or bank number. For faces, the best you can do is validate if someone you already suspect or someone you have in a database, is the origin of the mosaic. If you had a picture…
Re: Why blurring sensitive information is a bad idea (2007)
#14In some cases even blurring faces might be a bad idea. Just because we are unable to unblur a face today doesn't mean we are unable in 10 years or 100 years. In many cases this might not be a problem but in some cases this might lead to trouble later on which can be avoided just as easily.
Re: Why blurring sensitive information is a bad idea (2007)
#15Re: Why blurring sensitive information is a bad idea (2007)
#16Earlier quoted context omitted.
You cannot unblur mosaic blurring. It's the equivalent of a hash. The best you can do is brute force possible input vectors. There will be many collisions. This technique only works because digits/numbers limit the input space for a credit card or bank number. For faces, the best you can do is validate if someone you already suspect or someone you have in a database, is the origin of the mosaic. If you had a picture…
Maybe the scientifically correct definition of "to unblur" is reverting the process directly by applying a mathematical algorithm. In a normal conversation like what we have here, bruteforcing a good enough result can also be considered "to unblur" because for the person it's the same result: Everybody knows who it is.
Re: Why blurring sensitive information is a bad idea (2007)
#17Earlier quoted context omitted.
You cannot unblur mosaic blurring. It's the equivalent of a hash. The best you can do is brute force possible input vectors. There will be many collisions. This technique only works because digits/numbers limit the input space for a credit card or bank number. For faces, the best you can do is validate if someone you already suspect or someone you have in a database, is the origin of the mosaic. If you had a picture…
Maybe the scientifically correct definition of "to unblur" is reverting the process directly by applying a mathematical algorithm. In a normal conversation like what we have here, bruteforcing a good enough result can also be considered "to unblur" because for the person it's the same result: Everybody knows who it is.
Re: Why blurring sensitive information is a bad idea (2007)
#18[deleted]
Re: Why blurring sensitive information is a bad idea (2007)
#19[deleted]
Re: Why blurring sensitive information is a bad idea (2007)
#20[deleted]
Are you a professional cryptographer? Can you prove that your random shuffling is impossible to extract sensitive data from? No? Then you better stick with completely deleting the data from the image entirely.
Me: Your protocol has a serious size-side channel that leaks all the important data as sizes. Please use a constant length encoding.
Duh: Thanks! I added RANDOM padding. Totally secure now(tm).
Me: Your random was rand(), I recovered the LCG state from a few packets with known sizes and then recovered the original sizes, its still totally insecure. /Please/ make it constant size.
Duh: I made the random better and got rid of the known length packets. Now its extra completely secure.
Me: This will just take more statistical analysis to break, please just make it constant— the overhead is negligible! This is critical and anything short of constant is leaking information. We can't make assumptions about how powerful the attacker's statistical reasoning is, so even a small leak could be fatal.
Duh: I tried for two hours and couldn't break it. You're wasting my time.
Me: Argh. After a week of analysis, I've created this sampling and averaging script which completely recovers the secret data. Please. Just. Make. The. Encoding. Constant. Length.
Duh: Oh come on, that requires the same user to use it four times in a row. But fine, I now also quantize the size to a multiple of 2. The script you gave me no longer works, so now it's secure.
Me:
The adage that anyone can make a cryptosystem he himself can't break— should have a sister rule: Most people can make a cryptosystem which isn't cost effective to review by an honest party but which may be very economical to attack once it's protecting something of value.