You are not logged in.
Pages: 1
The pink box at https://wiki.archlinux.org/index.php/Dm … sk_support says:
Warning: Do not use this setup with a key file. Please read about the issue reported here. Alternatively, use a gnupg-encrypted keyfile as per https://bbs.archlinux.org/viewtopic.php?id=120181
Reading that link (https://wiki.archlinux.org/index.php?ti … e_insecure):
They cause the swap encryption key to be picked up by mkinitcpio and stored on the unencrypted /boot partition, thus rendering the encryption useless.
Looking at the contemporaneous version of the page https://wiki.archlinux.org/index.php?ti … sk_support, it has instructions like
7. Then create and edit the hook setup file /lib/initcpio/install/openswap as:
# vim: set ft=sh: install () { MODULES="" BINARIES="" add_file "/etc/keys/swap.key" FILES="" SCRIPT="openswap" } help () { cat<<HELPEOF This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice HELPEOF }
If you don't use a saved key file, remove unnecessary line add_file "/etc/keys/swap.key" from the file above.
8. Add the hook openswap in the HOOKS array in /etc/mkinitcpio.conf, before filesystem, but after encrypt which is mandatory as well.
9. Regenerate the boot image:
# mkinitcpio -p kernel26
It seems that removing"add_file "/etc/keys/swap.key" resolves the issue of including the decrypted key in the /boot initcpio.
But then he goes on to say
Better still, the suspend image contains the keys for any other encrypted partitions that were currently open too...
Why is this a problem? While it means that anyone who can resume the machine can also decrypt the other partitions, this seems reasonable most of the time. And since we're encrypting /swap just as strongly as everything else, anyone with the ability to can crack the suspend image in /swap could also crack our other partitions.
Offline
Pages: 1