6 ms·

TrueCrypt Discrepancy

150 points by 16s 15y ago

d0ne 15y ago
This should be addressed promptly by the TrueCrypt community.
- deleted 15y ago
  [deleted]
  - deleted 15y ago
    [deleted]
DCoder 15y 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 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?
- deleted 15y ago
  [deleted]
- mquander 15y ago
  That makes sense, since the installer has compressed its contents.
- 16s 15y ago
  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
  - DCoder 15y 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.
  - DCoder 15y 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.
deleted 15y ago
[deleted]
carbonica 15y 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 15y 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 15y 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.
    - LeonB 15y ago
      for example, record an mp3 where you sing the 1's and 0's that comprise the encrypted data.
plasma 15y 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 15y 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 15y ago
    I guess if the download is served from a CDN or mirror the checksum would still be helpful.
- cookiecaper 15y 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 15y 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.

150 points by 16s 15y ago

d0ne 15y ago

This should be addressed promptly by the TrueCrypt community.

deleted 15y ago
[deleted]
- deleted 15y ago
  [deleted]

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

deleted 15y ago
[deleted]
mquander 15y ago
That makes sense, since the installer has compressed its contents.
16s 15y ago
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
- DCoder 15y 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.
- DCoder 15y 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.

deleted 15y ago

[deleted]

carbonica 15y 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 15y 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 15y 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.
  - LeonB 15y ago
    for example, record an mp3 where you sing the 1's and 0's that comprise the encrypted data.

plasma 15y 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 15y 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 15y ago
  I guess if the download is served from a CDN or mirror the checksum would still be helpful.
cookiecaper 15y 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 15y 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.