
Automated encrypted swapfiles - pmoriarty
http://www.braxs.net/?p=28
======
Jedd
This seems a bit convoluted and fragile.

I agree with the sentiment to use swapfiles rather than swap partitions -- the
flexibility is appealing (though in practice I rarely need to change the
dimensions of mine) and the lack of measurable difference in performance over
partitions removes any arguments in favour of dedicated partitions anymore.

But on my secure systems everything other than /boot is encrypted on, so I get
encrypted swapfiles just by creating them as /swapfile.x -- I have a saltstack
recipe that creates these on new installs automatically now, too, and that
doesn't need to be changed for encrypted or non-encrypted root file systems.

The automatic creation of these (and decommissioning them later) based on
ephemeral memory usage requirements is an interesting idea, and it's a shame
the author hasn't gotten to that point yet. I wonder how useful that'd be in
practice, though, especially in an era of 'disk is cheap'.

------
biot
For a second I thought it was going to be a short article about installing
OpenBSD which encrypts the swap by default since version 3.9 (released 2006).
It also encrypts different areas of swap with different keys and, when a
particular area isn't needed anymore, the key is erased.

------
cryptonaut
If you're using systemd you can do this by setting up /etc/crypttab[1] which
has a similar format to fstab. For example, here's my swap line:

    
    
         eswap   /dev/mapper/vg0-swap    /dev/urandom            swap,cipher=aes-cbc-essiv:sha256
    

[1]
[http://www.freedesktop.org/software/systemd/man/crypttab.htm...](http://www.freedesktop.org/software/systemd/man/crypttab.html)

~~~
scintill76
FWIW it's not specific to systemd -- I've been using /etc/crypttab for full-
disk encryption (LUKS) for a few years on Ubuntu. The file is consulted when
building the initrd, to build in whatever magic is needed to decrypt the disks
at boot.

------
Adaptive
Another alternative: Self Encrypting Drives (which can be managed on Linux
with hdparm).

I'm using this currently on my XPS 13 (2015). Works great. However given the
architecture of SED and its implementation in this case, it's not as
trustworthy as LUKS, for example.

For general laptop security not involving government intervention, I consider
it good enough.

~~~
snaky
You can't believe how much insecure they are.
[https://twitter.com/matthew_d_green/status/65642245191255244...](https://twitter.com/matthew_d_green/status/656422451912552449)

~~~
Adaptive
I can believe it. On the XPS 13, even when modifying or NULLing the master
password on the internal sata drive, the unit's BIOS will reassign the BIOS
(UEFI) admin password as a valid SED drive password, with no user
intervention.

It's really just an 'in case of (casual) theft' level of encryption as far as
I'm concerned. Good enough on the systems I'm using it on. For everything
else, there's LUKS.

