Thanks -- very helpful! I mayb have some more questions as I triy to digest this, but can't spend time on it today.
Nothing new below this line. On Friday, June 26, 2020 09:25:49 AM David Wright wrote: > 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,s > ize=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.
