| View previous topic :: View next topic |
| Author |
Message |
philip
Guru
Joined: 10 Jun 2003
Posts: 535
Location: Sweden
|
 Posted: Thu May 05, 2016 3:09 pm Post subject: Is post install disk encryption possible? |
 |
|
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 |
|
 |
nlsa8z6zoz7lyih3ap
Guru
Joined: 25 Sep 2007
Posts: 378
Location: Canada
|
| Posted: Thu May 05, 2016 3:29 pm Post subject: |
|
|
| 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 |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6042
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6228
Location: Room 101
|
| Posted: Thu May 05, 2016 7:09 pm Post subject: |
|
|
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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6296
|
| Posted: Thu May 05, 2016 8:30 pm Post subject: |
|
|
| 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 |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2971
Location: Germany
|
| Posted: Thu May 05, 2016 8:54 pm Post subject: |
|
|
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 |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6296
|
| Posted: Fri May 06, 2016 5:40 am Post subject: |
|
|
| 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 |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2600
|
| Posted: Fri May 06, 2016 5:57 am Post subject: |
|
|
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 |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6228
Location: Room 101
|
| Posted: Fri May 06, 2016 6:29 am Post subject: |
|
|
| 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 |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2600
|
| Posted: Fri May 06, 2016 7:12 am Post subject: |
|
|
| 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 |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2971
Location: Germany
|
| Posted: Fri May 06, 2016 11:26 am Post subject: |
|
|
| 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 |
|
|
|
Installing Gentoo
