TrueCrypt Discrepancy(16s.us)
16s.us
TrueCrypt Discrepancy
http://16s.us/TCHunt/discrepancy/
5 comments
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.
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.
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?
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.
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.
I found the idea of file histogram very interesting so I searched and found this nicely working Python script: http://www.cutawaysecurity.com/blog/file-content-histograms (needs Python2)
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)?
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.
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.
The problem with full disk encryption with an hidden volume is that if any program starts writing over the 'invisible line' of the normal volume (by which I mean, the size you configured for it), it'll overwrite the hidden data.
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.
for example, record an mp3 where you sing the 1's and 0's that comprise the encrypted data.
"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...
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...
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...
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...
The oversized volume argument seems a bit silly. Does that mean owning a 1TB hard drive is suspicious if you're only using 50GB worth of space?
No, but that's not the scenario we're talking about.
If you a) have an encrypted chunk of data that's 1TB, b) when subpoenaed, hand over only 50GB worth of data, and c) are using a tool that is known of it's ability to offer "hidden volumes" to supply plausible deniability, you can be damn sure that a judge is going to find that suspicious.
The more relevant question is: is it suspicious enough to permit the judge to issue a contempt citation? Well, that's a question for the lawyers, but I'd sure as hell hate to be the test case.
If you a) have an encrypted chunk of data that's 1TB, b) when subpoenaed, hand over only 50GB worth of data, and c) are using a tool that is known of it's ability to offer "hidden volumes" to supply plausible deniability, you can be damn sure that a judge is going to find that suspicious.
The more relevant question is: is it suspicious enough to permit the judge to issue a contempt citation? Well, that's a question for the lawyers, but I'd sure as hell hate to be the test case.
I haven't used TC in a long time but don't you determine the size of the volume/container when you create it, not when you put data into it? That would mean it's entirely believable that you created a larger (1TB) volume with future use in mind but have yet only had a need for a part (50GB) of it.
This is correct, the container won't expand in size. You have to specify the size at time of creation.
Of course that's the scenario we're talking about. Having a big volume is about as relevant as a big hard drive. Would you buy a 250GB drive when the 1TB version is the same price (or less)? Of course not. Bigger is better. So why would you create a small encrypted volume when you have boatloads of diskspace to spare?
And no, that's not how contempt works. IANAL but Wikipedia says this: To prove contempt, the prosecutor or complainant must prove the four elements of contempt: Existence of a lawful order The contemnor's knowledge of the order The contemnor's ability to comply The contemnor's failure to comply
There's no way to prove your ability to comply with decrypting a hidden volume for as long as it remains hidden.
And no, that's not how contempt works. IANAL but Wikipedia says this: To prove contempt, the prosecutor or complainant must prove the four elements of contempt: Existence of a lawful order The contemnor's knowledge of the order The contemnor's ability to comply The contemnor's failure to comply
There's no way to prove your ability to comply with decrypting a hidden volume for as long as it remains hidden.
There was a post on Reddit about this a few days ago.
http://forums.truecrypt.org/viewtopic.php?t=23969 Comments: http://www.reddit.com/r/reddit.com/comments/i8dqh/true_crypt...
http://forums.truecrypt.org/viewtopic.php?t=23969 Comments: http://www.reddit.com/r/reddit.com/comments/i8dqh/true_crypt...
I misunderstood. I see your point now, but I still see good alternatives. Use an external hard drive, easy excuse for having a large encrypted drive. Tell them you just started using it, or made it big and then never decided to use it again, etc.
Of course having an external hard drive works... as long as you're confident enough to lie well.
Hopefully you paid cash, otherwise, they'll know when you bought it. That means no NewEgg. Damn.
Then, you just need to be comfortable saying that you bought a 1TB hard drive, encrypted the whole thing (despite the obvious speed hit it'll take, which you know if you're smart enough to use TC), just to throw a few gigs of porn on it. Hopefully you have a wife or significant other, since no single guy is going to encrypt his porn. Not sure how women treat their porn stashes; it just has to be believable. Also, make sure you don't load the porn on all at once - that'll be very, very suspicious. It'll have to look like an organically-grown stash.
Given all that, if you can lie well, you might be able to convince an investigator that you (as a suspect in something) have an innocent hard drive on your hands. And you should practice, because if the cops aren't convinced and can't force you to hand over the password (due to plausible deniability), you'll probably need to convince a jury.
Hopefully you paid cash, otherwise, they'll know when you bought it. That means no NewEgg. Damn.
Then, you just need to be comfortable saying that you bought a 1TB hard drive, encrypted the whole thing (despite the obvious speed hit it'll take, which you know if you're smart enough to use TC), just to throw a few gigs of porn on it. Hopefully you have a wife or significant other, since no single guy is going to encrypt his porn. Not sure how women treat their porn stashes; it just has to be believable. Also, make sure you don't load the porn on all at once - that'll be very, very suspicious. It'll have to look like an organically-grown stash.
Given all that, if you can lie well, you might be able to convince an investigator that you (as a suspect in something) have an innocent hard drive on your hands. And you should practice, because if the cops aren't convinced and can't force you to hand over the password (due to plausible deniability), you'll probably need to convince a jury.
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?
Do they scan your laptops now?
No.
Unfortunately the answer is not "no", but rather "no for most people, yes for some people".
I am curious about this - can you link me to some stories of regular traveler's having their laptop hard drives scanned by the TSA?
Jacob Appelbaum (of the Tor project) has been detained multiple times at the US border already, and at least one time has had his electronic equipment taken away.
The wikipedia article about him has a section about it that should lead to some more sources: http://en.wikipedia.org/wiki/Jacob_Appelbaum#Investigation_a...
Granted, he's not a "regular traveler", but then again, it shouldn't matter if you're famous or not.
The wikipedia article about him has a section about it that should lead to some more sources: http://en.wikipedia.org/wiki/Jacob_Appelbaum#Investigation_a...
Granted, he's not a "regular traveler", but then again, it shouldn't matter if you're famous or not.
Here's a lawsuit about it, with some statistics:
http://www.aclu.org/free-speech-technology-and-liberty/group...
http://www.aclu.org/free-speech-technology-and-liberty/group...
Look up Jacob Appelbaum aka ioerror.
Yes. This has been happening for a long time:
https://www.nytimes.com/2006/10/24/business/24road.html
The 9th circuit court already ruled it permissible.
The Association of Corporate Travel Executives put out this warning:
"ACTE’s advice to business travelers states:
1. That you should not carry any confidential, personal information that you do not want examined by third parties on your computer – or other electronic devices. This includes financial data, photographs, and email stored on computers, wireless phones, Blackberries, or iPod-type devices.
2. That you should limit the amount of proprietary business information you carry on your computer, and that it be transmitted before crossing the border so you have access to it in the event your unit is seized.
3. If your laptop also serves as your major home computer, get another one for travel purposes.
4. The Association of Corporate Travel Executives is not advising travelers to hide data from U.S. border authorities, but to take steps to minimize the impact of its loss, or the inability to access it, in the event it is seized."
Source: http://www.eturbonews.com/2264/ninth-circuit-court-rules-bor...
The 9th circuit court already ruled it permissible.
The Association of Corporate Travel Executives put out this warning:
"ACTE’s advice to business travelers states:
1. That you should not carry any confidential, personal information that you do not want examined by third parties on your computer – or other electronic devices. This includes financial data, photographs, and email stored on computers, wireless phones, Blackberries, or iPod-type devices.
2. That you should limit the amount of proprietary business information you carry on your computer, and that it be transmitted before crossing the border so you have access to it in the event your unit is seized.
3. If your laptop also serves as your major home computer, get another one for travel purposes.
4. The Association of Corporate Travel Executives is not advising travelers to hide data from U.S. border authorities, but to take steps to minimize the impact of its loss, or the inability to access it, in the event it is seized."
Source: http://www.eturbonews.com/2264/ninth-circuit-court-rules-bor...
Thank you for the clarification.
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?
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?
That makes sense, since the installer has compressed its contents.
Several files were added to the .rsrc/BIN folder. See the second screenshot here.
http://16s.us/TCHunt/discrepancy/Screenshot2.png
http://16s.us/TCHunt/discrepancy/Screenshot2.png
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.
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.
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.
[deleted]
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.
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>
Amazon S3 uses this, dont think any browsers do. You could file a bug report!
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.
BT is pretty awesome, I'd love to see it become a standard file distribution mechanism.
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.
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.
I didn't confuse checksums and signatures. I understand the difference between a checksum and a cryptographic signature. I'm sorry if "verification" was used outside its normal context, I just felt it was the best descriptor.
Secondly, there's been multiple times where I've downloaded a large file and found it was corrupted. Under conventional protocols you can't easily identify the part that is damaged, so even if it's only a small part (because WiFi dropped or whatever), you have to redownload the whole thing. Instead of doing that, I have just created a torrent, uploaded to openbittorrent, and downloaded the few megabytes I still needed.
I agree it may not be worth it to torrent small files (maybe <50MB), but I am not so pessimistic. As far as ISPs go, they just have to accept that their customers are going to be uploading much more than they have been and provide whatever infrastructure upgrades are required. I have no pity for that situation and I don't think it's a valid excuse to not see wider-spread usage of BitTorrent as a conventional download mechanism (i.e., baked into browsers, looks like a HTTP download). They can even default browsers to upload at a low rate, like 5Kb/s, or even 0Kb/s, and be fine; the benefits we're discussing now are inherent in the protocol, not necessarily the size of the swarm; we can still expect content providers to provide the machines that upload all of their content and allow seeding as opt-in only, and see big improvements from the usage of the BitTorrent protocol.
Secondly, there's been multiple times where I've downloaded a large file and found it was corrupted. Under conventional protocols you can't easily identify the part that is damaged, so even if it's only a small part (because WiFi dropped or whatever), you have to redownload the whole thing. Instead of doing that, I have just created a torrent, uploaded to openbittorrent, and downloaded the few megabytes I still needed.
I agree it may not be worth it to torrent small files (maybe <50MB), but I am not so pessimistic. As far as ISPs go, they just have to accept that their customers are going to be uploading much more than they have been and provide whatever infrastructure upgrades are required. I have no pity for that situation and I don't think it's a valid excuse to not see wider-spread usage of BitTorrent as a conventional download mechanism (i.e., baked into browsers, looks like a HTTP download). They can even default browsers to upload at a low rate, like 5Kb/s, or even 0Kb/s, and be fine; the benefits we're discussing now are inherent in the protocol, not necessarily the size of the swarm; we can still expect content providers to provide the machines that upload all of their content and allow seeding as opt-in only, and see big improvements from the usage of the BitTorrent protocol.
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)
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.
Signing moves the problem elsewhere. The problem then becomes the key exchange. How do I, as a first time downloader, know that the key listed on the website is the correct one? It's the same problem SSL has, sure, there's a key, and your browser trusts it, but how do I know that this key can really be trusted?
[deleted]
"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.