Live data from Hacker News

Why blurring sensitive information is a bad idea (2007)

dheera.net

11–20 of 131 posts

Re: Why blurring sensitive information is a bad idea (2007)

#11
post #2

A nice Gaussian blur would probably be fine, it's specifically the pixelation technique that's leaking data.

It will be worse than that. Pixellation destroys information, it's not reversible in general. But in this case, what is left is enough for recovery, as source domain (check number) is small. Gaussian blur is theoretically lossless (rounding loss and loss on image edges in practice) - you can take arbitrary image, blur it, reverse and get original+noise

Re: Why blurring sensitive information is a bad idea (2007)

#12
post #5
post #2

A 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.

Gaussian blur is equivalent to an auto key cipher [0] without a key. Each pixel is composed of a couple pixels from the original. With some simple algebra, cross-examining pixels that have values determined by the same origin pixel, you can reverse the operation.

[0] http://en.m.wikipedia.org/wiki/Autokey_cipher

Re: Why blurring sensitive information is a bad idea (2007)

#13
post #6

In 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…

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)

#14
post #6

In 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.

If you have trial faces at the right angle, you can unblur faces, it's just a bit harder to generate. But nothing major is going to change in 10 or 100 years; it's just information theory as to whether you can identify the person/number or not.

Re: Why blurring sensitive information is a bad idea (2007)

#16
post #13

Earlier 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.

The un prefix means to reverse. If you have no database of people you're not going to be able to do anything in the way of reversing the mosaic. It's not a reversal as much as it is a heuristic brute force.

Re: Why blurring sensitive information is a bad idea (2007)

#17
post #13

Earlier 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.

[deleted]

Re: Why blurring sensitive information is a bad idea (2007)

#19
post #15

[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.

Re: Why blurring sensitive information is a bad idea (2007)

#20
post #15

[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.

Brings back nausea from arguments past, that went something like this (dramatized for your pleasure):

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.

Post reply on HN