# Using dm-crypt in 2.6.4 for an encrypted filesystem

## afabbro

Note: This is too lame to be a HOWTO since I just followed directions I found elsewhere,

but I'm so happy I finally got a solid, large encrypted filesystem working under linux that I'm 

posting my experience

The Goal

A 100GB encrypted filesystem on a USB2 external drive.

My Trevails

I started with cryptoloop and the cryptoAPI.  I had nothing but problems.  Looking back, I realize it may

be that I had HIGHMEM set, and I think there are cryptoAPI bugs when that is set.  With it set, I had 

frequent hard lockups, either working with a block device or a file.  I'll chalk it up to HIGHMEM (for

now), though I've read of others' problems.  At any rate, cryptoloop looks to be on the way out, 

according to http://kerneltrap.org/node/view/2433/  One other thing I don't like about

cryptoloop is that losetup doesn't ask for your password twice.  If you pick a good, long passphrase,

you could easily typo it and find yourself unable to access your data.

Next I looked at loop-AES.  This package has gotten good reviews, but requires (a) replacing your kernel's

loop module, and (b) patching util-linux (though Gentoo does this for you).  I held this as a last resort

(what if I need my loop module for something some day?) and happily, never needed to use it.

Finally, I looked at BestCrypt, a commercial product from Jetico.  BestCrypt is very well-documented but

is not free ($50 US after a 30-day trial;  they give you the source code, so it's an honor system thing).  

I downloaded and tested it, but 1.5.1 didn't work well with my 2.6.3 system.  When using a block device, 

it ran out of space or gave strange "bogus i_mode" messages in dmesg while attempting to fetch impossible 

inodes, which hung the box.  When I tried to use containers (of 100Gb size), mkfs would freeze.  Since 

BestCrypt provides its own kernel modules, I'm going to have to lay the blame at their doorstep.  (The 

product works very well under Windows, incidentally).

Eureka!

Just as I was about to shoot myself out in frustration (see https://forums.gentoo.org/viewtopic.php?t=143108&highlight=),

I learned about dm-crypt.  This is new in 2.6.4 and was available in 2.6.3-mm.  The above-mentioned thread

(http://kerneltrap.org/node/view/2433) discusses the future of kernel cryptography, and it looks

to be dm-crypt instead of cryptoloop.  The main dm-crypt page is at http://www.saout.de/misc/dm-crypt/

Before 2.6.4, you needed to do some special patches on the -mm tree...that's a little too bleeding edge for me.  

But the good news is that 2.6.4-rc1 has dm-crypt support built in.  Note: HIGHMEM is still broken in

regard to CryptoAPI/dm-crypt, so don't use it if you want dm-crypt (yes, this sucks - see the dm-crypt page

above for some patches to fix it).  

To get up and running, I did the following:

```

emerge -u development-sources (to get to 2.6.4-rc1)

emerge device-mapper
```

device-mapper is needed for dm, which is an option in the 2.6.4 kernel (under the RAID section).  

You will also need hashalot, but that's pretty common (and just emerge hashalot if you don't have it).

After rebuilding the kernel, I downloaded cryptsetup (http://www.saout.de/misc/cryptsetup),

a script that makes working with encrypted volumes really easy.  Once downloaded (and chmod'd 755), setting

up the volume is easy.  I chose to use AES (The defaults are aes with a 256 bit key, hashed using rmd160):

```

modprobe dm-mod

modprobe aes (needed?)

./cryptsetup -c aes -y create my-data /dev/sda1

mke2fs /dev/mapper/my-data

mount /dev/mapper/my-data /data

```

You'll get a warning that -y isn't implemented yet - see below (I put it in the example in case someone

is cutting/pasting a month from now).

crypsetup will ask you for a password when you run it.  Unfortunately, the -y flag, which would ask you

for the password twice, is not implemented yet - a hack is to type your password in an editor somewhere

and cut and paste it, thus insuring that your long string of characters is not typo'd.

The mkfs ran pretty hot in terms of system load - 2 to 2.5 on a 1.6Ghz P-IV.  After the filesystem was

built, I started the copy.  It cooked along pretty well - I didn't really notice much of a slowdown compared

to a normal copy (though this is USB2, so it's not as fast as writing to a ATA133 anyway  :Wink:   The load average 

moved between 1 and 2, with 'pdflush' hogging most of it.

When I was finished, it was simply

```

umount /data

```

Yep, that simple.

Status

2.6.4-rc1 has only been out a few days, so this is all barely tested.  However, unlike my earlier experiences, I've written tens of gigabytes

of data on top of a dm-crypted filesystem and mounted and unmounted it several times without a problem.

Future Projects

I haven't investigated how to put this in /etc/fstab, but that's my next step.

I don't really see much use for an encrypted root/swap at home (since I'm religious about linking everything

unique *off* of root, such as /var/www, /home, /usr/local, etc.)  It would be interesting to play with

dm-crypt on a laptop...but that's a project for another day  :Wink: 

----------

## bluephile

afabbro,

I have 2.6.4-rc1 installed and would really like to try this, but the cryptsetup script that you link to no longer exists. Do you think you could post it here?

Cheers,

bluephile

EDIT:

Ah, although archive.org didn't have the page, Google's cache does. I'll be back later with my results!

EDIT2:

Unfortunately, it appears to be older than the one you used, as there is no mention of a -y option anywhere in the script.    :Crying or Very sad: 

EDIT3:

I realized that cryptsetup was linked from the dm-crypt page. They have a new verison of the script (er, program!) now in C: http://www.saout.de/misc/dm-crypt/cryptsetup-0.1.tar.bz2

----------

## mossmann

I've been running my laptop with the entire hard disk encrypted using dm-crypt for over a week now.  Works great!  I'm using a USB flash drive for my /boot and initrd, roughly following the method described in the Disk-Encryption-HOWTO.  I wanted to build a swap device on top of the same encrypted device as my root filesystem and also have flexibility for multiple filesystems, so I'm using lvm2 on top of the encrypted block device.  I had to build a custom initrd and linuxrc script to deal with a root filesystem over lvm2 over dm-crypt, but it was fairly straightforward (except for the conflicting documentation regarding what, exactly, the linuxrc script must accomplish).  Minimal documentation follows:

Warning:  You may destroy your data if you follow these instructions!

First I wrote a mkkey script to create a completely random key for the disk encryption and store the key on my flash drive in an encrypted loop file, protected by a passphrase.  Note that all my scripts use the soon to be defunct cryptsetup.sh but should be easily adapted to the new cryptsetup.

```

#!/bin/bash

LOOP_FILE="/boot/keyloop"

KEY_DMTARGET="key"

LOOP="/dev/loop7"

modprobe dm-mod

if [ ! -f "$LOOP_FILE" ]; then

        # making a 512 byte key even though only a portion will be used

        dd if=/dev/zero of=$LOOP_FILE bs=512 count=1

        chmod 600 $LOOP_FILE

        losetup $LOOP $LOOP_FILE

        cryptsetup.sh -b 1 create $KEY_DMTARGET $LOOP

        dd if=/dev/random of=/dev/mapper/$KEY_DMTARGET bs=512 count=1

        cryptsetup.sh remove $KEY_DMTARGET

        losetup -d $LOOP

        chmod 400 $LOOP_FILE

else

        echo "Don't make me destroy your key!"

fi

```

Then I backed up my hard drive, double-checked the backup, shredded my hard drive, and built a new partition table.  I chose to build my encrypted device on /dev/hda1 (maximum size) rather than /dev/hda just in case a new partition table accidently gets written to the disk or something.  Then I wrote a cryptup script to create the encrypted block device:

```

#!/bin/bash

LOOP_FILE="/boot/keyloop"

KEY_DMTARGET="key"

LOOP="/dev/loop7"

DMTARGET="pvcrypt"

DEVICE="/dev/hda1"

modprobe dm-mod

if [ -r "$LOOP_FILE" ]; then

        losetup $LOOP $LOOP_FILE

        # it would be better to do this readonly

        cryptsetup.sh -b 1 create $KEY_DMTARGET $LOOP

        cryptsetup.sh -s 16 -d /dev/mapper/$KEY_DMTARGET create $DMTARGET $DEVICE

        cryptsetup.sh remove $KEY_DMTARGET

        losetup -d $LOOP

else

        echo "Key not found."

fi

```

Then I built my lvm2 setup on top of the encrypted device with a mkvols script.  I chose to use a 1GB swap volume and a 10GB root volume to get me started:

```

#!/bin/bash

PV="/dev/mapper/pvcrypt"

VG="vgcrypt"

if [ -r "$PV" ]; then

        pvcreate $PV

        vgcreate $VG $PV

        # YMMV

        lvcreate -C y -L 1G -n lvswap $VG

        lvcreate -L 10G -n lvroot $VG

        mkswap /dev/$VG/lvswap

        mke2fs -j /dev/$VG/lvroot

else

        echo "$PV not found."

fi

```

The above script failed the first time I tried it because lvm2 does not consider device-mapper block devices (such as a dm-crypt device) for use as physical volumes by default.  I had to add a line to the devices block in /etc/lvm/lvm.conf:

```

types = [ "device-mapper", 16 ]

```

Now is a good time to verify that the encrypted block device can be remounted correctly, especially because cryptsetup.sh didn't ask for the password twice during setup (thanks to hashalot).  First I used cryptdown:

```

#!/bin/bash

DMTARGET="pvcrypt"

# 'vgchange -a n' fails if I don't do this first.  Not sure why.

# Asking lvm folks about this but no answer yet.

for lv in $(lvs --noheadings | awk '{print $2 "-" $1}'); do

        dmsetup remove $lv

done

vgchange -a n vgcrypt

cryptsetup.sh remove $DMTARGET

```

Then I could run cryptup and vgscan.  vgscan found the vgcrypt volume group, so everything worked.  Then I copied my old root filesystem onto /dev/vgcrypt/lvroot from the backup and built my initrd in /boot.  I copied my keyloop to the initrd and wrote a new linuxrc:

```

#!/bin/bash

export PATH=/bin:/sbin

LOOP_FILE="keyloop"

KEY_DMTARGET="key"

LOOP="/dev/loop/4"

DMTARGET="pvcrypt"

VG="vgcrypt"

LV="/dev/vgcrypt/lvroot"

DEVICE="/dev/ide/host0/bus0/target0/lun0/part1"

if [ -r "$LOOP_FILE" ]; then

        mount -t proc none /proc

        modprobe loop

        modprobe aes

        modprobe dm-mod

        modprobe dm-crypt

        for ((TRY=1; TRY <= 3; TRY++)); do

                # it would be better to use key readonly

                losetup $LOOP $LOOP_FILE

                # This is easier than figuring out why hashalot's password

                # prompt isn't showing up:

                echo -n "Passphrase: "

                cryptsetup.sh -b 1 create $KEY_DMTARGET $LOOP

                echo

                cryptsetup.sh -s 16 -d /dev/mapper/$KEY_DMTARGET create $DMTARGET $DEVICE

                cryptsetup.sh remove $KEY_DMTARGET

                losetup -d $LOOP

                if (vgchange -a y $VG); then

                        exit 0

                else

                        cryptsetup.sh remove $DMTARGET

                fi

        done

        echo "Sorry."

else

        echo "Key not found."

fi

while true; do

        read

done

```

This took a few tries.  Setting up all the files necessary to run cryptsetup.sh on the initrd was a bit of a pain but this will be easier with the new cryptsetup.  The lvm2 tools also have to be on the initrd along with a customized /etc/lvm/lvm.conf.

My grub.conf entry looks like:

```

title gentoo 2.6.4-rc1

root (hd0,0)

kernel /vmlinuz-2.6.4-rc1 root=/dev/vgcrypt/lvroot vga=791

initrd /boot/initrd.gz

```

----------

## Gentoo Server

hi i was the unlucky dude with highmem and cryptloop!

ok lets look forward 

how can i mount my cryptloop drive with dm-crypt? 2.6

----------

## chadders

CooL!  I think like this idea better than using loop based encryption.  Thanks for the howto.

Chadders (the other root encryption howto guy)   :Razz: 

----------

## bluephile

mossmann:

I'm trying to follow your instructions, but I'm confused on one major point:

What system are you booted into when you're running cryptsetup, etc.? The LiveCD kernel is too old for device-mapper support, and I don't know how to connect a laptop harddrive to my desktop to set this up with another machine. Please let me know how you did this!

Cheers,

bluephile

----------

## epic

seems like all this thing needs is a bit more time for developers to make util-linux(mount) and alike support this thing... i run cryptsetup from /etc/init.d/local , to mount my disk, this would ofcourse not work for a root/swap partition ;) i would love any hints to do it a easier way though..(hi to bluephile btw, who fixed the compile error in dmconvert for me! :) )

