Forensics Tool Finds Headerless Encrypted Files

gurps_npc writes "Forensics Innovations claims to have for sale a product that detects headerless encrypted files, such as TrueCrypt Dynamic files. It does not decrypt the file, just tells you that it is in fact an encrypted file. It works by detecting hidden patterns that don't exist in a random file. It does not mention steganography, but if their claim is true, it seems that it should be capable of detecting stenographic information as well."

Comments

Plausible Denial?

[telchine]

I'm am a citizen of the United Kingdom. Amongst many odd laws we have here, there's one that basically means that you can go to jail if you refuse to hand the police your encryption keys if they ask for them. The one saviour was Truecrypt's plausible denial. If they don't know you have encryption they can't ask for keys!

Now they do know I have encryption... ...and I've forgotten my password.

Can someone please give me tips on how to avoid dropping soap in the shower?

Re:Plausible Denial?

[wjh31]

practice holding soap between your cheeks, that should prepare you well.

Re:Plausible Denial?

[jroysdon]

I thought one feature of TrueCrypt was the ability to have two passwords. One password unlocks your "non-secret" data. The other password unlocks your "secret" data in a hidden volume.

http://www.truecrypt.org/docs/plausible-deniability

The point is both sets of data are stored in one big binary blob. It'll all look like one big fat encrypted mess. In fact, if you are not careful, your non-secret data can overrun your secret data.

To get around this "randomness" problem, after creating your non-secret partition, fill the partition completely with something (copy a few public domain books over and over until the partition is full). All the "randomness" will be gone with encrypted data. Then delete everything and put back in just the smallest amount of non-secret data you need to store in order to appear legit. The "randomness" is still there, as only the FAT entries are deleted, but all the encrypted data is still filling up that whole binary blob.

Now, create your secret partition and use it. Be sure to use it just short of the non-secret data's amount (as they fill from the opposite end), otherwise your non-secret partition will be corrupted.

This link helps with the graphics:
http://www.truecrypt.org/docs/hidden-volume

The one downside is that the non-secret side, if it fills up with too much data, will override your secret side. That's why your have backups and this is just for transport anyway, right?

Re:Plausible Denial?

[Animaether]

"That's cute, sir - now give us the other password"
- "what other password?"
"for the hidden truecrypt volume"
- "what hidden truecrypt volume??"
"the one that's being referred to by half a dozen applications' most recently used files lists"
- "oh err.. that's uh.. another drive entirely"
"very well, then hand us that other drive"
- "err uhm.. my dog ate it?"

If you're really, really serious about these things, maybe you could work super-diligently to prevent leaving any clues as to that hidden volume's existence.. odds are something's going to bite you in the behind somewhere though.

Re:Plausible Denial?

[Amazing Quantum Man]

Simple. Make your password, "what hidden truecrypt volume?"

Patterns?

[causality]

It works by detecting hidden patterns that don't exist in a random file.

I should first say that I'm rather ignorant about encryption but I hope someone will be able to explain this. I was under the impression that any sort of good-quality encrypted data is indistinguishable from completely random data. That seems to directly contradict the ability to determine whether a volume contains encrypted data by means of locating patterns. Is this really a contradiction?

Re:Patterns?

[Jah-Wren Ryel]

Dear mods, that's meant to be facetious. Some of you seem to be a little trigger-happy so you won't understand why I shouldn't have to explain that.

Make your joke and take the moderations like a man.
If you are going to explain that it is a joke, you might as well not bother in the first place since explaining takes away all the fun.

Re:Patterns?

[geekboy642]

Another thing would be Truecrypt's refusal to overwrite certain parts of that "random" data inside the not-hidden container. Gives it away that it's protecting the integrity of a hidden container.
Why do people constantly make this mistake?
TrueCrypt cannot know a hidden partition exists, *unless* you enter the inner volume password. It will cheerfully let you write right over the inner volume without so much as a by-your-leave, if you only give it the first password. It is true deniability, assuming this tool can't distinguish "encrypted blank space" and "encrypted data".

Umm...

[drakaan]

s-t-e-g-a-n-o-g-r-a-p-h-y...not stenography.

Re:Umm...

[Daimanta]

ssshhh, the "ga" is secretly embedded through steganography

Don't worry

[sakdoctor]

The company has "innovations" in it's name, so their product probably won't work.
If it did work against true crypt, which is a yard stick of well implemented encryption, I'm sure they'll come up with a counter measure by the next minor release.

Also: In before XKCD strip.

Re:Don't worry

[Kjella]

Since encryption implements a lossless conversion then the data is not random. BECAUSE random data is just that random.

