TrueCrypt Discrepancy

by 16s • 15 years ago

150 47 15 years ago

d0ne• 15 years ago

This should be addressed promptly by the TrueCrypt community.

DCoder3• 15 years ago

I downloaded the setups from the links, and used the "Extract" option in the installers. It appears that only the license was changed: http://pastebin.com/G3H78tSt

Edit: However, the installer binaries' sizes differ by 113280 bytes, while the extracted files' size totals differ only by 925 bytes.

Edit 2: the majority of the size difference is in the .rsrc section, the newer version contains several additional binary resources, some of which appear to be boot loaders. And the text resources are different... is it possible the installed versions are different and the extracted ones are not?

mquander• 15 years ago

That makes sense, since the installer has compressed its contents.

16s• 15 years ago

Several files were added to the .rsrc/BIN folder. See the second screenshot here.

http://16s.us/TCHunt/discrepancy/Screenshot2.png

DCoder3• 15 years ago

Yes, that's what I said... but this is the resource section of the installer, not of the extracted executable. The extracted executable is the same and doesn't, as far as I can see, make any references to those resources.

It is possible they recompiled it with the new license and the installer project was configured to carry all resources it found in specific folders, while the executable was configured to only include specific resource files... I used Extract instead of Install because my system disk is already truecrypt'ed, but if you can provide the files the installation creates, I could compare those too.

DCoder3• 15 years ago

Sorry for double posting, but those additional resources are boot loaders for Rescue Disks. Why and how do they differ from normal loaders, I don't know.

carbonica3• 15 years ago

The TCHunt program, whose website this link points to, is quite interesting. It seems to exist to simply point out something I always felt was self-evident, yet I commonly see misunderstood:

"Q. Why write a program such as TCHunt?

A. To demonstrate that while encrypted volumes may be indistinguishable from random data created in one specific fashion that the volumes themselves can be easily distinguished from most other files on your system. Many people insist that their encrypted volumes are undetectable. I hope TCHunt will convince them otherwise, before they learn this fact the hard way. More importantly, you should never claim that an encrypted volume with a mp3 file extension (or whatever) is a corrupt file, etc. While that explanation may seem plausible to an average person, it will not stand up to forensic or legal scrutiny. Data corruption does not resemble AES encrypted data. If disclosing the location of your encrypted volumes may lead to legal issues, then say nothing and contact a competent lawyer."

Of course, as he notes, it can't tell the difference between regular and hidden volumes, but once again: the hidden volumes will still stick out like a sore thumb and clearly be encrypted data. While plausible deniability is technically maintained, believable deniability will always be harder.

altrego99• 15 years ago

Basically, it identifies the randomness of a file that is AES encrypted. In general no other file will have that kind of random data. I wonder then, can there be an efficient encryption algorithm which will make your file look more like a particular type of data (say .mp3 or .jpg)?

jamesaguilar• 15 years ago

Well, you could always encode the data as an mp3. If you did, it would look a lot like an MP3. Might not be efficient though. And it would still be easy to tell that it was encrypted data.

dedward• 15 years ago

This is why you use full disk encryption with a hidden volume, and follow proper practices for keeping both maintained.