----------

## bluephile

(Hi epic!)

Well, I've gotten somewhat further along ...

I used catalyst to create a new livecd based on 2.6.4 that included device-mapper, gcrypt, and cryptsetup. I successfully created my encrypted LVM partition, but I'm having trouble with the initrd: the kernel oopses when it boots up before panicing due to being unable to mount root. I've had the same problem with an encrypted root without LVM. I can't figure out how to read what the oops is to try and track down what's wrong. I'm afraid I'm stuck until development of dmcrypt/cryptsetup/etc. progresses somewhat (perhaps it'll include scripts to create the initrd & do this stuff automatically?) and I don't have to figure out why my initrd is failing, unless someone has a suggestion.   :Sad: 

Thanks,

bluephile

----------

## mossmann

 *bluephile wrote:*   

> What system are you booted into when you're running cryptsetup, etc.?

 

Good question!  I was using a minimal system installed on a second partition on my hard disk that I failed to mention.  Someday it won't be there, but, as I have been on the road constantly over the past few weeks, I'm not quite ready to be without a safety net!  I haven't had the time or motivation to use catalyst yet, but I would like to.

I found it useful to use bash or sash as my linuxrc when I was first trying to get my initrd to work.  Being able to interact with the process was very helpful for debugging.  Have you figured out if the oops is prior to, during, or after linuxrc?

I haven't been following it closely, but I know there has been some discussion of initrd on the dm-crypt mailing list: http://news.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt

----------

## DerRalf

I created an ebuild for cryptsetup. You can get it here:

http://www.ece.cmu.edu/~rholzer/cryptsetup-0.1.ebuild

----------

## davidblewett

I would like to use this procedure to create an encrypted USB flash drive. Will this work in Windows, or is it a *nix only solution? Thanks!

----------

## epic

i cant get this to work with firewire... i have a 250 gb disk in a firewire enclousure. It works perfectly, but if i try to encrypt the device i get:

```

ieee1394: sbp2: aborting sbp2 command

0x2a 00 0e 90 40 57 00 00 80 00 

ieee1394: sbp2: aborting sbp2 command

0x2a 00 0e 90 40 d7 00 00 80 00 

ieee1394: sbp2: aborting sbp2 command

0x2a 00 0e 90 41 57 00 00 80 00 

ieee1394: sbp2: aborting sbp2 command

0x2a 00 0e 90 41 d7 00 00 80 00 

```

the command i use to set up the device is:

```

./cryptsetup -c aes -s 128 -y create cryptdev /dev/sda1

```

earlier i got the thing mounted... but it startet showing errormsg's after i tried to copy something to it... now, it cant get through mkfs.xfs before showing errors, so i cant mount it.

As i said earlier the disk works perfectly without the encryption.

Anyone got any ideas?

Another question i have in this dm-crypt matter is, when will we see this dm-crypt stuff merging into mount and such, so that the whole matter could be easilier managed(would be a breeze to encrypt root and such), since it's becoming the future in linux disk encryption since 2.6.4 i mean....

----------

## keschrich

Just a thought:

I don't know all too much about encryption and modern algorithms, but isn't encrypting the root partition a bit dangerous due to the amount of known plaintext?  As long as the intruder knows that you're running Linux, there are quite a few libraries and such that are fairly standard to just about any Linux system.  Not to mention those of us like me who've installed the howtos, now theres a lot of plaintext just waiting to be exploited..

There must be something I'm missing here otherwise I'm sure it would've been mentioned long ago.. is known plaintext no longer an issue?

----------

## tdb

Feel free to correct any inaccuacies in my post, I'm no expert.

Here is something, although I think that most modern ciphers themselves are not vulnerable to a known plaintext attack. (which is what you are describing) Chaning modes (CFB and CBC) and Initialization Vectors (IV) were invented to prevent this, I think.

http://lwn.net/Articles/67216/

----------

## rwallace

Ok.  I successfully created an encrypted filesystem with dm-crypt.  But...

I wanted to try this so I could protect data from theft if the server was taken.  But if all a person needs to do to mount the encrypted partition is 

```
mount /dev/mapper/crypt /data
```

 and they don't have to enter a key, what's the point?  Am I missing something?

[EDIT]  :Embarassed: 

I guess I should have read a little more. *Quote:*   

>  Don't forget: cryptsetup only creates a mapping. If you call cryptsetup again after a reboot and supply the same passphrase you will be able to mount your filesystem you created before.

 

So I guess now my question is how do I kill this mapping without having to reboot?

[/EDIT]

----------

## drfunfrock

 *rwallace wrote:*   

> Ok.  I successfully created an encrypted filesystem with dm-crypt.  But...
> 
> So I guess now my question is how do I kill this mapping without having to reboot?
> 
> [/EDIT]

 

On the commandline only type cryptsetup -h and you get help

or 

> cryptsetup delete [name] [device]

----------

## rwallace

Yah, I read some more of the dm-crypt page docs and lo' and behold found that its as simple as

```

umount /data

cryptsetup remove crypt

```

Very nice.  Very simple.  I did a 50GB transfer of the data I wanted to encrypt last night and it completed without a problem.  I'm very happy now.

Before I was trying cryptfs and cfs on FreeBSD 4.9-R, 4.9-S, 5.1-R and 5.2-R and none of the combinations could get past 15G.  Most of the time the system would hard lock at between 3 and 6G.

Thanks for this little pointer.  The gentoo forums strike again   :Very Happy: 

----------

## mossmann

 *keschrich wrote:*   

> I don't know all too much about encryption and modern algorithms, but isn't encrypting the root partition a bit dangerous due to the amount of known plaintext?

 

The only known plaintext attack I'm aware of that we need to be concerned about is the optimized dictionary attack described in the link provided by tbd.  This attack only works if the attacker knows some plaintext, including its exact location on the block device.  Even though there is a lot of known plaintext on a root filesystem, very little of it is in a predictable location.  That's why the attack in the link targets something in the filesystem header rather than any individual data files within the filesystem.

Personally, I don't trust any IV method to protect me from an optimized dictionary attack, at least not until the method and the specific implementation have undergone significant peer review.  That's why my key is a chunk of completely random bits that would never be found in a dictionary.  Then I encrypt my key with an easier to remember passphrase.  The encrypted block device can't be attacked with an optimized dictionary because the key would not be in anyone's dictionary (even though there is known plaintext on the device); the encrypted key can't be attacked with an optimized dictionary because it contains no known plaintext (even though my passphrase could conceivably be in someone's dictionary).

