# Replacing LUKS with TrueCrypt?

## wswartzendruber

So with TrueCrypt (seemingly) having the edge with all this randomized encryption and plausible deniability, are there any obvious caveats with placing TrueCrypt in initramfs and using that instead of LUKS to map and mount encrypted volumes?

----------

## Sadako

"randomized encryption"?

Honestly, I really don't think there's much you can do with TrueCrypt that you can't do with cryptsetup (with or without LUKS, which I think is a little overrated...).

First of all, the "cascading ciphers", you can do this with cryptsetup relatively easily, for example "Serpent-Twofish-AES" on /dev/sda3;

```
cryptsetup -s 512 -c serpent-xts-plain create v1 /dev/sda3    

cryptsetup -s 512 -c twofish-xts-plain create v2 /dev/mapper/v1

cryptsetup -s 512 -c aes-xts-plain create vault /dev/mapper/v2
```

which will give you /dev/mapper/vault, which should be just as "cryptographically strong" as it's truecrypt equivalent, aside from key management where you have a whole host of different options (LUKS being one of them).

I've been playing around with the above a bit, and I've actually been meaning to start a topic on it here for discussion, but it appears to work just fine.

wrt to plausible deniability, I presume you are reffering to "Hidden volumes"?

All this is is having a normal partition with a standard filesystem on it, taking up lets say 60% of the drive, and then another encrypted filesystem in the remanider.

Completely overlooking for the moment that this is just "security through obscurity", as any half competent tech should be able to discover that the unencrypted filesystem is far smaller than the partition it is residing on, and that the rest of the partition is full of "seemingly random" data, this too is easily doable with cryptsetup, via the --offset or the --skip options.

I've played with this too, and IIRC the only problem I had was that I could not have both the unencrypted filesystem mounted and the cryptsetup mapping set up at the same time, but this was actually in the very early days of dmcrypt, so it may very well have changed since...

I really can't comment on the "randomized encryption" unless you elaborate on it a bit, but I do kinda adore cryptsetup/dmcrypt for a number of reasons, one of the main ones being it's flexabilty.

You can even change the ciphers and/or the key used to encrypt a volume, albiet with `dd` doing quite a bit of work...

----------

## wswartzendruber

Randomized encryption is where the keys are randomly generated and stored in the partition's header.  This header is then encrypted using a key (or hash thereof) that you supply.  This technique has the attribute that every part of the partition (header and otherwise) is random.  The data cannot be identified as encrypted vs random.  Even though it is assumed that the data is encrypted, it is theoretically impossible to tell which utility (much less algorithm) was used.

----------

## tkmorris

Any news?   :Rolling Eyes: 

----------

## jmz2

If you use initramfs to mount "unallocated" disk space, it is not "plausible deniability" as the initramfs operation is proof enough that you have encrypted partition hidden on the disk. Plausible deniability is only plausible if it's not obvious to an observer that there is in fact an encrypted partition hidden on the disk.

Besides, I think it's far better to have a "normal" Linux on a normal partition, and store sensitive information on a truecrypt volume you mount on demand. If you need to protect home directories, use dmcrypt or somesuch.

----------

