[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Advice on encrypted filesystem

On Thu 25 Jun 2020 at 07:40:43 (-0400), rhkramer@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), rhkramer@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

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).


# 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.)


Reply to: