Talk:LVM on LUKS
Why was ,mode=1777 removed from /tmp? --Ncopa (talk) 07:12, 15 May 2014 (UTC)
Hello! While following the directions for installing grub (via grub-install) I found the package efibootmgr is longer available using apk. Help! --Mnemolyst (talk) 22:40, 07 Nov 2019 (UTC)
The last two umount statements before the reboot require a newer version of umount than what comes in the standard Alpine download. I needed to add the package util-linux to get the correct version and although the page mentions the package in the early section about getting the boot device name it doesn't explicitly state to download it. --Sadbadman (talk) 06:45, 2 February 2020 (UTC)
I had difficulty with an encrypted /boot setup sda1=>efi, sda2=>crypt=>lvm(/root,/boot,swap). The instructions by default will result in using LUKS2 with Argon2. This is not actually supported by GRUB2 for an encrypted /boot setup (see Arch wiki article "GRUB", section "Encrypted_/boot" and GRUB bug 55093 - i can't post links yet). Until GRUB 2.06 is released and reaches alpine, users wanting encrypted /boot may need --type luks1 when running cryptsetup luksFormat. And once GRUB 2.06 does arrive, it may require using PBKDF2. Users will need to consult GRUB documentation when that time comes. --Stapleemptier (talk) 09:09, 16 February 2020 (UTC)
I was able to confirm the above about --type luks1 today. That, plus adding "GRUB_ENABLE_CRYPTODISK=y" to /etc/default/grub, allowed this procedure to work with v3.11. I will update accordingly. --Stapleemptier (talk) 00:38, 17 February 2020 (UTC)
Optional: Overwrite LUKS Partition with Random Data
Is this section still accurate since since Kernel 5.6, or roughly Alpine Linux version 3.13?
Doesn't /dev/random now do what is needed here without installing extra packages?
zcrayfish (talk) 18:56, 17 December 2021 (UTC)
Done
- Looks like psykose, et al, removed the references to mostly obsolete haveged.
- zcrayfish (talk) 03:23, 14 August 2023 (UTC)
Optimized for security suggestions lowers the memory cost for attacks
The currently suggested -+optimized for security+- in cryptsetup recommendations lowers the memory cost for attacks from the defaults. From the article:
you could either use the default settings (aes-xts-plain64 cipher with 256-bit key and Argon2 hashing with iter-time 2000ms), or you could use these settings which have added security with the trade-off being a non-noticeable decrease in performance on modern computers: Luks2 Optimized for security: # cryptsetup -v -c aes-xts-plain64 -s 512 --hash sha512 --pbkdf pbkdf2 --iter-time 5000 --use-random luksFormat /dev/sda2
The defaults in cryptsetup were changed from pbkdf2 to Argon2id exactly for this reason: To make it more memory costly in order to inhibit usage of gpus/asics in attacks. We recommend the exact opposite of what the maintainers of cryptsetup did. The compute power of GPUs have increased significantly more than those of CPUs as such I think to add memory cost to the attackers is valuable goal.
See also 10.4 from the cryptsetup FAQ
10.4 Why use Argon2 in LUKS 2 instead of PBKDF2? LUKS tries to be secure with not-so-good passwords. Bad passwords need to be protected in some way against an attacker that just tries all possible combinations. (For good passwords, you can just wait for the attacker to die of old age...) The situation with LUKS is not quite the same as with a password stored in a database, but there are similarities. LUKS does not store passwords on disk. Instead, the passwords are used to decrypt the volume-key with it and that one is stored on disk in encrypted form. If you have a good password, with, say, more than 80 bits of entropy, you could just put the password through a single crypto-hash (to turn it into something that can be used as a key) and that would be secure. This is what plain dm-crypt does. If the password has lower entropy, you want to make this process cost some effort, so that each try takes time and resources and slows the attacker down. LUKS1 uses PBKDF2 for that, adding an iteration count and a salt. The iteration count is per default set to that it takes 1 second per try on the CPU of the device where the respective passphrase was set. The salt is there to prevent precomputation. The problem with that is that if you use a graphics card, you can massively speed up these computations as PBKDF2 needs very little memory to compute it. A graphics card is (grossly simplified) a mass of small CPUs with some small very fast local memory per CPU and a large slow memory (the 4/6/8 GB a current card may have). If you can keep a computation in the small, CPU-local memory, you can gain a speed factor of 1000 or more when trying passwords with PBKDF2. Argon2 was created to address this problem. It adds a "large memory property" where computing the result with less memory than the memory parameter requires is massively (exponentially) slowed down. That means, if you set, for example, 4GB of memory, computing Argon2 on a graphics card with around 100kB of memory per "CPU" makes no sense at all because it is far too slow. An attacker has hence to use real CPUs and furthermore is limited by main memory bandwidth. Hence the large amount of memory used is a security feature and should not be turned off or reduced. If you really (!) understand what you are doing and can assure good passwords, you can either go back to PBKDF2 or set a low amount of memory used for Argon2 when creating the header.
--Johanneszab (talk) 11:38, 31 May 2024 (UTC)