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

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?

[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.

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

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?

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.

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.