On 06/28/2013 03:41 PM, Fred Smith wrote:

I've got a F19 installation that I'd like to turn into a fully encrypted system with LUKS.

There are many howtos on the web for encrypting a partition, but they all show doing it to /home.

the implication is that you need to be logged in as root on the actual system you're modifying, though I don't think that is explicitly stated. That would mean you can't encrypt the root partition itself, since you've got to have an empty partition to work on, then restore its contents from backup.

So, my question(s): -can you do it while being booted into a recovery environment?

I've done it (on F16, or more probably F14, not sure).

You boot into a recovery environment and copy the partitions. In my case, I created the luks container, then the PV, VG, and LVs. Then I copied ("dd" style) the old volumes into the new encrypted volumes (which were a little larger, for safety). Then the tricky part: make a chroot inside the new system (the one on encrypted volumes), fix /etc/fstab and make the mkinitrd stuff to generate an initrd which knows about the encryption (and the new volumes UUID too); this can be triggered by just installing or reinstalling a kernel. Now you can try to boot the new system (/boot must be separate and unencrypted, of course). In my case it worked perfectly at first attempt (and I was pleasantly surprised, I have to say). When inside the new system, I online-enlarged the filesystems (as I said before, the new volumes were a big larger to avoid truncation risk).

Oh, the entire thing happened while switching to a new disk. If you have only one disk, it is more difficult. If you do not have additional space to use, it becomes impossible.

Everything is working right, the distribution has been than updated up to F17.

CPUs with AES-NI make encryption speed penalty basically null (even on a SSD); but with normal CPUs the slowdown is tragic.

On 06/29/2013 12:31 PM, Heinz Diehl wrote:

On 29.06.2013, Roberto Ragusa wrote:

...

CPUs with AES-NI make encryption speed penalty basically null (even on a SSD);

This is not true in my case. My OCZ Vertex delivers 465 MB/s unencrypted, and 167 MB/s encrypted with aes-xts-plain64:sha256 using the Core i5-2450's AES-NI and AVX instruction set.

Your SSD is better (and/or newer) than mine: I see 217 MB/s both with encryption and without.

In my tests (on my i7-2860QM) I remember to have measured about 900 MB/s when reading an encrypted loop device on a file on tmpfs.

Note that I'm using aes-cbc-essiv:sha256, after discovering that the xts variant has half the speed (as it actually encrypts twice); my investigation about what kind of increased security it offers finally led me to avoid it.

You should try aes-cbc-essiv:sha256, it could give you 330 MB/s.