Forensics Tool Finds Headerless Encrypted Files 374
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."
Yet another scam (Score:5, Interesting)
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 [truecrypt.org] 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:Patterns? (Score:3, Interesting)
No...
Encryption is supposed to indicate random noise. But encryption in a grand sense is about writing, and rewriting data.
Let's say I have data which is number 2...
My key is 4,4,4
My encryption is:
Value1 + number -> * Value3 -> - Value4
So it is 4 + 2 * 4 - 4... And I get some number...
I do this multiple times and I get a bunch of other others. Put all of these numbers together and I get what looks like giberish (assuming the algorithm is good enough).
But here is the problem, underneath the data is a pattern. And the calculations are a pattern, as a result a pattern emerges. The pattern is called human language.
For example one strategy for passwords is to use random data. Then you have no patterns because the resulting encryption is random noise.
To give you an understanding, I deal with random numbers and I cannot use a computer based random number generator because they generate patterns.
I subscribe to a random number service which is connected to a quantum lab and space noise...
Now, to say if it is not random you can start cracking it. Guess what you are right, but what if your numbers have 500 hundred thousand places. Going in reverse to figure out what those numbers are is actually pretty hard. That is why you have these issues of finding prime numbers...
Re:Plausible Denial? (Score:3, Interesting)
you got it. It's called hiding in the noise.
Format your drive, now plug it in as usb and create a full size truecrypt encryption on it and fill it with junk.
now take the drive, delete that file and then use it as your new drive whatever. any encrypted files will be hidden in the noise of the background encrypted file that is in the blank area of the drive.
TCHunt for Truecrypt containers (Score:1, Interesting)
TCHunt (free tool, you can find it with google) has worked for some time doing this exact thing on Truecrypt encrypted containers.
Actually tried it out last night. It does get false positives, but on my system it did indeed manage to find what it was looking for (total: 4 false positives, 1 true positive).
Re:Don't worry (Score:4, Interesting)
What I think they are doing and I think it would indicate an encrypted drive is distribution analysis.
If you have truly random data then there is a specific pattern. If you have deleted or unused blocks there will be a specific pattern.
But if you have an encrypted block the distribution will not be like any of the other pieces of data. This is your indicator.
Think of it as follows. You are driving on the highway and somebody on the highway drives the speed limit exactly, stays in the center lane, and does not switch lanes at all. Even though that would seem to be right, it is actually quite wrong and it would make police suspicious.
Re:Don't worry (Score:4, Interesting)
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:Yet another scam (Score:5, Interesting)
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.
Re:Plausible Denial? (Score:3, Interesting)
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?
It has a protection option where you can enter the hidden password along with the normal password so the hidden partition will be protected, the outer container will be frozen on a write attempt to hidden data. I think it's unnatural that you must ensure that there's no data written to the end of the disk though, it leads to some peculiar disk format choices and so on. A better implementation would be more like a transparent file system layer, where the outer partition could write anywhere it wants and the encryption software would move any encrypted data already stored there. It'd make it more difficult to locate the header but maybe a pseudo-random sector based on password. That way the outer container could look really natural. Today they tend to seem so very staged which tends to bring you don't from plausible deniablitity to "you can't PROVE it" deniability.
I'm calling BS (Score:2, Interesting)
I'm pretty familiar with TrueCrypt, but I don't know what a TrueCrypt "Dynamic" file is. Are they just talking about an encrypted virtual volume?
Anyway, I'm pretty sure this is BS. I think they're just doing regular entropy tests on files. That will tell you when you have random data. A good test might be able to distinguish a large amount of compressed data from encrypted data since compressed data does have a little redundancy (emphasis on "might" and "little").
But I guarantee that they are not detecting any redundancy in ciphertext. Detecting even a small amount of redundancy in the output of any modern cipher algorithm (like AES or Twofish) would be a HUGE cryptanalytic result. It would be front page news (in cryptographic circles).
In summary, I'm positive that they can't distinguish between a TrueCrypt volume and true random data.
Put up or shut up.
One-time pad (Score:2, Interesting)
Disk space is cheap.
Have a large one-time pad on one drive. For good measure, encrypt it.
Have an encrypted drive, and inside it have a one-time-pad-encrypted container file.
To keep from being toast if someone grabs both disks, have the one-time-pad-decoder program grab the bits from the one-time pad in some non-obvious order.
For example, when mounting the one-time-pad-encrypted container file, the mounter could ask for:
1) starting offset
2) byte-interleave
3) additional XOR string
The starting offset says start reading the one-time-pad file at byte OFFSET instead of byte 0.
The byte-interleave is how many bytes to skip between each read.
The additional XOR strong is an additional string that is applied as if it was a one-time pad, but it's used repeatedly. It won't offer a whole lot of protection on its own but it is just one more roadblock to decryption.
If the one-time pad is
01010111 11110000 00001111
and the data is
11111111 11111111 11111111
and the one-time XOR string is
01010101
and the starting offset is 0 and the byte-interleave is 0,
then the encrypted data is the xor of
01010111 11110000 00001111
11111111 11111111 11111111
01010101 01010101 01010101 <-- note the repetition
which is
11111101 01011010 10100101
Is unreadable data really encrypted data? (Score:3, Interesting)
I do a lot of data acquisition for work and in grad school. I've got lots of my data on my drive. They are written in binary formats of my design. There is lots of repetition, there are no headers, who knows what my data looks like to someone who doesn't know the "decoder ring" to unpack it.
That doesn't mean that my files are kiddie pron or directions to make a dirty bomb.
Sheldon
Re:Don't worry (Score:2, Interesting)
BTW I do statistical and probabilistic analysis in a hedge fund...
Oh, so according to Nassim Taleb [edge.org], you're one of the guys we should be blaming for the housing crash? You know, for improperly applying financial algorithms in a situation that has inherent (and significant) statistical uncertainty?
Ok, good to know.
Re:Don't worry (Score:3, Interesting)
So basically this doesn't tell the difference between an encrypted drive and a blank drive, it tells the difference between a pure random drive and a blank drive.
That is, out of the following three possibilities:
1. Default/blank drive, possibly non-random.
2. Drive written over with pure random bytes.
3. Full disk encryption.
This tool can tell the difference between 1 and {2,3}, but it can't tell the difference between 2 and 3. That should still give you plausible deniability then, because there's the possibility you've written over your drive with /dev/random, and there's no way (in theory) for any tool to distinguish between that, and TrueCrypt.
Re:Don't worry (Score:3, Interesting)
because, as one of the up-thread comments says, a large file which looks true random is either encrypted or the output of a (good) random number generator. This software wouldn't be able to tell the difference. Unfortunately very few people need very large amounts of true random data, as the people who need the most random numbers are probably computational scientists, and then a good PRNG will do that for you.
Alternative needs of true random data relate to communication, or cryptography. Either way you are either 1) an academic (easy to rule out/use as an excuse) 2)have a need for better than internet banking security on your communication (once again easy to prove or rule out, as almost noone needs this) or 3) have a large encrypted file.
One way around this would be to format the blank space on your hard drive true-random, rather than a specific pattern. that way all space which hasn't been used recently looks like a blob of "encrypted/random" text. If you then go and shred (overwrite with random data) all files as you delete them, then having a block of random text on your hard drive is only then evidence of paranoia, not criminal conspiracy.