= 27d567bc2d48d9f40e9ccc20ea370b15)
Nornagest comments on A pair of free information security tools I wrote - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (97)
What does "indistinguishable" mean in that sentence? Do you claim that a skilled attacker can't know that there metadata added?
Short answer is I don't know. The long answer will take a little background.
I haven't bothered to read through Decoy's internals, but this sort of steganography usually hides its secret data in the least significant bits of the decoy image. If that data is encrypted (assuming no headers or footers or obvious block divisions), then it will appear to an attacker like random bytes. Whether or not that's distinguishable from the original image depends on whether the low bits of the original image are observably nonrandom, and that's not something I know offhand -- although most images will be compressed in some fashion and a good compression scheme aims to maximize entropy, so that's something. And if it's mostly random but it does fit a known distribution, then with a little more cleverness it should be possible to write a reversible function that fits the encrypted data into that distribution.
It will definitely be different from the original image on the bit level, if you happen to have a copy of it. That could just mean the image was reencoded at some point, though, which is not unheard of -- though it'd be a little suspicious if only the low bits changed.
It's super-easy to spot in a histogram, so much so that there's ongoing research into making it less detectable.
You're mostly correct. The data is encrypted, and then broken into a base-4 string. The least significant base-4 bit is dropped from each pixel leaving 98.4% fidelity, which is higher fidelity than the compression that gets applied. Thus in terms of image quality, the picture is indistinguishable from any other compressed image.
The encoding is deliberately reversible and also open-sourced. However, you can apply the same algorithm to any image, whether it's a decoy or not, and get a string of possibly-encrypted-data. The only confirmation that the data is meaningful would be a successful decryption which is only possible with the correct passphrase.
All that said, the fact that the picture is indistinguishable from other non-decoy images only adds a trivial amount of entropy to the encryption. An attacker who is determined to brute force their way into your pictures can simply attempt to crack every picture in your camera roll, decoy or no.
Does it change the low bits of white (0xFFFFFF) pixels? It would be a dead giveaway to find noise in overexposed areas of a photo, at least with the cameras I've used.
It does. Taking a picture of a solid white or black background will absolutely make it easier for an attacker with access to your data to be more confident that steganography is at work. That said there are some factors that mitigate this risk.
The iPhone's camera, combined with its JPG compression, inserts noise almost everywhere. This is far from exhaustive but in a series of 10 all-dark and 10 all-bright photos, the noise distribution of the untouched photos was comparable to the noise distribution of the decoy. Given that I don't control either of these, I'm not counting on this to hold up forever.
The app forces you to take a picture (and disables the flash) rather than use an existing one, lessening the chances that someone uses a noiseless picture. Again though, someone could still take a picture of a solid black wall.
Because of this, the visual decoy aspect of it is not meant as cryptographic protection. It's designed to lessen the chances that you will become a target. Any test designed to increase confidence in a tampered image requires access to your data which means the attacker has already targeted you in most cases. If that happens, there are other more efficient ways of determining what pictures would be worth attacking.
My original statement was that an attacker cannot confirm your image is a Decoy. They can raise their confidence that steganography is taking place. But unless a distinguishing attack against full AES exists, they can't say with certainty that the steganography at work is Decoy.
TL;DR: the decoy aspect of things is basically security through obscurity. The cryptographic protection comes from the AES encryption.
The fact that it distributes noise doesn't mean that the noise is uniformly distributed. It likely doesn't put the same noise in an area with is uniformly colored and an area that isn't uniformly colored.
I can't say with certainty either that the sun will rise tomorrow.
This seems like deliberate misinterpretation of Nanashi's point. You can't say with certainty that the Sun will rise tomorrow, but you can say so with extremely high probability. An attacker can't confirm that the image is a Decoy with a probability anywhere near as high.
Correct. I'd assign a probability of, say, 99.999999999999999999% that the sun will rise tomorrow.
If I were an attacker analyzing the noise distribution of an image, I could say with maybe 10% probability that an image has been tampered with. From there I have to further reduce the probability because there are hundreds of ways an image could have been tampered with that aren't Decoy.
For what it's worth, here is a sample of the noise distribution of the iPhone's JPEG compression vs. Decoy
(iPhone on left, Decoy on right)
http://i.cubeupload.com/ujKps6.png
(Note that these are not the same picture, because Decoy does not save or store the original version of either photo. It's two pictures where I held the iPhone very close against a wall. So there's a slight color variation)
That's pretty useless -- what you want is to look at some statistical measures of the empirical distributions of lower-order bits in these images. See e.g. this outdated page.