Home Page
  • April 18, 2024, 02:16:55 am *
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  

News:

Official site launch very soon, hurrah!


Author Topic: Truecrypt 6.0 fixes  (Read 12685 times)

Dakusan

  • Programmer Person
  • Administrator
  • Hero Member
  • *****
  • Posts: 536
    • View Profile
    • Dakusan's Domain
Truecrypt 6.0 fixes
« on: September 28, 2009, 05:31:16 am »

Original post for Truecrypt 6.0 fixes can be found at https://www.castledragmire.com/Posts/Truecrypt_6.0_fixes.
Originally posted on: 07/05/08

TrueCrypt 6.0 [latest version] came out today, and I was looking at the version history. I mention this because I wrote a post about TrueCrypt 5.0 (3 days after it was released, on February the 5th of this year) and the problems I was having with it. I was not aware that after I submitted the bugs to them, they fixed the 2 important ones I reported (See 5.0a history) 4 days after I wrote the post, which were:
  • On computers equipped with certain brands of audio cards, when performing the system encryption pretest or when the system partition/drive is encrypted, the sound card drivers failed to load. This will no longer occur.   (Windows Vista/XP/2003)
  • It is possible to access mounted TrueCrypt volumes over a network.   (Windows)
I am quite impressed that they did this so quickly, and am sad I did not find out until now.  They also fixed the other missing feature I reported to them within a month of that [version 5.1]
  • Support for hibernation on computers where the system partition is encrypted (previous versions of TrueCrypt prevented the system from hibernating when the system partition was encrypted). (Windows Vista/XP/2008/2003)

Also in the version history [5.1a], this little paragraph made me smile
  • [Update 2008-04-02: Although we have not filed any complaint with Microsoft yet, we were contacted (on March 27) by Scott Field, a lead Architect in the Windows Client Operating System Division at Microsoft, who stated that he would like to investigate our requirements and look at possible solutions. We responded on March 31 providing details of the issues and suggested solutions.]

Other very important features they have added for version 6.0 that I am super happy about:
  • Hidden operating systems, which is done in a really well way.
  • Embedded backup header (located at the end of the volume)
  • Up to 20% faster resuming from hibernation when the system partition/drive is encrypted. (As I have always been super frustrated by super slow hibernation resume support on my now abandoned partition encryption software suite, BestCrypt.)
  • Multithreading support (Faster parallel processing, yay)

I did some speed tests of hibernation support in XP and got the following numbers: (Results are averages of at least 5 tests, in seconds)
Test SetupHibernationWakeup
VMWare* w/ no encryption~5.0~6.1
VMWare* w/ TrueCrypt 6.0 full drive encryption~7.5~11
VMWare* w/ TrueCrypt 6.0 decoy & dummy encryption~7.3~13.2
Laptop** w/ no encryption~12.84.8
Laptop** w/ BestCrypt Volume Encryption~92.1~16.6
Laptop** w/ TrueCrypt 6.0 full drive encryption~12.5~13.9
Laptop** w/ TrueCrypt 6.0 decoy & dummy encryption--
*VMWare was running with 256MB of RAM and 1 virtual CPU on Laptop**. VMWare results were not always stable due to other processes on the host machine, so I terminated the worst offenders
**Laptop is a 2.4ghz Pentium Core Duo with 2GB RAM and 60GB hard drive running at 7200RPM


ANYWAYS... The hidden operating system feature really excited me.  Unfortunately, the documentation on it is quite cryptic itself, so I thought I’d try explaining it myself.TrueCrypt hidden operating system diagram
TrueCrypt hidden OS diagram taken from http://www.truecrypt.org/docs/hidden-operating-system.php on 7/5/2008 and belongs to TrueCrypt

The decoy (first) partition holds a decoy OS and is accessible from the password prompt (password #3) at bootup. You should not have any sensitive data in it, and can give out the password if need be. TrueCrypt recommends using this decoy OS at least as much as the hidden OS so if someone checks out the decoy they are not suspicious of it.  If the perpetrator is suspicious of the decoy due to non use, the size of the partition, or just the fact that you have TrueCrypt installed, you may need to fall back onto the second stage of the security in the below paragraph.

The outer (second) partition holds some decoy files and a hidden volume inside of it. It is accessible by either the decoy or hidden OS by opening the partition through a normal TrueCrypt device mounting (password #1). It is recommended to give out its password only if you have already been forced to mount your decoy OS and the perpetrator suspects a secure partition as is explained in the above paragraph. If any data is written to it after creation, it can destroy information at random within the Hidden OS (see “Partition Sizes” at the bottom).

The hidden partition holds its own OS and is hidden within the outer (second) partition. It is accessible from the password prompt (password #2) at bootup or by mounting the partition from TrueCrypt as a device when the decoy OS is open. The decoy partition/OS is NOT accessible while the hidden OS is open.


Basic installation procedure:
  • Create a computer with 2 partitions.  The second (outer) partition must be 5% larger than the first (decoy) for a FAT file system, or 110% (2.1x) larger for a NTFS file system (see “Partition Sizes” at the bottom). You might as well make the outer partition FAT since it won’t be used much, if at all, and this won’t affect the hidden partition.
  • Install your operating system on the first (decoy) partition with all of your applications and data that are not sensitive.
  • Run the TrueCrypt hidden install, this does the following:
    • Asks for outer volume password (Password #1). Creates and formats the second (outer) partition/volume.
    • Lets you copy some “sensitive looking” files to the outer partition.  Nothing should ever be changed or added to the outer partition after this, see “Partition Sizes” at the bottom.
    • Asks for hidden volume password (Password #2). The hidden partition is created within the outer partition.
    • Asks for decoy volume password (Password #3).
    • Rescue disk is created
    • All data from the first (decoy) partition is copied to the hidden partition, and then all data from the first (decoy) partition is encrypted.

And finally, things that bugged me, because I like to vent :-) :
  • Forced creation of rescue disk on full volume encryption. Having the file is more than enough since it can be copied to other hard drives, but it wanted proof of the rescue disc creation, so I just mounted the ISO to a virtual drive.
  • No customized pre-boot screens. This isn’t important really, but I loved my hokie ASCII art ^_^;.
  • Partition sizes: The hidden OS partition will be the exact same size as the decoy and the outer partition must be at least 5% larger for FAT and 110% larger for NTFS than the decoy.

Partition sizes:

The hidden OS partition will be the exact size as the decoy partition because they are originally duplicates of each other, including their original partition tables, which include the size of the partition.

The outer (second) partition that holds the hidden partition must be at least 5% larger for FAT and 110% larger for NTFS than the decoy. The reason for this is the file contents tables. NTFS, unfortunately in this case, stores its file table in the middle of the partition. The outer partition’s file table does not, however, affect the hidden partition in any way.

So, for example (these numbers are theoretical, I am not entirely sure if these are correct), if we have a 2GB decoy partition, the outer NTFS partition must be at least 4.2GB and the hidden partition will be 2GB.  If we made the outer partition 6GB, then 0-3GB would be writable, 3.0GB-3.6GB would be used for the file table, 3.6GB-4.0GB would be writable, and 4.0GB-6.0GB would be used by the hidden operating system. So, theoretically, you could write 3.4GB to the outer volume before problems started occurring, but I wouldn’t trust NTFS to only write to the beginning of the drive.

Logged