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
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