If someone had both my hard disk (encrypted block device) and my flash device (encrypted key), then they could perform a dictionary attack, but it would be very computationally expensive and could not be optimized for multiple targets.

----------

## mossmann

 *epic wrote:*   

> As i said earlier the disk works perfectly without the encryption.

 

Hmmm.  Does it work perfectly with the same kernel that you are using for dm-crypt?  Have you tried an intensive write test like "badblocks -w"?

 *epic wrote:*   

> Another question i have in this dm-crypt matter is, when will we see this dm-crypt stuff merging into mount and such

 

That is being worked on.  See http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/34

----------

## crculver

I already have a partition set up with encryption and mounting provided by the loopback driver. How do I use device-mapper functionality to mount the drive?

Note that I only want to mount an existing encrypted filesystem with this new method, I do NOT want to have to reformat or reencrypt. In fact, the first time I want to mount it read-only so I can make sure I'm not going to lose my home dir.

----------

## tdb

 *crculver wrote:*   

> I already have a partition set up with encryption and mounting provided by the loopback driver. How do I use device-mapper functionality to mount the drive?
> 
> 

 

Try here:

http://www.saout.de/misc/dm-crypt/

About halfway down the page is a section about migration. It looks like dm-crypt can do cryptoloop created by 2.6 kernels. There are a few links to follow from there as well.

