The canonical implementation of the TrueCrypt encrypted container format is developed in a secretive way by anonymous hackers. This upsets some people who are not comfortable with their encryption software being developed by unknown people. Fortunately, there are alternative implementations of the TrueCrypt format, particularly on Linux and BSD platforms. (NOTE: there are Windows implementations as well, but I don’t use Windows, so I don’t know anything about them).

dm-crypt: Linux Kernel Encrypted Data Storage

The Device Mapper is the Linux kernel infrastructure which enable arbitrary data stores to appear as block devices. The dm-crypt module provides transparent encryption as a Device Mapper layer. Any block device (including loopback devices) can be mapped by dm-crypt as a transparently encrypted virtual block device under /dev/mapper.

This is a powerful kernel module for working with encrypted data stores. It abstracts the entire encryption handling into the kernel and allows the userland programs to treat the encrypted data container as a simple block device, just like any other. UNIX philosophy for the win!

tc-play: TrueCrypt for dm-crypt

A DragonflyBSD developer did a complete reimplementation of the TrueCrypt container format using the dm-crypt module to handle the crypto. In the process of developing his reimplementation, he discovered some inconsistencies between the TrueCrypt documentation and the actual container format.

tc-play GitHub

cryptsetup: Swiss Army Knife of Disk Encryption

The cryptsetup tool is vital to the functioning of encrypted disks on Linux. Originally only supporting some lame on-disk format, cryptsetup was later updated to implement LUKS.

LUKS is a hardened on-disk encrypted key storage designed to withstand bruteforce and forensic attack. It uses multiple key slots to allow multiple passphrases to decrypt, uses a strong master key to decrypt the drive contents, and is generally pretty awesome as an encrypted container format.

If you read nothing else, read the cryptsetup FAQ which is full of information about securing an encrypted drive.

For a while now cryptsetup has supported the TrueCrypt container format along side the native, and far superior, LUKS format. The TrueCrypt support is available as tcrypt and I’ll have to look into that more. See how to mount a TC container using cryptsetup.

stlth: stealth, the stego crypto container thats a cryptsetup shellscript

In 2009 or 2010 someone decided to wrap some of the awesome features of cryptsetup in a simple shell script, enabling humans to actually take advantage of these features. It was such a complicated process he lost all the vowels.

The one particularly cool thing about stlth is that it enables hidden storage, similar to TrueCrypt’s hidden container. You have to manually enter the offset for the hidden container, which is a bit brittle and error prone.

stlth source code is on sourceforge, although both stlth and sourceforge are basically dead.

Tomb: cryptsetup wrapper shellscript, part deaux

The Tomb project is actually really cool. They have done a lot of work to make the power of cryptsetup accessible to mere mortals. In the process, they have incorporated some very sound best practices, what I would call a robust SOP for handling encrypted data stores.

The major innovation with the Tomb software is the separation of the data store (the tomb) from the key. Tomb, like TrueCrypt, allows multiple files to be aggregated and used as the unlocking passphrase. Tomb goes further by forcing the user to keep the decryption key in a separate PGP encrypted file (the .key). The user can now store the key in an arbitrary location, separate from the encrypted container. `Tomb` supports using `steghide` to keep the key inside a JPEG. You can even pull the key file over Bluetooth when you unlock the tomb! If that doesn’t give you devious thoughts, get out of the hacking business, this is no place for you.

Tomb home. There is a github, but the src is old. The github wiki has interesting stuff though. The most relevant guide to using Tomb is probably the crunchbang paranoid computer user guide, which you should read anyway. It is quite comprehensive.

Conclusion

There are finally alternatives to the problematic TrueCrypt. TrueCrypt has development issues, performance issues, and poor file system support (FAT32, in 2013? are you joking?). There are also questions about whether crypto-cascades are voodoo crypto and whether a good password hardening scheme combined with AES is enough. Personally, I’ll take AES256-XTS-plain64 performance and security over TrueCrypt voodoo any day.