How to encrypt partitions with aes128, twofish &c
Forum: DSL Tips and Tricks
Topic: How to encrypt partitions with aes128, twofish &c
started by: WDef
Posted by WDef on June 27 2007,16:11HOW TO - ENCRYPT ENTIRE PARTITIONS WITH LOOPAES, SERPENT128, TWOFISH etc
NOTE: the following requires updated extensions that have now been posted in testing.
Loopaes is the most mature of all linux encryption partition methods. Large amounts of data can be encrypted with loopaes and it is very efficient. A loopaes-encrypted partition is indistiguishable from a partition full of random data.
The old loopaesv1.x that ships with dsl should not be used for encryption (its author says it is broken).
I'm looking for testers for my little tripl frontend, which is included in the loopaes extensions.
This is very easy to use once you get the hang of it.
Here is how to use loop-aesv3.x to encrypt partitions.
- a spare partition containing nothing you want to keep, or just a floppy.
1. Install the following extensions:
loopaes-3.1d-2.4.26knpx.dsl (or the version for 2.4.31 kernels if you are using eg dsl-2.1b).
Open /home/dsl/ gnupg/gpg.conf and add and entry:
This "hardens" gpg for symmetric encryption and is recommended unless you have a very old cpu.
The above will update dsl's obsolete loop driver and add serpent, blowfish and twofish modules in addition to updating mount, losetup, swapon, and swapoff with GNU versions that have been
patched to work with loopaesv3.x (as indeed the originals were - but for old loopaesv1.x).
2. Run "Update_loopaes" from the fluxbox menu.
3. Open a root shell and type:
# tripl -h
to see a list of tripl options.
4. You need to make at least one external key. Do:
# tripl -mkkey
and enter the path and name of your new key at the prompt. You could put it on a usb stick, for example.
Remember the password you enter and use a secure one. That will be the password to your encrypted partition.
Don't lose this key or forget the password, or you'll never recover your data.
It matters little if an attacker gets hold of your encrypted key if they don't have your password. If an attacker has not got your encrypted key, then even having your password (via say a keylogger) achieves nothing.
5. The first time you run tripl you will note it creates an example config file /home/dsl/.triplrc
Have a look at this file, then edit and, in particular, set DEVICE=/dev/your_spare_partition
dsl conveniently has a spare mount point /mnt/test, so set MOUNTPT=/mnt/test
Also set DISABLE_NEW=no since we are going to make a new encrypted partition below. (When enabled this is a "safety catch" to disable making a new loopaes partition, which destroys whatever data is on there).
Other options you can leave at the defaults for now if you wish, or you can change the order of ciphers etc.
Be sure to set key=/path/to/your_key
NB: perhaps don't try multiple encryption if you have an old machine. It's cpu intensive.
Single encryption is fine anyway. For single encryption, just set MODE=1.
6. Ready to make the encrypted partition? Do:
# tripl -new
This first overwrites the whole partition with random stuff - this is necessary so an attacker has difficulty
discerning how full your encrypted partition is with actual data.
Then you will be prompted for your password - enter the password you used to make your external key. The first encryption loop
will get set up. Then tripl will make another key automatically for the next encryption layer - it will prompt
you for another password. Again, pick a secure one and don't forget it. You will be prompted again to confirm,
as when you made your external key above. This will be the password to the second encryption loop. (This second key is embedded in the first encrypted loop and is not external).
You will then be prompted a third and last time to enter your second password so tripl can set up the second encrypted loop. tripl then makes an ext2 filesystem on your encrypted partition.
7. Now you can begin putting stuff on your encrypted partition.
# tripl -m
will prompt for the password to your external key, saying "Setting up loop1 .."
If you enter this correctly, it will say "Setting up loop2 .." and prompt for the password to your embedded
If you enter that correctly, you get:
This means your encrypted partition is now mounted on /mnt/test
So open this with emelfm or whatever and have a look. Inside you'll see an empty directory except for the
lostandfound entry, signifying an ext2 filesystem.
Put whatever you want to keep encrypted in /mnt/test.
8. When you're finished, do:
# tripl -u
to umount and pull down the loops.
9. Once in a while, certainly after an unclean dismount (power outage etc), do:
# tripl -fix
This will run fsck on the encrypted filesystem, thus saving nasty
filesystem errors and possible loss of data.
WHAT HAVE YOU GOT?
If you used the defaults in .triplrc, you now have a double-encrypted partition, encrypted with serpent128 and twofish, using one external gpg-encrypted key for the serpent layer and a second gpg-encrypted key for the twofish layer that is embedded inside the first serpent-encrypted loop.
Embedding the second gpg-encrypted key in this way means it cannot be accessible to an attacker unless they
crack the first serpent layer, and you only need to manage one external key instead of two (less to lose).
Or instead, you can disable embedding in ~/.triplrc and simply make and use 1, 2, or 3 external gpg-encrypted keys (as needed)
before running tripl -new
NOTES AND FURTHER INFO
It's best not to use swap when using encryption. I'll post another how to on encrypting swap with loopaes, which works fine on dsl.
In the meantime, if needed, after using loopaes you can do swapoff, then shred your swap multiple times, then do mkswap and swapon.
gpgpatched.dsl is only of benefit for making keys - you can use your keys thereafter with ordinary gnupg.
blowfish is not supported by tripl because it doesn't work with multiline gpg-encrypted key chains in loopaes.
tripl's main advantage is for making multiple-encrypted partitions and embedding keys easily, running fsck, etc. If you want, you can do everything manually and by
using lines in /etc/fstab as mount options.
While testing tripl, I tried extending the size of the CIPHER array up to the maximum no. of loop devices
(8) and then octuple-encrypted (!!) a partition using 8 different keys and various orders of ciphers. It worked fine.
But this can't be recommended - the more you layer encryption, the more friable the data. And it won't necessarily
give a more secure setup. Three layers seemed a reasonable maximum number. Single encryption is quite secure.
See /usr/share/doc/loop-aes/README and /usr/share/doc/loop-aes-ciphers/README for more info.
Posted by curaga on June 27 2007,16:31Nice
What happened to speed when you used 8 layers?
Posted by WDef on June 27 2007,16:39Ha! To my surprise, my centrino 1.87GHz actually coped with this. I could even play a small mpeg through 8 layers of encryption - cpu utilization was quite high though > 50% and up to 90% as I recall (only when reading or writing). Was slower. Couldn't be a good idea.
Posted by WDef on June 27 2007,16:42[sorry double posting - blasted network gateway timeout]
Posted by WDef on June 29 2007,09:56I've edited the above to make a few things clearer.
Anyone trying this out? Problems, suggestions?
Posted by lucky13 on June 29 2007,13:53
I'm going to try it this weekend, at least on USB sticks or floppies. I'm testing something else crypto-related on my crash-test hard drives now, but I can try to free one up.
Posted by WDef on July 11 2007,13:24Well you apparently didn't try it out, but no matter.
Posted by lucky13 on July 11 2007,21:13Sorry, haven't had much time between work, family, and flooding. It's still on my to-do list if it matters. :-)
Posted by WDef on July 12 2007,09:30Thanks Lucky.
Flooding - let's see, there's so many parts of the world with natural disasters on these days it's hard to pick which one.
Posted by lucky13 on July 12 2007,09:53Try central Texas.
Posted by lucky13 on July 18 2007,20:47WDef:
I was just going to download again and test under DSL 4 but looked again at the info files and was reminded each version is for a previous kernel (2.4.26 and 2.4.31), not 2.4.34. I'll try later tonight on 2.1b when I'm in front of that computer again.
edit: Oh yeah, any plans for a 2.4.34 version yet?
Posted by WDef on July 23 2007,13:44
Yes, but not right now.