----------

## GentooBox

Hi.

I have some experience with loop-AES with gpg keys.

but for loop-AES to work perfectly i need to patch util-linux and build a loop.ko module.

is there any reason why i should switch to dm-crypt ?

EDIT: has anyone encrypted their whole harddisk ? how does it work ?

did you guys figure out how to add the encrypted drive to fstab ?

----------

## epic

 *GentooBox wrote:*   

> Hi.
> 
> I have some experience with loop-AES with gpg keys.
> 
> but for loop-AES to work perfectly i need to patch util-linux and build a loop.ko module.
> ...

 

yes there is a good reason to switch to dm-crypt. Because the 2.6 maintainer morton has deprecated the loop-crypt.

To set up the encrypted partitions in fstab you would need to patch your util-linux with the patch located in the mailinglist(for util-linux 2.12 i belive, dunno if this works with a root/swap partition though)

Anyone know how to use dmconvert to encrypt a already existing partition?

----------

## misc

Hi,

I haven't began to do this yet but I have a backup server that a lot of servers backup to. I store all this data on a separate partition, and it's a raid device as well (mirror). Is this going to cause trouble? Do I need to delete the partition before I encrypt it? 

One last question, I noticed that when you unmount the drive that you type 'cryptsetup remove crypt' which will make it so that on a reboot, it will still ask for a pass phrase. My question is, what happens if this drive needs to be mounted at all times? I'm guessing that you can still type the cryptsetup command to remove the key even while it's mounted? Otherwise theres no point for me in using this, because if the backup server gets stolen then they will have access to the partition.

