[linux-lvm] LVM and Truecrypt

[Sven Eschenberg]

Hi Gordon,

The kernel crypo API carries a vast selection of ciphers, hash functions 
and mode of operation (or rather block chaining algorithms). Most of 
them are used for ipsec too (ciphers and hashes), thus I am somewhat 
confident they are rather well revised. if you use a precompiled kernel, 
just do a cat /proc/crypto, it will list, what's available, if the 
ciphers etc. are modular, you might need to modprobe the modules you 
plan to use first.

I personally use luks headers, for easier handling, because I can assign 
keys via UUIDs, by plugging in a usb stick during boot (you could aswell 
probably write an init-script that waits for the keys to be transmitted 
via network ...)

The problem with volumes >>1TB seems to be 'omnipresent' cbc-essiv etc. 
show the same weakness, from what I gathered (I am no expert here), this 
  is a general consideration, if you have enough data for a statistical 
attack chances get bigger to break the encryption, if an adversary is 
able to write data to the device, and thus knows the unencrypted data 
aswell as the encrypted data. There seems to be a new mode of operation 
(or algorithm for block chaining) which reduces those chances further.

There was a discussion on the dm-crypt list, to automatically slice huge 
volumes in chunks, and use key splitting (or some sort of derivation) to 
get multiple keys for the chunks.

I chose another option, let's assume you haave n disks, let's call them 
/dev/sda through /dev/sdn for now. create an encrypted blockdevice via 
dm-crypt for each of those, for the sake of easiness we give them 
symbolic names, let's say crypt-a through crypt-n, with n different 
keyys. (On the assumption that every physical device is smaller than 
1TB). The crypted blockdevices behave exactly like physical disks, thus, 
you can partition them, or you can create PVs for LVM usage, or you can 
use md(raid) to form a raid volume out of them.
You can stack md/devmapper/dm-crypt devices on top of each other as you 
please, but always consider, more layaers could potentially produce 
errors, if any of the layers might have a bug/failure, this should be 
taken into account, tough it's a locigal thing.
Advantages of such a setup are:
1.) each disk has an own key, thus you need to break n keys, if you want 
to acces ALL data in clear
2.) no matter if the crypto algorithm is parallelized, each disk gets 
it's own dmcrypt kernel thread, which in turn can be scheduled onto 
different cores and cpus, thus yielding in a better performance, if you 
have multiple cores/cpus and the algorthim itself is not prallelized.
But it needs a little more work in the setup, since you need to provide 
multiple keys.

Example for clarification:


/dev/sda becomes /dev/crypta, /dev/crypta can be used like /dev/sda, 
after providing the key, cipher algorithm etc. to cryptsetup.
Now instead of putting your PV Header/Metadata onto /dev/sda, you use 
/dev/crypta, thus the metadata gets encrypted aswell as all the data in 
the PV. The PV's Metadata holds information about your VolumeGroup and 
Logical volumes, in your case as I understood it, you will have one 
VolumeGroup consisting of those n dm-crypt devices, and one 
LogicalVolume, with one giant filesystem.

If you wanna access files from windows easily, you'd then setup samba, 
and export the filesystem or directories in the filesystem via samba.
Make sure, you use a filesystem with ExtendedAttributes/Posix ACLs, have 
support for it in the kernel and in samba. If you set it up properly, 
you can access the volume or the directories exported, from windows, you 
can even manage user permission on the filesystem from your windows 
client, in the same manner you can on local disks. This will need some 
fiddling and testing around, but I can assure you it works :-).

 From what I know, luks/dm-crypt support is tied pretty well into 
ubuntu,  eventually check the ubuntu wiki, there's some articles for 
setting up dmcrypt etc. right from the beginning, if you'd want to hold 
the actual system on those crypto devices and boot of them aswell, for 
the latter, you need to choose some alternate setup media if I remember 
correctly.

Personal sidenote: Nopes, nevr made it to CCC unfortunately, but it's on 
my agenda, of things a man should do in his life :-)


Hope my mail helps a little in understanding possible setups ;-).

Regards

-Sven


Gordon Fogus schrieb:
> 
> Sven Eschenberg: "Concerning encryption, I was asking, because if you 
> use linux as OS on your NAS and linux solely, you could use dmcrypt 
> (which is used by truecrypt on linux too, if available) which gives you 
> more options on encryption etc. (Choose any cipher from the kernel 
> crypto api, luks key managment ...). This is usually integrated far 
> better into distributions, than truecrypt."
> 
> Wow, Linux has built in crypto.  Windows has... :(  I will check this 
> out.  I guess this means I need to get used to typing into the command 
> box to do everything.  I am using a 6TB RAID5 currently (5TB usable).  I 
> find it unbearably slow compared to my 4TB RAID0+1 (2TB usable).
> 
> Sven Eschenberg: "In case you want to avoid the luks header (since it 
> indicates some info on the crypted volume, offers multiple key slots 
> etc.) you can still revert to non-luks mode with dm-crypt and still 
> enjoy all the ciphers from the kernel (and modes of operation)."
> 
> Yes, I would definitely prefer not to have a header that says: "Secrets 
> lurk beyond".
> 
> Sven Eschenberg: "Concerning truecrypt: Truecrypt always uses XTS afaik, 
> you certainly would not want to encrypt a 10 TB volume with that.
> (http://en.wikipedia.org/wiki/XTS#XTS)"
> 
> Ohhhh bother!  You sound like you know crypto better than I.  What mode 
> of operation do you recommend?  Is there a distro you would recommend 
> for crypto above others?  I was thinking of using Ubuntu because it has 
> such a large support base.
> 
> Sorry, I didn't look at your address.  I was in Frankfurt a few years 
> ago.  Have you been to CCC ever?
> 
> Gordon
> 
> 
>