Encryption in ECB mode leaves a very clear pattern, because identical input blocks leads to identical output blocks. Pretty much every other block chaining mode doesn't though because they mix it the preceding blocks, so i'm guessing an implementation flaw because the cryptographic primitives are pseudorandom, they have no distinguishable non-randomness unless you know the exact key.

Re:Don't worry

[FutureDomain]

The company has "innovations" in it's name, so their product probably won't work.

I actually tried it with a Truecrypt volume and a random file (/dev/urandom) and it seems to work. The Truecrypt is identified as "Encrypted Data (Headerless)" and the random file is identified as "Data File (Unknown)".

Re:Don't worry

[Anonymous Coward]

You realize that you aren't saying anything at all, right? Your argument is that since encrypted data is different than random data (an assumption you make without stating), encrypted data will look different than random data.

In reality, one of the standards for encryption algorithms (and block chaining methods) is that they produce a pseudorandom output. In fact, block ciphers are often called upon to operate as PRNGs when given random input data. The idea is that they will produce a significantly larger amount of pseudorandom output data than the random seed data.

BTW I do mathematical cryptanalysis at a university...

Re:Don't worry

[Stray7Xi]

BECAUSE random data is just that random.

Any kind of analysis that answers the question of whether a piece of data is random or deterministic can't do so with certainty. You can't prove a string of a million 1's wasn't randomly generated. Every piece of random data long enough will have substrings that appear to be a pattern.

Give a voice recognition program a low enough certainty threshold and it'll pick out words from below the noise floor. But the lower you go, it'll make more and more mistakes and eventually it'll pick out words from plain white noise.

Re:Don't worry

[MSG]

I don't think so... It's recommended that you compress things before you encrypt them if you plan to do both (usually for network transmission). If you encrypt and then compress, your compression will not be very effective. Good encryption produces very few patterns, and patterns are what compression applications need in order to function.

Re:Don't worry

[MoxFulder]

I wish I had mod-points for you.

Finally we hear from someone who knows WTF he/she is talking about.

Just to expand a bit: encryption algorithms (except for one-time-pad) don't produce truly random output. But all good, modern ones seek to produce output that's as indistinguishable as possible from truly random output, as a necessary but not sufficient component of their security. There are a variety of techniques to produce pseudorandom data based on a variety of sophisticated mathematics.

It seems like the height of hubris to claim that one software program can reliably detect all these different kinds of extreme slight deviation from perfect randomness.

A more plausible approach (as others have pointed out), is to look for files that do appear to be totally random. Such files are likely to be either (a) the output of a random number generator, or (b) encrypted. All files that have some useful content in their present form have some structure or non-randomness.

Who Cares?

[DomNF15]

The Wikipedia page on TrueCrypt already indicates that the volumes can pretty much be detected since they are always divisible by 512, it's just impossible to PROVE they are TrueCrypt volumes...

Be enlightened: http://en.wikipedia.org/wiki/TrueCrypt

Yet another scam

[trifish]

Wow, the quality of Slashdot has really been going down lately. Now any random fraud can submit his misleading material and it gets accepted to front page just because it sounds interesting? Is this actually tabloid or serious news for nerds who understand what the talk about?

In short, this is yet another lame attempt to make money by posting bogus claims about a popular product.

First, hidden volumes are the only kind of steganography that TrueCrypt offers. Second, if you read the TrueCrypt documentation, you'll learn the following about hidden volumes vs. dynamic:

On Linux or Mac OS X, if you intend to create a hidden volume within a file-hosted TrueCrypt volume, make sure that the volume is not sparse-file-hosted (the Windows version of TrueCrypt verifies this and disallows creation of hidden volumes within sparse files).

Furthermore, when I try to create a dynamic TrueCrypt volume, TrueCrypt displays a big warning saying that dynamic volumes are insecure. That's right. Insecure.

So again, I demote this story as total and utter bogus motivated by the vision commercial gain.

Re:Yet another scam

[gurps_npc]

I am the poster. I have ZERO connection to the company mentioned I read about because I do computer programming for a law firm.

The article may in fact just be an advertisement, created for commercial gain.

But it was posted because I personally read it and was interested in it.

This is complete BS, and is easy to test

[anom]

This is complete sensationalist crap. Truecrypt isn't broken, (probably) nor are any of the other programs they possibly claim to have broken.

This is easy to test for yourselves folks, I just did it in 5 minutes.

dd if=/dev/urandom of=/home/me/somefile.jpg bs=512 count=10000

Performing this command and then scanning the resulting file with "File Investigator" results in the file being detected as a headerless encrypted data file.

Whoever pointed out that they simply identify any randomly filled binary file of a size of a multiple of 512bytes is correct.

TrueCrypt doesn't use ECB mode, hasn't for some time, etc etc etc. Stop freaking out every time someone claims to have broken it.