polywogsys

OK. So I tried to check out the new version of TrueCrypt for linux (5.1a)... plainly... it sucks. They forced a GUI using wxWidgets (which I've never gotten to work successfully for programs which need to be compiled, particularly wxPython). And that's just the "first" problem I've encountered. Apparently, lots of people hate the new version, and a lot of the features are stripped out of it.
Someone who's spent more than three hours trying to get it to work posted the following on truecrypt's forums:

PostPosted: 15 Mar 2008 Sat 00:15 [Link to This Post] [Report to Admin] Reply with quote

Before I begin my review of Truecrypt 5.1, You should know that I am not new to encryption. I have been using truecrypt 4.3 first on windows and then on linux with good results. Everything I do on this machine is automatically encrypted after login. While truecrypt without a gui was difficult to use at first, as I learned the commands it actually became easier and more efficient to use. Always, I found it to be fast, responsive and seamless.

Today, I installed truecrypt 5.1 on an older machine, to test it out. The experience has been so unforgivably horrible, that I have had to revert to 4.3 just to accomplish the most basic of tasks. I found myself writing a list of everything wrong with this version so as not to forget something.

As a linux user, there is a lot to find attractive in version 5. For example, Mounted volumes appear in the side pane of Nautilus. The graphical user interface has been ported from windows. When selecting a drive to encrypt, the GUI will list the size of each partition preventing the horrible of mistake of typing /dev/sdb instead of /dev/sdc. However, if you don't want to use the GUI you will have to type truecrypt -t before every command. This quickly gets tiresome. If I wanted to launch the GUI, I wouldn't have typed $truecrypt in the command line, would I. This became so tiresome that I was forced to create a wrapper to prevent the damned little GUI windows from launching every time I did anything in the command line.

If you are confused about any of the new features in truecrypt, don't expect to go to the man pages. What once existed in truecrypt 4.3 seems to have been erased. The 'Help' function doesn't work either. Other annoyances to add to the list: 1. The icon for truecrypt that appears in the sytem tray, disappears the moment you close the program. 2. Double clicking on a drive is supposed to open a file explorer window of the drive. It doesn't even fail, it just sits there doing nothing. 3. $truecrypt -d # doesn't appear to work anymore. 4. Even in text mode, you will have to dismiss more questions to accomplish basic tasks. 5. I couldn't mount unformatted volumes from the command line. (more on this in a bit)

These annoyances are not the worst of it. The structure of truecrypt has been so fundamentally altered that I couldn't even do a relatively simple task: create an XFS encrypted volume on an external drive.

After creating the encrypted volume, I attempted to load it so I could make the XFS filesystem. ( Why truecrypt can't give me this option when I first created the volume is a mystery to me. only the FAT filesystem is available) After typing in my long password, truecrypt refused to let me load it because the partition had no filesystem. Of course it doesn't! I haven't formatted it yet! Instead of letting me mount it anyway I had to type in the entire password again, but this time click the button more options and select "do not mount." Grr.

I opened Gparted, my favorite disk formatting utility, but it seems truecrypt has changed the way it works. Instead of mount volumes on /dev/truecrypt? It now mounts them on /dev/loop? This means that truecrypt volumes don't show up in Gparted anymore. It also destroys all old scripts that I had built to work with truecrypt. "Okay", I thought, I'll just have to use the command line $mkfs -t xfs /dev/loop? This work for the first few innodes, but then stalled on 28/1100. "Stalled" is to weak a word, it completely FROZE the entire computer forcing me to do a hard reboot.

Regardless, I pressed on. I created the XFS filesystem using a different computer that still had the GOOD truecrypt installed. Then, I mounted the volume with BAD truecrypt and attempted to copy some files. It was 60 MiB in when it completely FROZE the computer once again. I watched as the time remaining counter started count up. The message box was saying 400 HOURS estimated before I had enough and did a hard reboot again. It's as if the entire driver has been rewritten and the result is EPIC FAIL. This reminds me of the problems experienced by Windows Vista users.

By this point, I had had enough. I reinstalled truecrypt 4.3 and did everything I mentioned earlier. The volume formatted flawlessly and the file copy only took a few minutes. Suffice it to say, I will not be going back anytime soon. The minor annoyances, I could have worked around for the easy use of the GUI. But to fail so completely at the most basic task. That is simply unforgivable.

So I've been following the recent (ish) threads on the truecrypt forums about the futility of doing, what I wanted to do: namely create a truecrypt volume the size of the cd/dvd, copy a bunch of data on to it, then burn the entire thing to cd/dvd.

I was able to do this... However, I ran into a problem with truecrypt in that when I tried to do:

# truecrypt /dev/scd0 /mnt/foo
device-mapper: reload ioctl failed: Invalid argument
Command failed
# dmesg
device-mapper: table: 253:0: truecrypt: truecrypt: Device lookup failed
device-mapper: ioctl: error adding target to table
device-mapper: ioctl: device doesn't appear to be in the dev hash table.

So the forums had this thread about some guy asking for this feature. He assumed that just because you can't read the disc, that would be enough for plausible deniability. However, someone replied:

I think that would be a spurious claim and wouldn't fool many, especially if it was suspected that you used encryption technology.

Discs can go bad and become unreadable, sure, but they do not do so in such a way as to become completely random volumes. Don't forget that the sectors themselves will still be very much readable (as in, without producing read errors, although the data remains indecipherable).

A fully readable, verifiable optical disc full of random data would be suspect. As a "bad burn" would be terribly unlikely to result in a completely random disc. Moreover, that the disc itself is not physically damaged, and the ECC data contained in each sector of the disc verifies that the data is correct, would be a strong indicator that the data placed on the disc was not the result of an accident.

And another continued...

The reason why I would like to see this implemented is related to plausible deniability (yes, that again).

As I said before on several occasions, plausible deniability is not really plausible on Read Only Media. This is particularly true for the hidden volume feature (burning a half empty outer volume on a DVD is suspicious. Why loosing so much space?).

Here is how it could be remedied with "Raw CD/DVD encryption". Roughly:

• Burn your 700 Mb (or so) volume on a CD-RW in "RAW mode" (let's call it that).
• Check whether hidden volume is accessible. (Say hiden volume is 300 Mb and outer volume is empty)
• Burn 400 Mb of data on the same disk the ordinary way (this data would be accessible to anybody exploring the CD).
• Part of the outer volume is now destroyed, but the hidden volume remains intact and should still be accessible in "RAW mode".
• Somebody exploring the disk would just see 400 Mb of ordinary clear text + (only if curious enough to check) unallocated random data at the end of the disk.

If asked for a reason why there is so much free space at the end of your CD, say you intended to burn more data later.

If asked for a reason why there is random data at the end of the disk, just shrug shoulders: "Hum... It must be someting I've burnt before on this disk... A compressed backup? Something with an exotic format? Can't remember what. Perhaps could you analyse it and tell me?"

Playing with ISO image would probably more efficient than the process described above.
– Little Fish

But apparently, there is a way to do it (if you wanted to) anyways. You would need to do the following:

# losetup /dev/loop0 /dev/scd0
# truecrypt /dev/loop0 /mnt/foo

So... if all you want to do is burn an encrypted disc (like of your financial files, or other personal information), it might be easier to use cryptoloop device. BUT if you want to hide data from other people and deny it exists by encrypting it, RW media with a hidden volume is your best bet.

Ugh, so truecrypt works for linux, and windows, but there's no truecrypt for the mac. :-\ Yeah, I know, you can use Disk Utility to create an AES encrypted imagefile, but I wanted something more portable... maybe it's a project idea?!
I haven't even written kernel code for linux, much less try my hand at one for the mac.

Create a keyfile. This could be anything (i.e.: dd'ing /dev/urandom would work, or an mp3 file, etc.)

truecrypt --keyfile-create asdf.key --random-source /dev/urandom

The following creats a 1 Mb normal (not hidden) unformatted volume encrypted with AES, and RIPEMD-160 hash. It uses /dev/urandom for the random number generator. It will display the primary and secondary volume keys after creating the encrypted volume using the keyfile asdf.key. The file it creates is called asdf.tc.

truecrypt --size=1M --type normal --filesystem none \
 --hash RIPEMD-160 --encryption AES --random-source /dev/urandom --display-keys \
 -k ./asdf.key -c ./asdf.tc

Map the volume, but don't mount it. This way we can format the volume whatever format we want. In our case Ext2.

truecrypt -k asdf2.key asdf.tc

Find out what our 'raw' device name is: /dev/mapper/truecrypt??

truecrypt -vl

Format that raw device

sudo /sbin/mke2fs /dev/mapper/truecrypt1

Unmap the volume

truecrypt -d

Mount the volume.

truecrypt -k asdf2.key asdf.tc /mnt/floppy/

Unmap/Unmount all volumes

truecrypt -d

In order to get the files you need for making any module but more specifically TrueCrypt module working (assuming that you are using the Fedora 7 stock, or updated, Kernel): http://www.mjmwired.net/resources/mjm-fedora-fc6.html#kernelsrc
There are 3 basic steps involved in installing the kernel source.
1. Download the desired kernel source (matching your current kernel if required)
sudo yum install yum-utils
yumdownloader --source kernel
2. Installing the SRC.RPM package
sudo rpm -ivh kernel-2.6.23.1-21.fc7.src.rpm
3. Using rpmbuild to prepare the source into a usable state
sudo rpmbuild -bp --target=$(uname -m) /usr/src/redhat/SPECS/kernel-2.6.spec

Now, it's ready for the truecrypt part.

4. Edit truecrypt's truecrypt-4.3a-source-code/Linux/build.sh file to point to a different KERNEL_SRC:
KERNEL_SRC=/usr/src/redhat/BUILD/kernel-2.6.23/linux-2.6.23.i686
5. Edit line 659 of truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.c to comment out the last "NULL" argument to kmem_cache_create. It should read: bio_ctx_cache = kmem_cache_create ("truecrypt-bioctx", sizeof (struct bio_ctx), 0, 0, NULL/*, NULL */);

But alas!!
# modprobe truecrypt
FATAL: Error inserting truecrypt (/lib/modules/2.6.23.1-21.fc7/extra/truecrypt.ko): Invalid module format

So I did a 'dmesg' and the error was: truecrypt: version magic '2.6.23.1-21.fc7 SMP mod_unload PENTIUM4 4KSTACKS ' should be '2.6.23.1-21.fc7 SMP mod_unload 686 4KSTACKS '

This is because even though I downloaded and configured the kernel sources (above). It still "looked" at kernel-devel for the kernel config etc. It so happened that when I ran make config in /usr/src/kernels/2.6.23.1-21.fc7 i changed the processor type to Pentium4. Not knowing what else I had changed, I decided to uninstall/reinstall "kernel-devel". When I rebuilt it, and modprobed truecrypt it worked fine.