----------

## Nate_S

Here's a very dirty hack I'm using to encrypt swapspace on bootup with local.start and local.stop  

DISCLAIMER:  Use at your own risk.  This is what I am using on my system, and it works for me, but I can't promise it won't make your hard drive scream in pain or your mouseball to get filled with dust twice as quick.  However, I'd highly doubt it could do worse than cause the swap not to work, which could be easily fixed by simply removing this hack, and mkswap on your swap partition again.  

/etc/fstab

```
/dev/hda9               none            swap            sw                     0 0

```

I still have an unencrypted swap in my fstab that the kernel activates during bootup.  This is most likely not necessary, but I left it just in case it uses swap as it boots.  

/etc/conf.d/local.start

```
swapoff /dev/hda9                                           #turn off swap activated in fstab

cryptsetup -d /dev/urandom create swap /dev/hda9            #encrypt partition using a random key from /dev/urandom

mkswap /dev/mapper/swap                                     #setup the swap space on the encypted partition

swapon /dev/mapper/swap                                     #activate the encrypted swap

```

/etc/conf.d/local.stop

```
swapoff /dev/mapper/swap                                        #deactivate the swap device

cryptsetup remove swap                                          #remove encrypted device

mkswap /dev/hda9                                                #set it up for unencrypted use on next reboot

```

I hope this helps some of you

-Nate

----------

## tweakt

 *Nate_S wrote:*   

> Here's a very dirty hack I'm using to encrypt swapspace on bootup with local.start and local.stop

 

This is insecure. If you've got unencrypted swap mounted while an encrypted device is mounted, the possibility exists for cleartext to remain in your swap even after you remount in encrpyted since mkswap does not wipe the partition, it only writes a signature. So ideally, encrypted swap should be mounted before any other encrypted devices. Or do a dd if=/dev/urandom of=/dev/swapdevice before the mkswap.

----------

## Nate_S

I'm sure you don't mean that it might write the key used for encryption to swap?  It shouldn't do that anyways...

Otherwise, I don't think there'd be any information in swap that was not already encrypted.  I had it use the swap unencrypted at first, partially because I didn't know if it might speed up boot up, but mostly because I have an old installation of Gentoo on another partition that I still boot in to occasionally, and it uses the swap unencrypted ( I don't need it encrypted when I boot into that install anyways.)  So the only thing that should be in swap at bootup is either swap from a previous bootup, encrypted with a random key, lost on shutdown, or unencrypted swap from the other install that I don't care about.  

Regardless, from what I've read about people not using swap entirely, even with small amounts of ram, you should be able to not have any swap activated until local.start.  Or I suppose you could do a dd if=/dev/(zero,urandom) of=/dev/mapper/swap, but I chose not to because I think it'd really slow down bootup.  

