Slashdot Mirror
USAF Wants To Find Steganographic Content
Bud Higgins writes "The U.S. Air Force has posted a Small Business Technology Transfer Program (STTR) solicitation in which they seek proposals for the automated detection of steganographic content. They seek an application that should run both unobtrusively in the background and in a manual mode, and provide the user the capability to scan all email attachments, downloaded materials and accessed files with an appropriate steganalysis algorithm, reporting any abnormal results (i.e. the presence of steganography). I personally don't think that is feasible, but maybe a good programmer can prove me wrong. A link to the solicitation AF04-T008 can be found here. For those who are not familiar with the SBIR/STTR program, it provides up to $850k for 3 years of research." This sounds very similar to what Niels Provos did over a several-year period at University of Michigan's CITI and released under a free license. I hope the USAF doesn't spend too much of my money without considering extending that research.
...reporting any abnormal results (i.e. the presence of steganography). I personally don't think that is feasible...
I think it probably depends on where you hide the data. For instance, it's probably harder to hide data in the LSBs of an image than, e.g. a file that's supposed to be white noise ("Hey, my mic doesn't work, it only records noise. See for yourself"). Of course, the less data you encode, the harder it is to detect it.
Opus: the Swiss army knife of audio codec
I work for a company that is funded through a SBIR grant, so on behalf of the company I work for and to all tax paying Americans let me just say: Thank You!
It really is an interesting government program. All the IP we generate with the money stays with us. However in the interest of equitable return to the taxpayer, we have decided to release all of our core software components GPL. (Okay, okay this also helps when it comes time for our semi-annual review, to show that we aren't just soaking the taxpayers.) We hope to turn a profit partially by our user interface components (non-core code that we are not releasing) and also through support.
Trying to get one of these grants is highly competitive, but if you have a really good idea and don't want the vulture capitalists to "fund" you, this is a great program.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
As stegdetect (last time I checked) easily fails on files created with steghide
argan0n
I'd expect that a fair amount of first-order steg would be detectable by a process that examined all patterns in a data stream, and spotted that or those patterns that were UNLIKE the other patterns in the data, based on some heuristic.
Of course, if you were to steg with an OTP or some such (i.e. your steg is based on deviance from a known data set), you'd more easily escape such detection.
Terrorists can attack freedom, but only Congress can destroy it.
If the steg'd data has obvious headers and block formatting, a weak algorithm could leave enough of a pattern in the output file to be detectable. And of course some applications of stego are used to embed cleartext data...
Proponents of stego sometimes suggest it's use in environments where even the suspicion of crypto is enough to risk persecution and/or prosecution.The other "trick" to detecting stego is that "normal" JPG/BMP/WAV/MP3/AVI/MPEG files tend to not actually show a high degree of random noise -- the seemingly random data in the LSB tends to have a pattern imposed by the encoder used and the input device.
I'd guess that this problem is more of an issue on highly-processed information from clean sources. You wouldn't expect random noise on an MP3 file ripped off the latest pop album release, but it wouldn't be out of place on a .SHN "bootleg" recording of a TMBG live concert from a handheld DAT recorder...
I do not deploy Linux. Ever.
paper (pdf) on detection of steganographic messages based on simple statistical analisys of the image. It seems to work well against 2 of the 3 major steganographic endodings they tried.
To be precise: they have much more noise, but You can only use a fraction of that noise for steganography. Otherwise You would destroy or significantly alter the original content of the compressed file.
The point of steganography is to hide information so that its presence cannot be detected. This means hiding information below the noise floor of the media. Information hidden in this way cannot be practically detected, assuming the stego is halfway decent, and the message to be hidden appears random (easily accomplished by encrypting it first).
Sure, *if* you had access to the unaltered original, then you could detect that it had been altered, but any competent steganographer would encrypt the hidden information first.
This sentence demonstrates that you don't understand either /dev/urandom or steganography.
More mis-informed rubbish - kernel implementation and processor type have little to do with the algorithms underlying the /dev/urandom implementation. Furthermore, /dev/urandom is based on "natural type" entropy (i.e randomness derived from unpredicable physical processes).
So if you have to hide something from the feds then become a scientist and collect lots of data from nature. It should have an element of randomness that allows you to steg your secrets in the data.or, you could go and take a regular photo. Plenty of real, nature-derived randomess there.
But then how would you know it was there in the first place? The person sending off your internal data won't be caught and will probably just try other ways. But, if you detect steganography in outgoing/incoming data, you can try and hunt down who is sending it and who he is speaking to. And, if you can decipher the files, you can find out what they are after.
Cthulhu Saves.
oh hell it's easier than that.
I wrote a program back in college that did better than that.
your "hidden data" must be 1/16th the size of the total image size. I used tga files as they were very common back then.
I simply encoded my data one bit at a time into the lsb of every other pixel. extremely small changes in the pixel color so it's undetectalbe by the human eye. and I'd bet that it's undetectable by every detection program out there. I even wrote in a function to specify the number of padding 0's you wanted to use before data started to be written.
This add's no redundancy or any detectable changes to the image file.
Do not look at laser with remaining good eye.
You'd have go go around obtaining lots of original recordings. Like using an one-time pad, with stego, you can't use the same source twice, nor can you use a source that's already available. You need to be the sole source. Otherwise the enemy can do a binary comparison and see that there's something different, possibly hidden data.
I am afraid you have it backwards. Compression is removal of repetitive, guessable parts. The better you compress, the more random the output becomes. Perfectly compressed data consists of bits where each bit has no relation whatsoever to any other bit in this data.
So it is perfectly possible to hide information in large data files. The original request is impossible, because you not just need to reliably extract the ciphertext - you can't even recognize it as such; what you have to do is to extract a probable ciphertext and decipher it, only then you know that you are successful. But deciphering of even one ciphertext may take years, and the customer wants to do millions of them, and in real time... good luck.