# LUKS encryption less secure?

## 1veedo

What are the advantages of using LUKS over dm-crypt instead of just using dm-crypt?  From what I've read LUKS puts all the information about the encrypted drive on the actual drive and needs a seperate password to access that information.

Doesn't this somehow make it less secure?  I could just as easily remember my password and I don't need to change passwords or create new ones.

The only advantage I could see is that luks also knows the encryption method, so I figure if you bring your HD somewhere else you'd have to remember your encryption method to access the files, whereas otherwise you'd just need lucks and a password?

Also, if you use the wrong password on a dm-crypt drive (without luks) and try to write to it will your drive become corrupted or does it just tell you that it's the wrong password?

----------

## Hu

LUKS stored the volume key in a header on the volume, and uses your password to derive a key to encrypt the volume key.  Assuming that there are no implementation mistakes, such as generating weak keys from the password, this should be as secure as plain dm-crypt, with one caveat.  The caveat is that plain dm-crypt does not have the ability to verify whether the password was entered correctly.  Give an incorrect password, and the volume will successfully mount, but contain garbage data.  Analysis of the presented volume would be required to determine whether the volume mounted successfully.  You could theoretically corrupt the filesystem by writing to it with an incorrect password, but negligence would be required.  Since the entire volume would be garbage data, there would be no valid superblock, so the kernel would refuse to mount a filesystem from it.

LUKS can confirm whether the password was correct, as evidenced by the fact that the block device creation fails and it prompts again if you enter an incorrect password.

----------

## 1veedo

That makes sense.

Does dm-crypt or LUKS automatically know what encryption method is used?  And for that matter how do I specify when I create an encrypted device?  I have support for the encryption method I want to use in the kernel.

edit -- Also, I read that journalling slows down performance.  Do you have to worry much about data loss if you use ext3 without journaling? Or would that justify using an atomic filesystem like reiser4?

----------

## Hu

As I understand it, DM-Crypt does not record any metadata or control information on the volume, so it does not know the encryption method.  You must tell it each time you mount the volume.  Most people will get tired of entering this and will write a shell script that calls cryptsetup with the correct arguments.  LUKS stores the encryption method in the LUKS header, so you can do cryptsetup luksOpen /dev/my-disk plaintext-volume and it will do the right thing.

Specify the cipher when you create the encrypted device, typically through cryptsetup.  See man cryptsetup for details.  Some of the comments in /etc/conf.d/dmcrypt may also be useful.

Yes, journaling will cost you performance.  I cannot point to any benchmarks, but I would expect that the performance difference between journaled and unjournaled I/O on an encrypted volume does not vary much from the difference between journaled and unjournaled I/O on an unencrypted volume.  Most people take the attitude that the protection from data loss during a crash is worth the performance cost that journaling imposes.  As far as I know, disabling journaling is fully safe if you expect never to have your filesystem unmounted uncleanly.  An unclean unmount will occur in the event of a kernel panic or power outage.  Other causes are possible, though none come to mind at the moment.  If a filesystem is unmounted uncleanly and was not journaled, you will need to fsck it.  For large drives, this can take many minutes.

I would prefer to avoid starting a filesystem comparison thread, but my opinion of the Reiser series is rather low, based on the number of people who show up on forums with corrupted Reiser filesystems versus other filesystems.

----------

## 1veedo

I think I prefer it without luks then.  It seems simpler.

Also I figured out how to specify the encryption method.  You do it with -c but it's not obvious what to put as an option there.  I found the XTS method to be aes-xts-benbi.  There is also aes-xts-plain, the difference being that the former is optimized for 64bit processors (plain for 32).

For essiv there is aes-cbc-essiv.

I have one other related question.  I created an image of my root partition with dd if=/dev/root of=root.img.  I never really understood the purpose of blocks and sectors with dd.  Could  I put that image onto a partition that is not the same size as my root partition without any problems at all (without any block specifications and whatnot)?  And just out of curiosity would it work on a different harddrive, like one with a different number of blocks and sectors?

Also is it possible to cp every file in that image onto a new partition with a different filesystem, granted that fstab is modified?  I've tried this before and system links didn't copy over properly.

----------

## Hu

 *1veedo wrote:*   

> I have one other related question.  I created an image of my root partition with dd if=/dev/root of=root.img.  I never really understood the purpose of blocks and sectors with dd.  Could  I put that image onto a partition that is not the same size as my root partition without any problems at all (without any block specifications and whatnot)?  And just out of curiosity would it work on a different harddrive, like one with a different number of blocks and sectors?

 

You can write that image to a partition which is at least as big as the file root.img.  A smaller partition will not work, even if root.img contains mostly empty space.  If you did this, you would restore the filesystem headers that /dev/root had at the time it was copied.  This would make the resulting filesystem exactly as big as the original root filesystem, even if the destination partition would allow for a bigger filesystem.  You can use a filesystem-dependent utility to grow the filesystem after the image is on the partition.  It should work fine on any hard drive, providing the above size constraints are met.

 *1veedo wrote:*   

> Also is it possible to cp every file in that image onto a new partition with a different filesystem, granted that fstab is modified?  I've tried this before and system links didn't copy over properly.

 

Yes, but not directly.  cp operates at the filesystem level.  You have created a block-level image of the source.  You would need to mount that block level image as a filesystem to be able to use cp on it.  When you do, take care to have cp preserve metadata such as ownership, timestamps, and hard links.  For this type of copy, I often recommend tar instead of cp.  For example, tar -c -f - -C /mnt/src . | tar -x -f - -C /mnt/dst.

----------

## zyko

 *Quote:*   

> I think I prefer it without luks then. It seems simpler. 

 

You should definitely use LUKS. LUKS adds usability and security. It doesn't complicate things at all.

All you need is a sufficiently recent version of cryptsetup. The currently stable version in Portage will do.

To setup an encrypted partition, just run 

```
cryptsetup -c aes-xts-plain -s 256 -y luksFormat /dev/sdax
```

To open your encrypted partition, run

```
cryptsetup luksOpen /dev/sdax cryptodev1
```

You will now have a device /dev/mapper/cryptodev1 that you can use like a real partition (make a file system on it, mount it, etc).

That's basically all you need.

----------

## 1veedo

Is there any way to encrypt an entire hardrive, use parted to write a partition table to it and everything, and then somehow create device nodes for each partition?

Currently gparted is complaining that the kernel cant see the partitions or something.  I can create a partition table with partitions but I cant format any of them or access of any of them.

I bassically just need to take a device node and generate other nodes bassed on the partition table.

sfdisk gets mad because I'm not using an msdos partition table (decided to use sun).

```
ERROR: sector 0 does not have an msdos signature
```

And partprobe error's with the same message gparted was giving me (they are using the mapped node).

edit -- using an msdos table I still get an error from sfdisk, 

```
BLKRRPART: Invalid argument
```

 *Quote:*   

> You should definitely use LUKS. LUKS adds usability and security. It doesn't complicate things at all.
> 
> All you need is a sufficiently recent version of cryptsetup. The currently stable version in Portage will do.

 I can remember everything I need to know about the encryption type and everything.  And I dont plan to be changing passwords.  I assume that those would be the only benefits of using luks?

----------

## mv

 *1veedo wrote:*   

> I can remember everything I need to know about the encryption type and everything.  And I dont plan to be changing passwords.  I assume that those would be the only benefits of using luks?

  As long as you use for the actual encryption a really really secure password (several hundred characters of high entropy) which you get from somewhere else in a secure way, you have no additional benefit.

----------