Pretty much it's just mirroring the commands I would type when setting it up initally, just having it do so automatically on startup.  I've heard that encrypted loopback devices are out, but I have yet to see anyone say they got encrypted swap to work with dm-crypt.  So, (hoping there's not good reason for this,) I invented my own method.  

So, to amend my previous disclaimer, I can't guarntee that this method will be very secure.  Heck, going by what I know about security and encryption, I can go so far as to say it probably won't be.  As I said, this is the method I use, so I believe that it offers at least partial security, but use at your own risk.  

Tweakt, I do appriciate the criticisim.  If I've missed any other big gaping security holes, please do point them out as well.

----------

## Devsforev

Excellent tutorial! I just used it as an outline to create an encrypted partition of my own. Nice little 20gig, reiserfs partition, using the Blowfish algorithm.

An afterthought just occured to me. At no time during the process was I asked for how many 'bits' should be used for my Blowfish algorithm. I know the keys go from 32 -> 448 bits. How do you specify how many bits? What is the default? Thanks a bunch!!

Once again, great guide!!!

-- Devsforev

----------

## martinm1000

Hi!

I'm using 2.6.6 and I just recompiled my kernel to be able to use dmcrypt;

I wanted to compile cryptsetup, but it needs libdevmapper.

I suppose that I need to emerge device-mapper ? Well he want to ALSO

install gentoo-sources-2.4.26_pre6... But I'm on 2.6.6 ! I don't want 2.4 !

What did you do to make it work ?

Thanks.

----------

## Q

What filesystems are you using?

Is there an issue with journaling file systems?

----------

## Tazok

 *martinm1000 wrote:*   

> Hi!
> 
> I'm using 2.6.6 and I just recompiled my kernel to be able to use dmcrypt;
> 
> I wanted to compile cryptsetup, but it needs libdevmapper.
> ...

 

You should check your virtual/linux-sources inside /var/cache/edb/virtuals.

Btw, has anyone gotten dm-crypt with gpg-encrypted keys to work?

Would be nice to hear which steps are needed for that.

----------

## Petyr

Much thanks the original author for posting this thread. I've been considering how to go about encrypting at least my home_vlm for a good while now.

dm-crypt has been a great solution.

In answer to the previous two posts, I've had ext3 up and running for a few days now. I'm highly inclined to think that there are no issues with using a journalated file system on dm-crypt. Effectivly dm-crypt just looks like a block device, which is all a HD really is... so *shrug*

I dunno I could be wrong, so don't take just my word for it.

As for GPG keys, I'm using a slightly different solution. I recently bought a usb keychain ($30 for 128 Meg! Gotta love Fry's) and I just store a loopback file on there. Using losetup and dm-crypt in an initrd setup, I'm able to have my real HD key stored on the USB keychain. While this doesn't make use of GPG, it has the same end result. Yes one can argue about how GPG encrypts this way while AES does it another way, but ultimatly one has to ask the question, "If my data secure?"

I figure with the setup I've got I can safely say yes to that.

Both setups have an added benifit (or risk depending...) Without the USB keychain, the laptop the /home dir's are junk. Now if it gets stolen while I'm traveling, and the keychain is not with it, well at least my personal data is safe.

Now I just have to encrypt the whole friggin HD... wonder if the live CD can help me out here...

Petyr Rahl

----------

## Petyr

Meebe if I had read a little closer I woulda saved myself some time... oh well. So the LiveCD won't help, however since I spent all this time creating an initrd I decided to take a pretty massive risk.

Since I already had /bin/bash on the initrd I just made it so the initrd just dumped me into a shell. I had copied over the commands that I was going to need, and just encrypted the HD from the initrd (I had 2 of them setup and I had booted from the second one).

Then I just rebooted and had the system boot using the first initrd and *poof* system worked and everything was encrypted, except /boot of course  :Wink: 

Damn that was scary doing though... I was convinced that I'd missed something and that all my data on my laptop was hosed. 

Guess I had enough coffee this morning or something because it all came out well.

Anyways cheers! Now my laptop is much safer ^^

Petyr Rahl

----------

