Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Distinguishing Encrypted Data From Random Data?

timothy posted about 4 years ago | from the is-this-a-solved-problem? dept.

Data Storage 467

gust5av writes "I'm working on a little script to provide very simple and easy to use steganography. I'm using bash together with cryptsetup (without LUKS), and the plausible deniability lies in writing to different parts of a container file. On decryption you specify the offset of the hidden data. Together with a dynamically expanding filesystem, this makes it possible to have an arbitrary number of hidden volumes in a file. It is implausible to reveal the encrypted data without the password, but is it possible to prove there is encrypted data where you claim there's not? If I give someone one file containing random data and another containing data encrypted with AES, will he be able to tell which is which?"

cancel ×

467 comments

Sorry! There are no comments related to the filter you selected.

iieorjoeghoiuhtr (1)

Anonymous Coward | about 4 years ago | (#33629470)

erjpgoijpoij erghoiehrgoiuh ernnerughoiehrgh poiuhgriuhpoihegh erherhoiuerhgih.

Was that random or encrypted?

Re:iieorjoeghoiuhtr (4, Funny)

Anonymous Coward | about 4 years ago | (#33629484)

Trick question! It is random text that's been encrypted!

Re:iieorjoeghoiuhtr (2, Funny)

bennomatic (691188) | about 4 years ago | (#33629634)

Nice. "All your base are belong". You purposely left off the last two words to give a smaller sample to review and potentially recognize patterns.

Re:iieorjoeghoiuhtr (3, Funny)

Volante3192 (953645) | about 4 years ago | (#33629882)

Looks Welsh...

Yes he will know (1)

Anonymous Coward | about 4 years ago | (#33629478)

If he works for the NSA

perhaps... (0)

Anonymous Coward | about 4 years ago | (#33629490)

you're not the best one to write this kind of software if you don't know the answer. start here:

http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099

Re:perhaps... (1)

NFN_NLN (633283) | about 4 years ago | (#33629560)

you're not the best one to write this kind of software if you don't know the answer. start here:

http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099

I think this is the software version of the ADE 651 http://en.wikipedia.org/wiki/ADE_65 [wikipedia.org] .

Crunch, Crunch, beep, bop, boop.... yup, our software says that is encrypted data right there. Now give us the decryption key.
What, you can't? Looks like you're just trying to hide terrorist information from us.

Well (0)

Anonymous Coward | about 4 years ago | (#33629494)

If your question is: Can an encryption algorithm create patterns which can be identified upon analysis, then the answer is yes.
 

Re:Well (5, Insightful)

Kjella (173770) | about 4 years ago | (#33629558)

As far as I know finding patterns in the output is tightly linked to reducing the number of possible keys, so good encryption algorithms should not create patterns. Of course if your encryption software writes some kind of header - which wouldn't affect the security of the encrypted contents - then it will be obvious to anyone looking that you have an encrypted container. So this is 99% about implementation and 1% about encryption algorithms.

Re:Well (5, Insightful)

bytesex (112972) | about 4 years ago | (#33629678)

It depends what you call an 'encryption algorithm'. If you mean 'DES', then no - DES is nowadays considered a weaker algorithm. If you mean 'AES-256', then still no - you need to *apply* AES-256 before it's any good, because AES is a block-cipher and will re-encrypt identical blocks of plain-text with the same key to identical blocks of ciphertext. If you mean 'AES-256 in CBC mode with random IV and SHA-256 HMAC authentication', then that's an algorithm that can be safely used. Under certain real-world circumstances.

Re:Well (1)

zero.kalvin (1231372) | about 4 years ago | (#33629604)

I was always baffled by this. If you run your encryption algorithm on the encrypted data again(n times). wouldn't produce something indistinguishable at then end from random data?

Re:Well (5, Funny)

bennomatic (691188) | about 4 years ago | (#33629642)

Weird. I guess I there's a bug in my ROT13 implementation. If I run my text through twice, I just get the original message.

Re:Well (5, Funny)

SeanTobin (138474) | about 4 years ago | (#33629764)

Weird. I guess I there's a bug in my ROT13 implementation. If I run my text through twice, I just get the original message.

Just do what they did with DES... use 3rot13 and you're much more secure than the original implementation.

Ignore the person holding the phone book. (2, Insightful)

Suki I (1546431) | about 4 years ago | (#33629498)

After a few whacks on the head with the NYC Yellow Pages (old school, print edition) I think someone could find out which file is encrypted and which is garbage.

Re:Ignore the person holding the phone book. (1, Insightful)

acnicklas (1740146) | about 4 years ago | (#33629608)

Obligatory XKCD: http://www.xkcd.com/538/ [xkcd.com]

Re:Ignore the person holding the phone book. (5, Insightful)

parlancex (1322105) | about 4 years ago | (#33629670)

I think you're missing the point. Of course after they know that you have some encrypted data on your disk the strength of the encryption becomes moot because they can just drug / beat you until you tell them the key, but what this question is about is hiding encrypted data in unencrypted data so prying eyes can't tell if anything is even there at all.

For example, there may come a day when airport security could demand you disclose your passwords when they find you are carrying storage with encrypted content using the aforementioned techniques, but they aren't going to drug / beat every single person coming onto an airplane or going across a border. If your jpgs look like everybody elses jpgs both visually and under close analytical scrutiny they aren't going to bother you. Another example is there may come a day when any traffic on the Internet that cannot be positively identified as a common protocol with statistically "normal" contents is simply rejected. Maybe not here, maybe not right now, but this kind of idea is still very useful.

Re:Ignore the person holding the phone book. (1)

Suki I (1546431) | about 4 years ago | (#33629742)

I think you're missing the point. Of course after they know that you have some encrypted data on your disk the strength of the encryption becomes moot because they can just drug / beat you until you tell them the key, but what this question is about is hiding encrypted data in unencrypted data so prying eyes can't tell if anything is even there at all. For example, there may come a day when airport security could demand you disclose your passwords when they find you are carrying storage with encrypted content using the aforementioned techniques, but they aren't going to drug / beat every single person coming onto an airplane or going across a border. If your jpgs look like everybody elses jpgs both visually and under close analytical scrutiny they aren't going to bother you. Another example is there may come a day when any traffic on the Internet that cannot be positively identified as a common protocol with statistically "normal" contents is simply rejected. Maybe not here, maybe not right now, but this kind of idea is still very useful.

I thought the point was there is one encrypted file and one random file. Properly encrypted data is identical to random data, so let's see how many times the big man can hit you before you tell us which one is which. just like in the XKCD cartoon. Did I miss the point or do we need the drugs and wrench? ;) Even better, a small woman like me and you are helpless. How long do you think you can hold out? LOL

Re:Ignore the person holding the phone book. (3, Insightful)

John Hasler (414242) | about 4 years ago | (#33629848)

Try to get your head around the idea that they might have possession of your hard disk but not have possession of you. Or they don't even know who you are. Or they are honest cops, trying to determine if you have violated the rules. They've asked you if there is encrypted data on the laptop, you said no, and they are doing a routine check to verify that. Contrary to popular opinion, "The Man" is not always ready, willing, and able to administer a beating.

Then there is the possibility that your opponent is not "the Man" but some sort of furtive criminal...

Re:Ignore the person holding the phone book. (3, Insightful)

dcollins (135727) | about 4 years ago | (#33629870)

"Did I miss the point or do we need the drugs and wrench?"

You missed the point. The primary question of the OP is this: "...is it possible to prove there is encrypted data where you claim there's not?"

Hint: Include the likelihood of false-positives and false-negatives in your "wrench-based" analysis.

Both usable (1)

SuperKendall (25149) | about 4 years ago | (#33629932)

I thought the point was there is one encrypted file and one random file.

With stenography, one is encrypted and the other normal data. But both are usable - say a JPG image, where both load. So who is to say one has encrypted data, and they weren't just compressed using different settings? The question is, could anyone tell that (though with any given file format it seems like sophisticated enough analysis might be able to tell you that).

Re:Both usable (1)

Korin43 (881732) | about 4 years ago | (#33629958)

Or a more related example, trying to tell the difference between a hard drive with nothing on it ("random data"), and a hard drive with something encrypted. I'm not sure what the point would be with a normal file, since most people don't have large files containing random data, but empty partitions are somewhat believable.

Re:Ignore the person holding the phone book. (2, Interesting)

sjames (1099) | about 4 years ago | (#33629780)

That's why the deniability matters. They only have so many people available to whack people with the NYC Yellow Pages. You want them to believe there is a low probability that you have any secret to give up under "questioning".

Re:Ignore the person holding the phone book. (2, Funny)

Suki I (1546431) | about 4 years ago | (#33629838)

I see a market in in automated phone book whacking gadgets! Look for them soon on ThinkGeek.

Re:Ignore the person holding the phone book. (2, Funny)

sjames (1099) | about 4 years ago | (#33629856)

They will need to give it a significant civilian use, so it should come with an attachment that lets you beat the marketing department and PHBs to death with a paper towel roller.

Re:Ignore the person holding the phone book. (0)

Anonymous Coward | about 4 years ago | (#33629944)

You're an idiot, and you watch too many movies.

Encrypt the random data? (0)

Anonymous Coward | about 4 years ago | (#33629508)

Just a thought, encrypt the random data?

Lifting the Lid on the Guilty Yid (-1, Offtopic)

Anonymous Coward | about 4 years ago | (#33629516)

The liberals got it exactly right. For years now they’ve been telling us how “vibrant” mass immigration has made stale, pale White societies. Well, London was certainly vibrating on 7th July and that got me thinking: What else have the liberals got right? Mass immigration “enriches” us too, they’ve always said. Is that “enrich” as in “enriched uranium”, an excellent way of making atom bombs? Because that’s what comes next: a weapon of real mass destruction that won’t kill people in piffling dozens but in hundreds of thousands or millions. Bye-bye London, bye-bye Washington, bye-bye Tel Aviv.

I’m not too sure I’d shed a tear if the last-named went up in a shower of radioactive cinders, but Tel Aviv is actually the least likely of the three to be hit. What’s good for you ain’t good for Jews, and though Jews have striven mightily, and mighty successfully, to turn White nations into multi-racial fever-swamps, mass immigration has passed the Muzzerland safely by. And mass immigration is the key to what happened in London. You don’t need a sophisticated socio-political analysis taking in Iraq, Afghanistan, Bosnia, Jewish control of Anglo-American foreign policy, British colonialism, and fifteen centuries of Christian-Muslim conflict. You can explain the London bombs in five simple words:

Pakis do not belong here.

And you can sum up how to prevent further London bombs – and worse – in three simple words:

PAKI GO HOME.

At any time before the 1950s, brown-skinned Muslim terrorists would have found it nearly impossible to plan and commit atrocities on British soil, because they would have stood out like sore thumbs in Britain’s overwhelmingly White cities. Today, thanks to decades of mass immigration, it’s often Whites who stand out like sore thumbs. Our cities swarm with non-whites full of anti-White grievances and hatreds created by Judeo-liberal propaganda. And let’s forget the hot air about how potential terrorists and terrorist sympathizers are a “tiny minority” of Britain’s vibrant, peace-loving Muslim “community”.

Even if that’s true, a tiny minority of 1.6 million (2001 estimate) is a hell of a lot of people, and there’s very good reason to believe it isn’t true. Tony Blair has tried to buy off Britain’s corrupt and greedy “moderate” Muslims with knighthoods and public flattery, but his rhetoric about the “religion of peace” wore thin long ago. After the bombings he vowed, with his trademark bad actor’s pauses, that we will... not rest until... the guilty men are identified... and as far... as is humanly possible... brought to justice for this... this murderous carnage... of the innocent.

His slimy lawyer’s get-out clause – “as far as is humanly possible” – was soon needed. Unlike Blair and his pal Dubya in Iraq and Afghanistan, the bombers were prepared not only to kill the innocent but to die themselves as they did so. And to laugh at the prospect: they were captured on CCTV sharing a joke about the limbs and heads that would shortly be flying. Even someone as dim as Blair must know you’ve got a big problem on your hands when there are over 1.6 million people in your country following a religion like that.

If he doesn’t know, there are plenty of Jewish journalists who will point it out for him. There’s the neo-conservative Melanie Phillips in Britain, for example, who never met an indignant adverb she didn’t like, and the neo-conservative Mark Steyn in Canada, who never met an indignant Arab he didn’t kick. Reading their hard-hitting columns on Muslim psychosis, I was reminded of a famous scene in Charles Dickens’ notoriously anti-Semitic novel Oliver Twist (1839). The hero watches the training of the villainous old Jew Fagin put into action by the Artful Dodger:

What was Oliver’s horror and alarm to see the Dodger plunge his hand into the old gentleman’s pocket, and draw from thence a handkerchief! To see him hand the same to Charley Bates; and finally to behold them both running away round the corner at full speed! He stood for a moment tingling from terror; then, confused and frightened, he took to his heels and made off as fast as he could lay his feet to the ground.
In the very instant when Oliver began to run, the old gentleman, putting his hand to his pocket, and missing his handkerchief, turned sharp round. Seeing the boy scudding away, he very naturally concluded him to be the depredator; and shouting “Stop thief!” with all his might, made off after him. But the old gentleman was not the only person who raised the hue-and-cry. The Dodger and Master Bates, unwilling to attract public attention by running down the open street, had merely retired into the very first doorway round the corner. They no sooner heard the cry, and saw Oliver running, than, guessing exactly how the matter stood, they issued forth with great promptitude; and, shouting “Stop thief!” too, joined in the pursuit like good citizens.

“Wicked Muslims!” our two Jewish Artful Dodgers are shouting. “Can’t you see how they hate the West and want to destroy us?” Well, yes, we can, but some of us can also see who the original West-haters are. Mark Steyn claims not to be Jewish, but his ancestry shines through time after time in his writing. Above all, there’s his dishonesty. One week he’s mocking anti-Semites for claiming that the tiny nation of Israel could have such a powerful influence for bad on the world’s affairs. The following week he’s praising the British Empire for having had such a powerful influence for good. You know, the world-bestriding British Empire – as created by a tiny nation called Britain.

If the Brits could do it openly and honestly, Mr Steyn, why can’t the yids do it by fraud and deception? And the yids have done it, of course. They’ve run immigration policy and “race relations” in Europe and America since the 1960s, and Steyn is very fond of pointing out what’s in store for Europe as our Jew-invited non-white guests grow in number and really start to show their appreciation of our hospitality.

Funnily enough, I’ve never seen him point out that the same is in store for North America, which has its own rapidly growing non-white swarms. And when Steyn launches one of his regular attacks on the lunacies of multi-culturalism and anti-racism, a central fact always somehow seems to escape his notice. He recently once again bemoaned the psychotic “Western self-loathing” that has such a “grip on the academy, the media, the Congregational and Episcopal Churches, the ‘arts’ and Hollywood”. Exhibit one: the multi-culti, hug-the-world, “Let’s all be nice to the Muslims” memorial for 9/11. This was his list of those responsible for it:

Tom Bernstein... Michael Posner... Eric Foner... George Soros...
Well, that’s a Jew, a Jew, a Jew, and a Jew – sounds like a lampshade collector showing off his Auschwitz shelf. But fearless “Tell It Like It Is” Steyn, ever-ready to mock the “racial sensitivity” of deluded liberals, is himself very sensitive about race when it comes to the Chosen Ones. He’ll kick dark-skinned Muslims and their liberal appeasers till the sacred cows come home and he can start kicking them too, but just like Melanie Phillips he never whispers a word about the Jews who created liberal appeasement or about the enormous power Jews wield in “the academy, the media, the 'arts', and Hollywood”.

The same is true of all other Jewish “conservatives”. They’re shouting “Stop thief!” at the top of their voices and hoping that no-one will notice that they all belong to the biggest race of thieves who ever existed. Those bombs went off in London because Jews have stolen large parts of Britain from their rightful White inhabitants and handed them over to the non-white followers of a psychotic alien religion. When non-whites commit more and worse atrocities in future, you won’t need to ask who’s really responsible: it’s liberal Jews like Tom Bernstein and George Soros, who organize mass immigration and the anti-racism industry, and “conservative” Jews like Mark Steyn and Melanie Phillips, who distract White attention from the racial motives of Jews like Soros and Bernstein. Heads they win, tails we lose – liberal, “conservative”, they’re all of them Jews.

Re:Lifting the Lid on the Guilty Yid (2, Funny)

ian(at)union.io (1868404) | about 4 years ago | (#33629566)

Let me guess... Random!.. No, wait, too obvious. Encrypted!

Re:Lifting the Lid on the Guilty Yid (0)

Anonymous Coward | about 4 years ago | (#33629628)

I prefer the Boeing Boeing Gone guy. At least he varies the intro of his troll so that it's relevant.

Obvious solution (0)

Anonymous Coward | about 4 years ago | (#33629518)

Encrypt the random data with AES. Then do what you are doing. Result: It shouldn't be possible to tell whether you've written more AES encrypted data over some parts of the old AES encrypted data. And it should be impossible to distinguish what the data was like before the encryption.

(I don't know if that would really work as I've never studied cryptography... But I don't see any obvious reason why that wouldn't solve the problem.)

It's all about entropy (5, Insightful)

cpghost (719344) | about 4 years ago | (#33629538)

Encrypted files have maximum entropy, just like absolutely random files. Basically, you can't tell which one is which. However, absolute random noise on a disk isn't all that usual, so any encrypted file (or pure random file) will stand like a sore thumb: it will be highly visible. But, again, you can't tell the difference.

Re:It's all about entropy (1)

rm999 (775449) | about 4 years ago | (#33629578)

"However, absolute random noise on a disk isn't all that usual"

Doesn't compressed data look random?

Re:It's all about entropy (4, Informative)

Omnifarious (11933) | about 4 years ago | (#33629606)

Doesn't compressed data look random?

As an ideal, yes. But compressed data is still pretty distinguishable from random data. In particular, many compression formats have small markers in various places so that the decompressor can attempt to recover a corrupted file. Also, no compression technique is perfect, so even without these the data is still distinguishable.

Re:It's all about entropy (1)

Joce640k (829181) | about 4 years ago | (#33629826)

Nope. Imagine compressing a big file full of zeros. Most compressors will produce repeating output for that.

Re:It's all about entropy (1)

Jane Q. Public (1010737) | about 4 years ago | (#33629908)

They shouldn't. The best (and also most obvious) compression for such a file would be RLE, which would simply result in 2 numbers: 1 for the size of the file, and the other a 0.

Re:It's all about entropy (1)

parlancex (1322105) | about 4 years ago | (#33629598)

Parent is correct. If you want to disguise encrypted data with plausible deniability in existing files you should choose files that already contain data with very high entropy such as compressed file formats like mp3, gzip, rar, etc. Assuming the file remains functionally intact it would be extremely difficult or impossible to tell it was modified.

Re:It's all about entropy (5, Insightful)

mlyle (148697) | about 4 years ago | (#33629684)

Not exactly.

The problem with steg'ing inside known container formats, compressed container formats, is this:

Each implementation of the compression algorithm has its nuances. If the majority of an MP3 looks like it was compressed by the iTunes implementation, but then there's a range of output iTunes would not generate (particularly if the input file is known), that's very suspect. Ditto if things like PSNR change, even subtly, for the portion where steganography is in play. Even though compressed data has a great deal of entropy, it IS significantly constrained over random data in that A) known decompression programs must return specified output from it, and B) known compression programs generated this data as output from possibly-known input data.

If your adversary is the local police or one of your buddies, this stuff doesn't matter. If it's intelligence agencies or research organizations, good luck. Steganography is hard.

Re:It's all about entropy (2, Interesting)

gnasher719 (869701) | about 4 years ago | (#33629738)

Each implementation of the compression algorithm has its nuances. If the majority of an MP3 looks like it was compressed by the iTunes implementation, but then there's a range of output iTunes would not generate (particularly if the input file is known), that's very suspect.

Record same LPs to uncompressed audio files. That recording will be pretty unique. Encrypt your data any way you like, then store the encrypted data in the lowest bit of the 16 bit samples. Compress with Apple Lossless or FLAC or whatever you have.

Re:It's all about entropy (4, Interesting)

bytesex (112972) | about 4 years ago | (#33629694)

make it compressed header-less audio. Give 'em a decoder (which will produce noise), and claim you're a scientist and this is you recording Jupiter.

Re:It's all about entropy (1)

nullgraph (905820) | about 4 years ago | (#33629702)

What about compressing the files? The encrypted ones (high entropy) will not compress well while the other files, hopefully not all random noise, will compress much better.

Re:It's all about entropy (2, Interesting)

LihTox (754597) | about 4 years ago | (#33629712)

Isn't the point of steganography that you add the encrypted data on top of some other data, like a photograph or video, so that it looks like normal noise? I agree that carrying a thumb drive around, filled with random 0s and 1s, would be rather suspicious....

Re:It's all about entropy (1)

sjames (1099) | about 4 years ago | (#33629844)

Yes. What TFA talks about isn't actually steganography, it's just hiding the needle in the haystack a bit.

Real steganography would replace the nearly random least significant bits of something like a photograph with another set of nearly random LOOKING bits that are actually an encrypted message.

Ideally, it should use a one time pad for encryption. That will make it actually impossible to prove that there is an encrypted message at all. Any photo's LSBs can be "decrypted" to anything (within length constraints) using the right key.

Re:It's all about entropy (0, Troll)

betterunixthanunix (980855) | about 4 years ago | (#33629952)

Real steganography would replace the nearly random least significant bits

Someone should read up on modern steganography and watermarking techniques before making statements like that...

Re:It's all about entropy (2, Funny)

biryokumaru (822262) | about 4 years ago | (#33629730)

From now on, whenever I go on a flight I'm bringing several DVDs of random data.

Re:It's all about entropy (1)

butlerm (3112) | about 4 years ago | (#33629828)

Encrypted files have maximum entropy, just like absolutely random files

Not true, unless you have a randomly generated key that is as long as the file. You cannot apply any deterministic process to inputs of limited entropy and expect to get output entropy that is strictly speaking (computational complexity wise) higher than the sum of the entropy of the inputs.

Re:It's all about entropy (1)

Americium (1343605) | about 4 years ago | (#33629840)

That's the WHOLE point of encryption, if it didn't look random, you could crack it right away.

Re:It's all about entropy (1)

Americium (1343605) | about 4 years ago | (#33629854)

That's also the entire point of TrueCrypt, hiding an encrypted volume within an encrypted volume.

Re:It's all about entropy (1)

shentino (1139071) | about 4 years ago | (#33629890)

Just say that you copied stuff from /dev/urandom because you like to listen to it better than pirating crap from the RIAA.

No (2, Interesting)

trigeek (662294) | about 4 years ago | (#33629542)

Properly encrypted data is indistinguishable from random data. However, just the presence of random files on the system could be incriminating. Perhaps it's better to hide the data in another type of file? Perhaps using the lsb of a bitmap file?

Re:No (2, Insightful)

sjames (1099) | about 4 years ago | (#33629620)

It would be best to precondition the media by writing random data over the entire thing. For added fun, encrypt the text of various childrens books and write the result to the drive.

Re:No (0)

Anonymous Coward | about 4 years ago | (#33629970)

Would it be possible to create an encryption system which creates files which return the actual information when decrypted with key A, and "Alice in Wonderland" if decrypted with key B?

Yes (1)

ceoyoyo (59147) | about 4 years ago | (#33629636)

Unless you're using a properly constructed one time pad, which the poster is not, encrypted data is distinguishable from random. The more of it you have, the more distinct it is. With a good encryption algorithm it's not easy, and investigators would probably use other techniques, but it is possible.

perhaps not (0)

Anonymous Coward | about 4 years ago | (#33629736)

if one regularly wipes their deleted files with the final pass being a write of random data. That should, in theory, provide some haven in particular with encrypted drives and partitions.

Re:No (1)

butlerm (3112) | about 4 years ago | (#33629778)

Properly encrypted data is indistinguishable from random data.

That is the ideal, but hardly the reality. It is strictly _impossible_ for an encrypted version of a non-random data file to have as much real randomness as as a random data file, unless the key is as long as the file. Sure it can look pseudo random, much more random than the output of a pseudo random number generator (depending on the source file), but distinguishing it from real random data is just a matter of having sophisticated enough statistical tests. The larger the file, the easier it is to tell the difference.

Re:No (1)

MBoffin (259181) | about 4 years ago | (#33629790)

However, just the presence of random files on the system could be incriminating. Perhaps it's better to hide the data in another type of file? Perhaps using the lsb of a bitmap file?

Or just name the file JavaRandomNumberSeedFile.txt or similar.

Re:No (1)

maxwell demon (590494) | about 4 years ago | (#33629830)

What about naming it "OneTimePad"? And when asked, tell them you haven't used it yet, or you would have deleted it.

Re:No (2, Interesting)

owski (222689) | about 4 years ago | (#33629968)

Or, actually use the encrypted data as a one time pad and then when pressed use it to decrypt some ordinary data.

Ideally, Yes, but No (0)

Anonymous Coward | about 4 years ago | (#33629554)

In a perfect world, encrypted data would appear to be entirely random. We don't live in a perfect world, though, and as far as I'm aware there aren't any algorithms that exist with this attribute. You can make it very difficult, though.

Re:Ideally, Yes, but No (1)

maxwell demon (590494) | about 4 years ago | (#33629706)

Data encrypted with a one-time pad looks completely random. Provably. Indeed, if you were given the pad and the encrypted data, you'd not be able to say which is which.

It depends.... (4, Insightful)

TrumpetPower! (190615) | about 4 years ago | (#33629562)

If I give someone one file containing random data and another containing data encrypted with AES, will he be able to tell which is which?

Does the person to whom you give these two files have a rubber hose? Is he a member of the “extraordinary rendition” team?

The point of steganography is to not get caught in the first place. If you need plausible deniability, you’ve already lost.

Cheers,

b&

Re:It depends.... (1)

zill (1690130) | about 4 years ago | (#33629602)

If I give someone one file containing random data and another containing data encrypted with AES, will he be able to tell which is which?

Does the person to whom you give these two files have a rubber hose? Is he a member of the “extraordinary rendition” team?

The point of steganography is to not get caught in the first place. If you need plausible deniability, you’ve already lost.

Then why does the field of steganography exist at all? If your claims are true, then there is absolutely no point in studying and researching steganography. Yet dozens of paper are published on the subject matter every year.

Re:It depends.... (1)

TrumpetPower! (190615) | about 4 years ago | (#33629666)

zill wrote:

Ben Goren wrote:

The point of steganography is to not get caught in the first place. If you need plausible deniability, you've already lost.

Then why does the field of steganography exist at all?

To keep from getting caught. Duh.

Cheers,

b&

Re:It depends.... (1)

Joce640k (829181) | about 4 years ago | (#33629688)

Simple: Because there's a difference between "the card in this camera has some holiday snaps on it" and "the card in this camera has a file on it which is indistinguishable from random noise".

One will get you waved through, the other will get you tied up in the back room, drugged and being hit with a wrench.

Re:It depends.... (1)

maxwell demon (590494) | about 4 years ago | (#33629750)

Well, the point is: If you send someone pictures of your last holiday, someone noticing that will not suspect anything, and will not even think of applying tests to the pictures you sent. Therefore if you hide information in them, you will not need plausible deniability, because nobody will question you.

Re:It depends.... (1)

John Hasler (414242) | about 4 years ago | (#33629878)

The point of steganography is to not get caught in the first place. If you need plausible deniability, you've already lost.

No. You are not "lost" if the party examining the files is doing a routine search for encrypted files which usually comes up empty and/or has no access to your person anyway.

At the risk of doing someone's homework in a forum (1)

bytesex (112972) | about 4 years ago | (#33629570)

No. You cannot distinguish between the two. If you could, you would have an attack vector against the encryption. The trick, once you have a key, is to have authentication-strings in your data structure, so you can see whether the key you used is actually correct, and the decrypted data is actually useful. An attack based on this authentication string, is one of the many, many possible attack vectors against encryption. Also, 'random' is not always very 'random'. In the world of cryptography, we need serious random. C'mon dude, how far are you with this ?

Re:At the risk of doing someone's homework in a fo (2, Informative)

mysidia (191772) | about 4 years ago | (#33629686)

Perhaps. But if you use cryptsetup with LUKS, there is a readable header for the encrypted file, you don't need the key to determine encryption has been used. In fact, you can set multiple passphrases that have the authority to decrypt the partition.

GPG Encrypted data is also distinguishable, regardless of whether you use ASCII armoring or binary .GPG files. There are headers in the encrypted output that can be recognized without having the key to decrypt anything.

Now if you run 'openssl' from the command line, and choose 'aes-256-cbc', supply a true random key, and enter data bits interspersed with random 'padding bits'. It will be probably impossible for anyone to determine from the output whether there are any data bits or not, without knowing the key.

Re:At the risk of doing someone's homework in a fo (1)

Joce640k (829181) | about 4 years ago | (#33629698)

Maybe you should design it so the encrypted data has some patterns in it (ie. interleaved with the ciphertext)

Re:At the risk of doing someone's homework in a fo (2, Informative)

butlerm (3112) | about 4 years ago | (#33629858)

You cannot distinguish between the two.

This is categorically not true, unless the key is as long or longer than the data file (and never used again). There is indeed an attack vector against any encrypted data file if the key length is small by comparison. Statistical analysis plus the slightest idea of what type of data is being encrypted is more than adequate to mount a successful attack (given sufficient computational resources) unless the key is _much_ longer than what is typical today. The lack of computational resources is the only thing that keeps typical encrypted data secure.

Wrong question to ask? (2, Interesting)

mclearn (86140) | about 4 years ago | (#33629580)

Perhaps the question is incorrect. If i have a volume with data and a volume with encrypted data, then the encrypted data can be discerned from the non-encrypted data by virtue that there will be patterns detectable in the non-encrypted volume. So technically if you have a drive and there is random data on it but no discernible patterns, then there is either encrypted data on it, or it is an empty drive. It is likely not even factory default since that it likely to have some structure imposed upon it as well. What is the point of carrying around an encrypted volume with the ability for plausible deniability if that plausible deniability requires you to have random data as a volume? The existence of random data will render your plausible deniability claim useless since, by definition, your claim is no longer plausible.

Re:Wrong question to ask? (1)

mysidia (191772) | about 4 years ago | (#33629716)

I'm guessing you have three partitions on your hard drive... a 20 gigabyte Windows partition, a 5 gigabyte Linux partition, and a third partition that appears to be random data, the descriptor in your partition table reads type 0 UNKNOWN, or some random type that other OSes won't treat as valid.

To mount this volume you boot another OS first, or boot the 'unknown' partition from external media.

It depends. (1)

Delta (16579) | about 4 years ago | (#33629582)

If everything is perfect? No.

If you have two plaintext blocks, and encrypt using ECB mode with the same IV though, then the two cipher blocks would turn out identical cipher blocks. Would make it trivial to see which was the encrypted one.

So basically the answer is; it depends.

If you need to ask the question, do more research before you continue your work. This is stuff you really should understand before you embark on such a project.

Simple: encrypt a bunch of stuff (1)

KPU (118762) | about 4 years ago | (#33629590)

LUKS has a header. When I run cryptsetup on an uninitialized volume
# cryptsetup luksOpen /dev/sdb1 foo
Device /dev/sdb1 is not a valid LUKS device.

That means it can tell if the header is valid without a password. So now every offset needs valid LUKS header. Once you've done that, just make a bunch of perfectly valid encrypted volumes. Put real data in them. Install a working operating system that looks used.

One possibility... (0)

Anonymous Coward | about 4 years ago | (#33629610)

Would be to encrypt the empty data portions of the filesystem when the file system is created (or when files are deleted) using the same algorithm and a pseudo-random key (you want to encrypt the empty data portions using a pseudo-random key so that you can deny it).

Does it matter? (1)

Burning1 (204959) | about 4 years ago | (#33629612)

Do you think that 'I'm just sending random garbage' is going to offer any kind of plausible denyability in any situation where you could expose yourself to prosecution simply for using encryption?

Context (0)

Anonymous Coward | about 4 years ago | (#33629638)

Very rarely do people just have random data sitting around or transferring, when was the last time you burned a cd of random bits? Context can easily give away the purpose of data besides the data itself. Pretty much the only time you will see 'random' data being sent across a network would be for metric, discovery or troubleshooting purposes, though that might be a clever cover.

Simple (1)

PPH (736903) | about 4 years ago | (#33629646)

The files on employees computers containing seemingly random data can be assumed to be just that unless they're driving brand new Porsches and have vacation condos in Whistler.

Shouldn't (4, Informative)

dachshund (300733) | about 4 years ago | (#33629658)

AES is designed to be a pseudo-random function (meaning it's evaluated against that criteria). What this means is that /when used properly/ AES encrypted data should be indistinguishable from random data, at least for a distinguisher running in bounded time. If anyone discovers an efficient algorithm that can distinguish this, it'll be a big nail in AES's coffin (and yes, at the very theoretical level I realize that there already are some known weaknesses in AES, but for the moment you're in good shape).

Re:Shouldn't (2, Informative)

dachshund (300733) | about 4 years ago | (#33629796)

Erp, I meant Pseudo-Random Permutation, which is indistinguishable from a PRF if the amount of data is realistic.

Re:Shouldn't (1)

butlerm (3112) | about 4 years ago | (#33629898)

AES encrypted data should be indistinguishable from random data, at least for a distinguisher running in bounded time

That is a mathematical impossibility. The computational complexity of any finite deterministic function of inputs of finite complexity is finite. That means that any necessary analysis can also be conducted in finite time. The only thing protecting AES is the lack of computational resources on the part of attackers. Does anyone really think that thirty years from now it won't be commonplace to break the encryption of data encrypted using the key lengths we use now?

Random bytes are incriminating themselves (0)

Anonymous Coward | about 4 years ago | (#33629662)

As a practical matter, if anyone finds storage media that contains a byte sequence which passes many statistical tests of randomness, then they should conclude it probably contains encrypted data. There are very few other common mechanisms for random data to get on a hard drive in the first place. Disk wiping utilities usually only write a sequence of fixed bit patterns like all 1's or all 0's, but not random sequences.

That's not to say that randomness is a useless property. In a legal sense, no one can prove that random data is an encrypted volume. But if the goal is to avoid attention entirely, then even OTP is not good enough. Instead you have to hide your information in a natural, common source of entropy, like photographs or video. (Yes, your giant porn collection is a great place to hide the evidence from your secret conspiracy investigation.)

Re:Random bytes are incriminating themselves (1)

maxwell demon (590494) | about 4 years ago | (#33629784)

(Yes, your giant porn collection is a great place to hide the evidence from your secret conspiracy investigation.

But what if my giant porn collection is exactly the information I'm trying to hide? ;-)

Even apparent "random" data can contain structure (0)

Anonymous Coward | about 4 years ago | (#33629674)

You best run it through a statistical script for finding structure in data sets.

Also, remember that the file itself will contain structure.
If the file is suddenly structured, then random, then structured, it is pretty easy to tell there is something hidden there.
This is the easiest way used to detect hidden data on your average image upload websites and the like.
So stay away from that idea.

Hiding data in messy file formats, such as JPG, audio and video files, works really well.
You can use the files data itself to hide data. (such as using a certain section of the color channels for data)
A good example is hiding encoded data in the last X amounts of alpha channel in PNG. (10 for example)
It limits the amount of data, but it also limits the chance of anyone, or any thing, noticing it unless they are really looking hard. Alternative is hiding the data in the first X set of alpha channel, then it makes more sense that large chunks of the image is transparent (and the original image maker just sucked at making transparent backgrounds)

As always though, best way to test any algorithms is posting examples up of your methods and getting others to crack it, maybe even with a reward.

Hide it in Here! (0)

Anonymous Coward | about 4 years ago | (#33629708)

http://xkcd.com/221/

crypto is hard (3, Informative)

Tom (822) | about 4 years ago | (#33629710)

Hard to say from your question, but if you haven't done already, get yourself some crypto knowledge. Crypto is hard, there is a reason that you are laughed out of the room if you say you've invented a new crypto algorithm and you don't already have strong credentials.

Randomness is one of the harder computer problems. Especially in steganography, many implementations have been defeated by creating not enough or too much randomness. If you want to hide your message in something, it doesn't matter if your output is distinguishable from randomness, it matters if it is distinguishable from what should be there. Simple approaches like LSB tricks have often fallen because those happen to be not random in many input data.

Re:crypto is hard (1)

Spykk (823586) | about 4 years ago | (#33629788)

Randomness is one of the harder computer problems.

Random isn't so hard... [xkcd.com]

Re:crypto is hard (1)

mrmeval (662166) | about 4 years ago | (#33629928)

/dev/random does something like this by using environmental noise

Stick it in an existing format (0)

Anonymous Coward | about 4 years ago | (#33629762)

So why can't the encrypted data just be added to a normal file like one created by Open Office or Word (docx format)? I know the word format better, but my understanding is that both are simply zip containers that house XML and some pointers to things like graphics, etc. that sit in different folders in the zip. So just add the encrypted data as "graphic7" to a file that only has graphic1 - graphic6. I don't believe the applications would care at all about this and would display the file correctly.

chaining is essential (3, Informative)

pedantic bore (740196) | about 4 years ago | (#33629768)

If you use AES in ECB mode, then the answer is that it's usually painfully obvious that the original data was structured.

If you do use chaining (CBC, or something similar), then it will look quite random.

Excellent example here: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 [wikipedia.org]

Sure, you have to use... (1, Funny)

Anonymous Coward | about 4 years ago | (#33629770)

Math.

Be sure to use some math and it'll all be good

Plausible Deniability - TrueCrypt (1)

thetinytoon (827176) | about 4 years ago | (#33629794)

what you want is plausible deniability and that is not easy to achieve, as some states have started to have laws allowing to hold you hostage if you do not provide an decryption key to an encrypted container (which, with your method, would be corrupted). Have a look as TrueCrypts technical details behind their plausible deniability feature: http://www.truecrypt.org/docs/?s=plausible-deniability [truecrypt.org]

Yep (0)

Anonymous Coward | about 4 years ago | (#33629798)

The NSA can.

Depends on implementation (0)

Anonymous Coward | about 4 years ago | (#33629800)

If the right AES mode is used (CBC is a good one) and the implementation doesn't have any unencrypted headers, then it should be unable to differentiate between that and random.

Well... (1)

symes (835608) | about 4 years ago | (#33629818)

Arthur Conan Doyle wrote that the best place to hide something was right under the nose of the person looking for it - if someone spots an encrypted file, no matter how well hidden, it says you have something to hide. Instead you could simply print out your secret file in the form of a glossy magazine, something no one in the security world would really be interested in flicking through. Gardeners World or Philosophy Today. And then just leave it lying around, literally. It will be the last place they look. And the last thing they will confiscate.

metadata... (1)

Chris Snook (872473) | about 4 years ago | (#33629862)

While the data within the encrypted volume should be indistinguishable from randomness, the metadata headers are quite distinguishable. It's pretty obvious if something is a LUKS volume, but within that you shouldn't be able to tell.

Unfoilable Steganography in LSB Plane of Imagery (5, Interesting)

mirkurius (133480) | about 4 years ago | (#33629896)

Steganographic attempts are considered foiled if someone can detect that there is a secret message, they don't need to be able to retrieve the message in order for the attempt to be considered a failure. I did my Master's project on hiding data in the least significant bitplane of imagery. The trick is to "randomly" scatter your secret message throughout this plane. I showed methods that would allow you to do this so that the data was indistinguishable. You should always encrypt your secret message first so that it looks random, or better yet, shape the statistics of your encoded message to match the noise characteristics that were in the original LSB plane. If you use an image created from a very noisy source, such as a digital camera, and you encrypt the embedded message and scatter it using a reversible algorithm, and iteratively ensure that the statistics of the altered LSB plane look the same as the original LSB plane, I proved that it is not possible for someone to tell that there is a secret message hidden there. However, you need to be careful to use an original image you created yourself, and to destroy the original, because if someone ever compared the original to the one with the embedded message, they could definitely tell there was something altered by comparing the LSB planes.

Don't leave it quite so random (0)

Anonymous Coward | about 4 years ago | (#33629934)

There is an old stego app called "texto" that uses some words (as I recall, 64) to encode bits. What comes out looks like
boring and rather repetitive text, but does look like text.

Encrypt, use something like texto (pick different words at any rate), then compress. Result will look like text,
can be hidden in more conventional ways (e.g., name the file "George's boring report"). This will not
leave a file around with suspiciously high entropy. Few folks store random data so finding such would tend
to arouse suspicion. They can and do sometimes store boring and repetitive data (especially where it
comes from superiors). Once someone decompresses it, they may stop messing further.

By now intelligence services are well aware of truecrypt and could always ask you to zero the
free space in the outer volume (which would destroy your unrevealed inner one), so it is not
as good, I would submit, as the above.

Subscribe to external random data (1)

equex (747231) | about 4 years ago | (#33629946)

What about some sort of web service where you can download tidbits of random data to overwrite unused blocks on your drive ? Doesn't even have to be random all the time; it could be pieces of non copyrighted material for instance. So if anyone ask why you have random data, then you can say 'oh, thats just some stuff from the internet i downloaded'. That would be better than leaving your current unused blocks with pieces of your old deleted data too. If this became common, completely random data wold be unsuspicious. And on top of that it could be used as part of a disk-checking software to test your disk much like memcheck. /2cent

One time pad test (1)

Fractal Dice (696349) | about 4 years ago | (#33629960)

It is my understanding that if you start with a random one-time pad of 1s and 0s, it should be impossible to determine whether or not you have XORed a file of any entropy against it. If any background communication has surplus bits that are random 1s and 0s, that is your ideal stenography sub-channel. So any a test for encrypted data is really a test for a channel of random bits being transmitted.

The other half of the question is whether a test for random data is sufficient to detect a stenography channel? The smallest encrypted message that can be sent is a single bit - basically just a flare going up. And from a single bit, you can grow over time that channel to any arbitrary length. So that means your algorithm would be required to detect the existence of any pattern of random (unexplained) bits in a file or communication channel that the receiver could be flagging to read as a string of bits.

That's as far as I get ... I think that it probably reduces to being able to put a statistical upper bound on the size of a file that could be hidden given the number of random/unexplained bits in a data stream, but I don't think you could "prove" stenography wasn't happening.

( standard disclaimer: I am not a $profession )

Don't do it yourself (1)

Mashiara (5631) | about 4 years ago | (#33629972)

Unless you're Bruce (Schneier).

It seems rubberhose [wikipedia.org] is dead, but look at it and especially the fundamental ideas in it if you really wish to pursue this (I like the idea of having N encrypted volumes and the fact that you cannot prove that you have fully co-operated [and they cannot prove that you're not], of course you need some interesting data on the "bait" volumes as well).

The problem with properly used encryption being indistinguishable from random data is that you need a lot of good quality random data to hide your encrypted data in, because it will be distinguishable from the not-so-random data that you get out of /dev/urandom.

If you are in a situation where you will actually need encryption (especially deniable the sort) then don't trust your own code. As they say: A lawyer who represents himself has a fool for a client. (Don't trust someone elses code either unless it has been actually reviewed by more than two people who actually know how to do cryptoanalysis)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>