On Thu 25 Jun 2020 at 07:40:43 (-0400), rhkra...@gmail.com wrote: > On Wednesday, June 24, 2020 10:20:55 PM David Wright wrote: > > On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkra...@gmail.com wrote: > > > On my Wheezy system, I used cryptsetup to set up a LUKs encrypted file > > > system on a dedicated partition > > > > What were the contents of this partition: the OS itself, or /home, > > or an independent filesystem that you'd probably mount under /media? > > an independent filesystem mounted as a top level directory
Then I can't see any point in involving the Debian installer. Some of the details depend on what scripts you use to unlock and mount. My own method for creating a filesystem is (from my notes): --✄---- If encrypting an entire disk, scramble the disk first, then partition. If only encrypting a partition, partition the disk first. Alignments should be at least 2M (4096 x 512B sectors). Scramble any sensitive pre-existing contents: # dd bs=1M if=/dev/urandom of=/dev/sdz[9] Partitioning is conventional. # gdisk /dev/sdz [… etc …] Creating the encrypted partition. # cryptsetup --align-payload 2048 luksFormat /dev/sdz9 WARNING! ======== This will overwrite data on /dev/sdb1 irrevocably. [… etc …] Add more passphrases: # cryptsetup luksAddKey /dev/sdz9 [… etc …] Create the filesystem: # cryptsetup open --type luks /dev/sdz9 thename # mkfs.ext4 -L name09 /dev/mapper/thename [… etc …] # e2label /dev/mapper/thename name09 (if forgotten above). Finally: # cryptsetup luksClose thename --✄---- (I mangle the device names to make copy/paste less dangerous.) > (I have some scripts to allow me to easily open (and close) those filesystems > -- when they open, the unencrypted content is put on a ramdisk (with the > intent if somebody gets physical possession of the device (which is a > desktop, > not a laptop), the enencrypted data disappears on power off.) As I encrypt /home, it wouldn't make sense for me to copy it all. I assume that nobody's going to freeze my PC when they steal it. My scripts use LABELled filesystems (as seen above), so there's nothing unusual about /etc/fstab; and I unlock with udisksctl, using the /dev/disk/by-partlabel value, so there's no entry in /etc/crypttab. > Well, the Buster system is a laptop, Jessie is a desktop. I don't plan to > put > much, if any, sensitive data on the laptop. (I don't really even intend to > take the laptop out of the house, especially during this Covid thing -- I > installed Buster on it because I needed GCC 7+ and couldn't (easily) do that > on the Wheezy or Jessie systems. > > > Do you use suspend? > > No. Then you could encrypt swap with a random key. My method for that is unusual, in that the swap partition is specified in fstab by its (tiny) filesystem's LABEL. Its /etc/crypttab is thus fixed: swap LABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512 > > Desktops? > > See above. > > > Do you boot them remotely? > > No, but they do stay up 24/7 unless there is a (longer that 2 minute (power > is > UPS supported)) power outage, or a (very rare) reboot. OK. This only really matters if you're encrypting /home (as I do) or the system itself, as you then need a method of supplying the passphrase before any users can login. (I use a pseudo-user whose ~ is in /var/local/home/ with a crafted .bash_profile.) Cheers, David.
