
TrueCrypt Discrepancy - 16s
http://16s.us/TCHunt/discrepancy/
======
carbonica
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
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)?

~~~
dedward
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.

~~~
icebraining
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.

------
DCoder
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?

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

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

~~~
DCoder
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.

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

~~~
cookiecaper
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
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.

~~~
cookiecaper
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.

------
d0ne
This should be addressed promptly by the TrueCrypt community.