The computer will be obviously encrypted - but, if done correctly, there will be no way to know there is more than one system in there. (there are plenty of side-channel give-aways though that a thorough investigation might turn up - truecrypt's docs and site explain this better than I ever could)

That was off topic - your idea, it is interesting. I wish I had the background to comment on it.

drivebyacct22• 15 years ago

"the hidden volumes will still stick out like a sore thumb and clearly be encrypted data"

I thought that was the entire point of the hidden volume... that from outside you can't tell there is a hidden volume? And that from inside the fail-safe, you still can't tell there's a hidden volume? I may simply be mistaken.

---

Uh, I think you're missing the point of how the plausible deinability works. The point is that under duress you can acknowledge that it's a TrueCrypt volume, and open it up without at all exposing the hidden volume inside. It's like having a treasure chest with a false bottom where you store your good. The fact that it can't differentiate the location of hidden volumes is... paramount.

A "hidden volume" does not mean a truecrypt volume disguised to look like a normal windows file which is what this program looks for...

carbonica3• 15 years ago

You're right in a way - TrueCrypt fills empty space in its volumes with random data, and hidden volumes fill that space, and will appear random as well (being encrypted).

The question is whether, upon finding a volume which is vastly oversized compared to the non-hidden data, you believe that there are no hidden volumes. If your hidden volume is small relative to your normally-encrypted volume, your believable deniability is much better. But if the important stuff is all on the hidden volume...

ineedtosleep• 15 years ago

I get that hidden volumes will stick out, but what about hidden volumes that are relatively small in size -- let's say about 500K - 1MB? Would that still stick out as its footprint is smaller or is that not the right way to look at hidden volumes?

fleitz• 15 years ago

Structured data has a 'histogram' that is vastly different than CBC encrypted data. CBC encrypted data has a 'flat' histogram, where as structured data has a different signature.

Create a program that creates data histograms and you'll see what I mean. There are much easier ways to tell as well, like FOURCC or magic bits for files, for instance a gif file always starts with GIF89, or JPEGs start with JFIF, same with zip files, tar, etc. Almost every file can be recognized independently of it's name, by it's structure.

If you reverse engineer stuff sometimes you'll be given files that you don't even know the structure of and have to figure out what are offsets and what is data. Samething with reverse engineering compiled code.

zobzu2• 15 years ago

It's still valid if the entire volume is encrypted that way, aka the disk is 100% random data, then nothing will stand out. The volume might have been deleted by dd if=/dev/urandom of=/dev/sdb (for example) in order to wipe the data and make recovery harder. It's common practice (except you usually want many passes).

This is also possible to do on a single partition.

Note that this does not mean that TC is undetectable in any way.

This only means, that the theory behind the concept is perfectly viable and correct - unlike what you are suggesting.

noduerme2• 15 years ago

Just out of curiosity, I wonder what happens if you zip and tarball your encrypted archives. If TCHunt mimics whatever the standard enforcement scan is, say when you land at an American airport and they search your laptop, then maybe a few rounds of various forms of compression would smooth out the noise?

__rkaup__• 15 years ago

Do they scan your laptops now?

plasma• 15 years ago

Web browsers should support built-in checksum verification of downloads (when owners upload md5sum/signatures/etc with the files), instead of having to do it manually.

gcr• 15 years ago

How does the browser verify that the md5sum is correct? The server would have to send the md5sum to the browser through SSL, which is good enough to protect the download anyway.

craz• 15 years ago

I guess if the download is served from a CDN or mirror the checksum would still be helpful.

cookiecaper2• 15 years ago

They should really use BitTorrent as the standard. BitTorrent is popular with people who download lots of large files because BitTorrent is an excellent way to download things. Summary and on-the-fly data verification, simple, reasonable ways to recover in case of corruption (download (approximately) only the corrupted portions, not the whole file again), and easy scaling and load distribution that makes things difficult to topple.

BT is pretty awesome, I'd love to see it become a standard file distribution mechanism.

dsl• 15 years ago

You are confusing checksums with signatures. BitTorrent only verifies that I have a bit for bit copy of the file the torrent was created from, not that the file is an unaltered version of what the author originally released. Additionally, the modern internet no longer needs mechanisms to deal with download corruption beoynd TCP checksums, BitTorrent implements recovery from failed blocks to protect you from a "flaw" of the protocol itself (you can't always trust the origin of the bits).

BitTorrent is also overly inefficient as a download protocol. It only makes sense in situations where you have extremely large flash crowds (WoW for example sending multiple GB to 14 million players in a few days) or the original source isn't in a position (legally or technologically) to source more than a few downloads.

The final nail in the coffin is the fact that a few major CDNs tried peer-to-peer for content delivery. The major broadband ISPs were none too pleased with their last-mile infrastructure (the most expensive part to deploy mind you) being abused. Their networks were designed for consumption, not distribution.

mike-cardwell2• 15 years ago

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

  14.15 Content-MD5

  The Content-MD5 entity-header field, as defined in RFC 1864 [23], is an MD5
  digest of the entity-body for the purpose of providing an end-to-end message
  integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting
  accidental modification of the entity-body in transit, but is not proof
  against malicious attacks.)

    Content-MD5  = "Content-MD5" ":" md5-digest
    md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>

EDIT: I don't know if any browsers actually support this. I just configured an incorrect Content-MD5 header for a page and visited it in Chrome, Safari and Firefox and none of them complained about it.

justincormack• 15 years ago

Amazon S3 uses this, dont think any browsers do. You could file a bug report!

zobzu2• 15 years ago

md5 only ensure data integrity from the download itself if the data has been tampered with, it ensures nothing. the md5 can be changed or even, the file can be made to match the md5 (its broken) gpg/pgp is a much better alternative as you can't create the signature either without having the original key (its not bullet proof as one could store the key in unsafe locations or be hacked of course, but its much better)

mike-cardwell2• 15 years ago

Signing using PGP would be good, but it wouldn't prevent somebody using a replay attack to cause the browser to download an old vulnerable version of an application instead of a new patched version.

TrueCrypt Discrepancy

Related Stories