21

I recently installed Kubuntu and I noticed the option for having an encrypted LVM. The behavior suggests it's full disk encryption since I need to put in a password before I can boot. This article and others I have read suggest it's full disk encryption. Is this actually full disk encryption? If so what type of encryption does it use? or is it just a password I have to put in before it hits grub or lilo but the disk itself is unencrypted.

The only reason I don't believe this is full disk encryption is because the only full disk encryption software I've used before was truecrypt which took hours to encrypt a hard drive and when I did something crazy like AES>Serpent>Blowfish the machine would be noticeably slower. Kubuntu's encryption didn't take 4 hours to setup and the machine doesn't seem slower at all.

Improve this question
0

2 Answers 2

Reset to default
27

LVM operates below the filesystem, so whatever it does, it does so at the disk level. So yes, indeed, when LVM implements encryption this is "full-disk encryption" (or, more accurately, "full-partition encryption").

Applying encryption is fast when it is done upon creation: since the initial contents of the partition are ignored, they are not encrypted; only new data will be encrypted as it is written. However, when applying encryption on an existing volume (as is typical of TrueCrypt) requires reading, encrypting and writing back all used data sectors; this includes sectors which were previously in use, even if they are not in use right now, because they may contain excerpts of some files which were later on copied around. So that kind of after-the-fact application of encryption requires reading and rewriting the whole volume. A mechanical harddisk will run at about 100 MB/s, so a 1 TB volume will need 6 hours (3 for reading, 3 for writing).

The encryption itself needs not be slow, at least if it has been properly implemented. A basic PC will be able to encrypt data at more than 100 MB/s, with AES, using a single core (my underpowered laptop achieves 120 MB/s); with recent x86 cores offering the AES-NI instructions, 1 GB/s is reachable. Thus, the CPU can keep pace with the disk, and, most of the time, the user will not notice any slowdown.

Of course, if you do "something crazy" like cascading algorithms, well, you've done something crazy and you will have to pay for it. Cascading three algorithms means having to compute all three whenever you read or write data. AES is fast; Serpent not so (about twice slower). In any case, cascading encryption algorithms is not a very rational idea. By default, "encrypted LVM volume" in Linux will rely on dm-crypt, which is configurable (several algorithms are supported) but does not indulge into voodooistic cascades, and that's a blessing.

(This does show one of the little paradoxes of security: if it is too transparent and efficient, then people get nervous. For the same reason, medicine pills must taste foul.)

Improve this answer
6
  • 3
    but if it doesn't make my stuff slow or less usable then it's not secure :) j/k great answer thank you!
    – Four_0h_Three
    Commented Jul 17, 2013 at 14:41
  • Ok so I read your answer on why cascading encryption is not very rational. With which I partially agree. Correct me if I'm wrong here but your argument is essentially since there are no known exploits for the major encryption algorithms such as AES and it's extremely unlikely to be cracked that cascading to another encryption algorithm doesn't make sense and is just a waste of resources?
    – Four_0h_Three
    Commented Jul 18, 2013 at 13:50
  • 1
    Cascading algorithms offers any protection only on the off-chance that one algorithm becomes utterly broken, while the other remains rock solid. It does not happen in practice. Never. When such systems are broken, it is because of a poorly protected key, not because of an algorithm weakness. So that's just a big waste of resources; any feeling of extra security provided by cascading is just that: a feeling, not something substantiated by theory or experience.
    – Thomas Pornin
    Commented Jul 18, 2013 at 14:08
  • I agree if you password is weak or if one algorithm is backdoored by the creators to get your key it doesn't matter (unlikely but not impossible). this also gives me an idea. Would Cascading make more sense to you if the application performing the cascading required a different password for each algorithm and forces the user to use different passwords?
    – Four_0h_Three
    Commented Jul 18, 2013 at 15:53
  • 2
    If you accept to type two passwords, you may as well concatenate both into a big password, and hash that (properly) into a key for a single encryption algorithm. You would still have the benefits of all the entropy in your passwords, and without paying for it with a twice slower encryption process.
    – Thomas Pornin
    Commented Jul 18, 2013 at 16:40
6

It is LUKS dm-crypt full partition encryption. Your /boot partition still needs to be unencrypted, but there is not a lot anyone can learn about you from your /boot

Read this table for more info. https://wiki.archlinux.org/index.php/Disk_Encryption#Comparison_table

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .