Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Is post install disk encryption possible?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
philip
Guru
Guru


Joined: 10 Jun 2003
Posts: 535
Location: Sweden

PostPosted: Thu May 05, 2016 3:09 pm    Post subject: Is post install disk encryption possible? Reply with quote

I have a functioning Gentoo system on a laptop with an SSD disk, partitioned as such:

/dev/sda1 grub
/dev/sda2 boot ext2
/dev/sda3 swap linux-swap
/dev/sda4 root ext4
/dev/sda5 a partion for virtaul box mounted on /mnt/vb_w7 ext4

My disk not encrypted and none of my partitions are encrypted.

Can I introduce encryption on one or all of my partitions on my already installed Gentoo system? Or must it be done in conjunction with a fresh Gentoo installation?
_________________
/Phil
Back to top
View user's profile Send private message
nlsa8z6zoz7lyih3ap
Guru
Guru


Joined: 25 Sep 2007
Posts: 378
Location: Canada

PostPosted: Thu May 05, 2016 3:29 pm    Post subject: Reply with quote

Quote:
Can I introduce encryption on one or all of my partitions on my already installed Gentoo system?


Yes. Boot using a live CD or DVD.

Copy the content of the partitions elsewhere (a usb hard-drive is handy for this as well as for backups.)

Encrypt the partitions as you wish and then copy the contents back. Modifications will be needed to /etc/fstab
and some other files, depending on how the encryption is done and on whether your are using openrc or systemd.
The details are very dependant upon your your situation.

Encrypt the partitions one at a time. I advise against encrypting boot as that requires a flash drive at boot time
Encrypting root is trickier as then you will require an initramfs.


Last edited by nlsa8z6zoz7lyih3ap on Thu May 05, 2016 7:08 pm; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6030

PostPosted: Thu May 05, 2016 6:48 pm    Post subject: Reply with quote

Here's a guide to using ext4 encryption: https://wiki.archlinux.org/index.php/Ext4#Using_ext4_per_directory_encryption

Do note that you'll have to build the tools yourself, because Gentoo doesn't provide sufficiently up-to-date versions.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Thu May 05, 2016 7:09 pm    Post subject: Reply with quote

Ant P. wrote:
Here's a guide to using ext4 encryption: https://wiki.archlinux.org/index.php/Ext4#Using_ext4_per_directory_encryption

Ant ... interesting, I did notice the addition when configuring 4.5.2 and thought "I wonder how they are doing keys", so doublubely interesting ... now if they would just disappear into the plausibly deniable I would probably give it a shot.

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6296

PostPosted: Thu May 05, 2016 8:30 pm    Post subject: Reply with quote

There is also sys-fs/encfs which is probably similar from a user perspective but has the advantage that it is older (hence, many bugs are already fixed, and it works also with most "older" distributions) and does not require the filesystem to be ext4.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Thu May 05, 2016 8:54 pm    Post subject: Reply with quote

It's possible to do LUKS in place, but you better know what you're doing.

LUKS header takes ~2MiB at the start of the device so all data shifts by 2MiB and you lose 2MiB of capacity so filesystems have to be shrunk first.

Unless you shift partition boundaries, dd is unsuitable since a simple dd would overwrite data that has yet to be encrypted and the whole thing would be gone.

ddrescue has a reverse mode that might work (or it might complain about the target device being smaller)

cryptsetup itself comes with a tool cryptsetup-reencrypt that has an in place mode

Quote:

ALWAYS BE SURE YOU HAVE RELIABLE BACKUP BEFORE USING THIS TOOL.
THIS TOOL IS EXPERIMENTAL.



Add LUKS encryption to not yet encrypted device

First, be sure you have space added to disk.

Or alternatively shrink filesystem in advance.
Here we need 4096 512-bytes sectors (enough for 2x128 bit key).

fdisk -u /dev/sdb # move sdb1 partition end + 4096 sectors (or
use resize2fs or tool for your filesystem and shrink it)

cryptsetup-reencrypt /dev/sdb1 --new --reduce-device-size 4096S


I've done it manually some time ago just to see if it would be doable: https://bpaste.net/show/DDIqHtnJF253YWViEwmE
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6296

PostPosted: Fri May 06, 2016 5:40 am    Post subject: Reply with quote

frostschutz wrote:
It's possible to do LUKS in place, but you better know what you're doing.

Alternatively, you can also use cryptsetup without LUKS: In this case you don't need any header, and you can use regular dd (with the default blocksize of 512 bytes).
The disadvantage is that you have to take care about handling of a strong "random" password by yourself; e.g. you have to store it with gpg, and write a script to get it with a "weaker" user password. Also you must remember which encryption algorithm and modes you use, since this information is not stored anywhere.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2600

PostPosted: Fri May 06, 2016 5:57 am    Post subject: Reply with quote

Probably the least labor intensive and smallest risk is to make a backup with rsync or similar tool, set up your encryption, and then restore your backup to the freshly made (and encrypted) partitions. Note that SSDs have special considerations when doing encryption.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Fri May 06, 2016 6:29 am    Post subject: Reply with quote

The Doctor wrote:
Probably the least labor intensive and smallest risk is to make a backup with rsync or similar tool, set up your encryption, and then restore your backup to the freshly made (and encrypted) partitions.

Doc ... agreed, not only that but it would allow you the opportunity to format the disk and so use lvm within luks, and to fill the luks container with zeros, or (pseudo) random data. Both of those are optional, but if you're going to do it you might as well go to some lenghts to make it difficult to get a crib, and the lvm makes the task of decrypting at boot less troublesome (obviously dependent on the number of volumes ... but I see no reason not to also place swap within the luks container, and, yes, you can resume from a swap within the luks container).

The Doctor wrote:
Note that SSDs have special considerations when doing encryption.

You mean WRT trim?

best ... khay
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2600

PostPosted: Fri May 06, 2016 7:12 am    Post subject: Reply with quote

khayyam wrote:
The Doctor wrote:
Note that SSDs have special considerations when doing encryption.

You mean WRT trim?
Like you don't fill them with random data. SSDs have limited writes and very important wear leveling technology to help with that. Of course, it is the interference with the wear leveling that is more important than a single write. Trim is something that should be done by the OS anyway so I don't count that as an encryption concern.

Also, many SSDs have built in encryption capability and it is far better to use that on an SSD. Any other encryption scheme has consequences for the SSD's life and performance. And before a discussion of possible back doors being added, I'll just remind everyone that it depends on the threat. If the point is to keep people from stealing bank info with the laptop, you are good. If you are worried about the NSA, well...
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Fri May 06, 2016 11:26 am    Post subject: Reply with quote

The Doctor wrote:
Like you don't fill them with random data. SSDs have limited writes and very important wear leveling technology to help with that. Of course, it is the interference with the wear leveling that is more important than a single write. Trim is something that should be done by the OS anyway so I don't count that as an encryption concern.


If you have unencrypted data on your SSD and want to make 140% sure it's gone... you still overwrite it with random data (shred -v -n 1). Trimming alone should get rid of it but that's hard to verify.

cryptsetup/LUKS blocks discard/trim by default. If you want it you have to explicitely allow it using cryptsetup --allow-discards (which then turns into strange boot parameters depending which initramfs flavour you use).

In general you do not have to worry about write cycles or wear leveling. As long as the SSD has a large enough internal reserve (basically anything that is sold as 240G-250G instead of 256G) wear leveling will work just fine even without trim - at the cost of some write amplification which isn't really an issue since SSD can survive a lot of writes, as shown by various write endurance tests you can find online.

The Doctor wrote:
Also, many SSDs have built in encryption capability and it is far better to use that on an SSD.


That's fine too, but you are relying on a black box at this point. And there may be a danger of bricking the device, people have locked themselves out using HDD password mechanisms before.

It all depends on your requirements. I use LUKS for encryption because I don't want to depend on hardware implementation that has been broken in the past.

I allow my encrypted SSD to be trimmed, but if you do that you accept that while data itself is encrypted, free space (the what's-where) is visible. Which isn't a problem for most people, but you should be aware of it in any case. Here's what it looks like in a hexdump ("random" data removed --, free space are the 00 * parts) https://bpaste.net/raw/505157
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum