Uwe Hermann - HOWTO: Disk encryption with dm-crypt / LUKS and Debian [Update] - Comments

Try ATA over ethernet

Hans Bausewein — Tue, 12 Jan 2010 08:28:00 +0100

If you are installing on a slow laptop and have a fast machine on the local network, try ATA over ethernet:

Here it depends on the speed of my 100Mb ethernet. I run the urandom on a quad core AMD64 machine and fill the disk partition on a Pentium-M 1.6 GHz laptop.

Hans

yast

Vladimir — Sun, 22 Nov 2009 11:27:00 +0100

How I can mount my home directory encrypted by yast in opensuse without yast? (my system cann't start!, now I install kubuntu)
I have:
/home/user
/home/user.img (2Gb)
/home/user.key (288b)
?

Tutorial for encrypting a working disk with remote access only?

Mango — Sun, 18 Oct 2009 12:43:09 +0200

Newbie here that has been looking for a 'complete' tutorial how to encrypt a drive that:
1. Only have remote access to, login is done via SSH, no GUI.
2. Already existing programs and users on the site
3. Just want to encrypt sensitive areas not entire disk as told that to do would make it almost impossible for a newbie to do and still be able to login remotely via SSH.
Sensitive areas?:
/home/...,
/jail/glftpd/...
and logs, etc, don't really know?

I've been told cryptsetup is great for this and that one would need to make partitions, containers, etc.. completely lost and scared to try anything without a complete tutorial including the partition parts.

Any chance of this? :D
Thank you!

corruption

Uwe Hermann — Sat, 11 Jul 2009 04:06:48 +0200

Good question, I was planning on testing just that on some test image. I guess only some blocks will be affected, but it probably also depends on the type of cipher and mode you use.

If anybody else does tests, please leave a comment and let us know.

data corruption

Dolfy — Mon, 29 Jun 2009 17:36:47 +0200

Q: what if HDD get some bad blocks/sectors, or any other corruption after being encrypted? How widespread the error will be on the unencrypted view? Will all my data lost or just a file or two?

Thx, Dolfy

re: multiple passes

Anonymous — Wed, 24 Jun 2009 02:49:29 +0200

The reason behind multiple passes has to do with the physical properties of the storage medium.

On a hard drive you have physical platters that are coated in a material that holds information through polarization.

For most intents and purposes the information stored is a true binary data (N or S polarization), but because the density is not 1 bit per molecule, there is a possibility that a particular bit may only be partially polarized, meaning that some of the field may actually be polarized with the old data, meaning that should someone either use specialized forensic software or physically dissect the drive, it may be possible to recover the original information. Each new pass of random information reduces this possibility of recovering the information by compounding the magnetic 'echos' to the point that, which echo is valid, becomes nearly impossible to determine. How many passes are taken should be directly related to the sensitivity of the information that was in that area of the disk being wiped. The multiple pass approach normally includes either all 0's and/or all 1's as one or more of the passes, before or mixed in with the random passes (not the last pass), just to ensure that every bit changes polarity at least once and in such a way to make it more difficult to recover the information.

Anything beyond 26 passes is just overkill, and unless the information is TS-SCI, even 26 passes is going to be a bit excessive.

I find it strange, because

Anonymous — Tue, 26 May 2009 00:55:37 +0200

I find it strange, because shred is by default using exactly the same /dev/urandom, which is almost sure to be a bottleneck. Actually, in my case, there's really no noticeable difference. Maybe if you tell dd to copy more blocks at once, it will go faster?
e.g.
dd if=/dev/urandom of=/dev/sdb bs=10240
(10MiB at once)

Why use multiple passes at all?

Jürgen Hestermann — Thu, 29 Jan 2009 18:10:41 +0100

I also can't imagine how it would be possible to recover data from a disk that was (physically) overwritten (with a random pattern). Not even for these old MFM and RLL drives which Gutmann is talking about in his article from 1996. Just imagine you know that a 1 (or 0) is stored somewhere and you would be able to detect the kind of bit that was stored before, what does it tell you? You would not know whether this previous bit was stored by the erase process or by any of the other (hundreds or thousands) of storage processes applied to this bit. So why waste time with multiple overwrite passes if even one would be sufficient?

Thanks

Jakub — Sat, 24 Jan 2009 21:20:21 +0100

Thanks for this howto, I have aplied it to an external harddrive in Fedora 10 without any problems.

Of course CPU usage is high,

Anonymous — Wed, 23 Apr 2008 15:40:05 +0200

Of course CPU usage is high, the CPU is being used to run the encryption and decryption algorithms. When combined with SCP, it has to do the usual SSH encryption/decryption, plus the LUKS encryption/decryption. If you want that done fast, it needs clock cycles. Duuhhh!!

Yes, wipe would be another

drivers — Sun, 09 Mar 2008 18:15:00 +0100

Yes, wipe would be another option. Or shred. I'll try to find a comparison of all these tools and their effectiveness in regard to "real" random garbage and their speed.

or wipe /dev/sdb

Anonymous — Sun, 02 Mar 2008 01:17:49 +0100

wipe /dev/sdb

off topic

pnt — Fri, 15 Feb 2008 06:39:24 +0100

this is not the LUKS way
it's just the normal crypt_dm way, which cannot change key or have more than 1 key

Anonymous

Anonymous — Thu, 27 Dec 2007 18:56:06 +0100

dd if=/dev/urandom of=/dev/sdb
is VERY slow.

I use this command:

shred -n 1 /dev/sdb

This work 100x faster.

dmcrypt issues with Etch standard kernel

andrew henry — Fri, 07 Dec 2007 19:40:52 +0100

I fixed the problem by compiling and running kernel 2.6.23.9. disk activity is now fast and constant but CPU usage is still high. Seems like kernel supplied with Etch is not suitable for usage with dmcrypt.

HOWTO: Disk encryption with dm-crypt / LUKS and Debian [Update]

Uwe Hermann — Mon, 03 Apr 2006 02:54:56 +0200

A few weeks ago I published a small HOWTO for using loop-aes to encrypt your hard drive, usb thumb drive etc.

As I have bought a new 300 GB external USB disk drive on Friday, I have tried something new this time: disk encryption using dm-crypt / LUKS. It has been suggested to me multiple times that dm-crypt is superior to loop-aes, however I didn't get a real reason. Yes, it doesn't require any kernel patches and is easier to setup. But has any serious cryptographer looked at it sharply, yet? Did it withhold his eye contact?

Anyways, here's how I encrypted my 300 GB drive. I largely followed the guide at the EncryptedDeviceUsingLUKS wiki page...

Make sure you run Linux 2.6.16 or better. Previous versions suffer from an implementation problem which affects the security of dm-crypt, see Linux Kernel dm-crypt Local Cryptographic Key Disclosure.
Enable the following options in your kernel:
- Code maturity level options
  - Prompt for development and/or incomplete code/drivers
- Device Drivers -> Multi-device support (RAID and LVM)
  - Device mapper support
  - Crypt target support
- Cryptographic options
  - AES cipher algorithms
Overwrite the whole drive with random data in order to slow down attacks on the encryption. At the same time perform a bad blocks scan to make sure the hard drive is not going to die too soon:
badblocks -c 10240 -s -w -t random -v /dev/sdb
Replace /dev/sdb with whatever is correct on your system. If you're really paranoid, and are willing to wait one or two days, do this:
dd if=/dev/urandom of=/dev/sdb
Install the required packages:
apt-get install cryptsetup hashalot
The current cryptsetup in Debian unstable already supports LUKS, which was not the case a while ago, if I'm not mistaken. So Debian testing or stable will most probably not work!
Create one or more partitions on the drive:
cfdisk /dev/sdb
I created one big 300 GB partition, /dev/sdb1.
Setup LUKS:
cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb1
Enter a good passphrase here. Don't spoil the whole endeavour by chosing a stupid or short passphrase.
Open the encrypted device and assign it to a virtual /dev/mapper/samsung300gb device:
cryptsetup luksOpen /dev/sdb1 samsung300gb
Create a filesystem on the encrypted device:
mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super /dev/mapper/samsung300gb
I used ext3 with some optimizations, see mke2fs(8).
Mount the encrypted partition:
mkdir /mnt/samsung300gb
mount /dev/mapper/samsung300gb /mnt/samsung300gb
That's it. Everything you write to /mnt/samsung300gb will be encrypted transparently.
For unmounting use:
umount /mnt/samsung300gb
cryptsetup luksClose /dev/mapper/samsung300gb

After unmounting, nobody will be able to see your data without knowing the correct passphrase. Drive is stolen? No problem. Drive is broken, and you want to send it in for repair without the guys there poking in your data? No problem. You leave the USB drive at home and some jerk breaks into your house, steals your drive, rapes your wife, and kills your kids? No problem. Well, sort of, but you get the idea ;-)

There's more things you can do, thanks to LUKS: have multiple passphrases which unlock your data, change/add/remove passphrases as you see fit, etc.

Comments?

Update 2006-04-17: You have to use cryptsetup from unstable if you want LUKS support. cryptsetup in testing does not support this (thanks Ariel).