Talk:LVM on LUKS - Revision history

Johanneszab: /* Optimized for security suggestions lowers the memory cost for attacks */

2024-05-31T11:45:36Z

Optimized for security suggestions lowers the memory cost for attacks

← Older revision		Revision as of 11:45, 31 May 2024
Line 24:		Line 24:
	== Optimized for security suggestions lowers the memory cost for attacks ==		== 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:		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:

	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:		Luks2 Optimized for security:

Johanneszab: /* Optimized for security suggestions lowers the memory cost for attacks */

2024-05-31T11:43:03Z

Optimized for security suggestions lowers the memory cost for attacks

← Older revision		Revision as of 11:43, 31 May 2024
Line 24:		Line 24:
	== Optimized for security suggestions lowers the memory cost for attacks ==		== Optimized for security suggestions lowers the memory cost for attacks ==

	The currently suggested "optimized for security~~" luksFormat~~ recommendations lowers the memory cost for attacks. From the article:		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:		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:		Luks2 Optimized for security:
Line 32:		Line 32:
	# cryptsetup -v -c aes-xts-plain64 -s 512 --hash sha512 --pbkdf pbkdf2 --iter-time 5000 --use-random luksFormat /dev/sda2		# cryptsetup -v -c aes-xts-plain64 -s 512 --hash sha512 --pbkdf pbkdf2 --iter-time 5000 --use-random luksFormat /dev/sda2

	The defaults in ~~luksFormat~~ were changed from pbkdf2 to Argon2id exactly for this reason~~, to~~ make it more memory costly in order to inhibit usage of gpus/asics. The compute power of GPUs have increased significantly more than those of CPUs as such I think ~~added~~ memory cost to the ~~attacker~~ is valuable goal.		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 [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#10-luks2-questions 10.4 from the cryptsetup FAQ]		See also [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#10-luks2-questions 10.4 from the cryptsetup FAQ]

Johanneszab: /* Optimized for security suggestions lower memory cost */

2024-05-31T11:38:09Z

Optimized for security suggestions lower memory cost

← Older revision		Revision as of 11:38, 31 May 2024
Line 22:		Line 22:
	:[[User:Zcrayfish\|zcrayfish]] ([[User talk:Zcrayfish\|talk]]) 03:23, 14 August 2023 (UTC)		:[[User:Zcrayfish\|zcrayfish]] ([[User talk:Zcrayfish\|talk]]) 03:23, 14 August 2023 (UTC)

	== Optimized for security suggestions ~~lower~~ memory cost ==		== Optimized for security suggestions lowers the memory cost for attacks ==

	The currently suggested "optimized for security" luksFormat recommendations lowers the memory cost for attacks. From the article:		The currently suggested "optimized for security" luksFormat recommendations lowers the memory cost for attacks. 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:		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:		Luks2 Optimized for security:
Line 32:		Line 32:
	# cryptsetup -v -c aes-xts-plain64 -s 512 --hash sha512 --pbkdf pbkdf2 --iter-time 5000 --use-random luksFormat /dev/sda2		# cryptsetup -v -c aes-xts-plain64 -s 512 --hash sha512 --pbkdf pbkdf2 --iter-time 5000 --use-random luksFormat /dev/sda2

	The defaults in luksFormat were changed from pbkdf2 to Argon2id exactly for this reason, to make it more memory costly in order to inhibit usage ~~for~~ gpus/asics.		The defaults in luksFormat were changed from pbkdf2 to Argon2id exactly for this reason, to make it more memory costly in order to inhibit usage of gpus/asics. The compute power of GPUs have increased significantly more than those of CPUs as such I think added memory cost to the attacker is valuable goal.

	See also [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#10-luks2-questions 10.4 from the cryptsetup FAQ]		See also [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#10-luks2-questions 10.4 from the cryptsetup FAQ]
Line 73:		Line 73:
	and can assure good passwords, you can either go back to PBKDF2 or set a		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.		low amount of memory used for Argon2 when creating the header.

			--[[User:Johanneszab\|Johanneszab]] ([[User talk:Johanneszab\|talk]]) 11:38, 31 May 2024 (UTC)

Johanneszab: /* Optimized for security suggestions lower memory cost */ new section

2024-05-31T11:35:17Z

Optimized for security suggestions lower memory cost: new section

← Older revision		Revision as of 11:35, 31 May 2024
Line 21:		Line 21:
	:Looks like psykose, et al, removed the references to mostly obsolete haveged.		:Looks like psykose, et al, removed the references to mostly obsolete haveged.
	:[[User:Zcrayfish\|zcrayfish]] ([[User talk:Zcrayfish\|talk]]) 03:23, 14 August 2023 (UTC)		:[[User:Zcrayfish\|zcrayfish]] ([[User talk:Zcrayfish\|talk]]) 03:23, 14 August 2023 (UTC)

			== Optimized for security suggestions lower memory cost ==

			The currently suggested "optimized for security" luksFormat recommendations lowers the memory cost for attacks. 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 luksFormat were changed from pbkdf2 to Argon2id exactly for this reason, to make it more memory costly in order to inhibit usage for gpus/asics.

			See also [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#10-luks2-questions 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.

Zcrayfish: /* Optional: Overwrite LUKS Partition with Random Data */ Resolved.

2023-08-14T03:23:50Z

Optional: Overwrite LUKS Partition with Random Data: Resolved.

← Older revision		Revision as of 03:23, 14 August 2023
Line 14:		Line 14:
	== Optional: Overwrite LUKS Partition with Random Data ==		== Optional: Overwrite LUKS Partition with Random Data ==

	Is this section still accurate since since Kernel 5.6, or roughly Alpine Linux version 3.13?		<s>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?		Doesn't /dev/random now do what is needed here without installing extra packages?</s>
	[[User:Zcrayfish\|zcrayfish]] ([[User talk:Zcrayfish\|talk]]) 18:56, 17 December 2021 (UTC)		[[User:Zcrayfish\|zcrayfish]] ([[User talk:Zcrayfish\|talk]]) 18:56, 17 December 2021 (UTC)

			:{{done}}
			:Looks like psykose, et al, removed the references to mostly obsolete haveged.
			:[[User:Zcrayfish\|zcrayfish]] ([[User talk:Zcrayfish\|talk]]) 03:23, 14 August 2023 (UTC)

Zcrayfish: /* Optional: Overwrite LUKS Partition with Random Data */ Forgot signature. Oops.

2021-12-17T18:56:18Z

Optional: Overwrite LUKS Partition with Random Data: Forgot signature. Oops.

← Older revision		Revision as of 18:56, 17 December 2021
Line 16:		Line 16:
	Is this section still accurate since since Kernel 5.6, or roughly Alpine Linux version 3.13?		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?		Doesn't /dev/random now do what is needed here without installing extra packages?
			[[User:Zcrayfish\|zcrayfish]] ([[User talk:Zcrayfish\|talk]]) 18:56, 17 December 2021 (UTC)

Zcrayfish: /* Optional: Overwrite LUKS Partition with Random Data */ new section

2021-12-17T18:55:58Z

Optional: Overwrite LUKS Partition with Random Data: new section

← Older revision		Revision as of 18:55, 17 December 2021
Line 11:		Line 11:

	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. --[[User:Stapleemptier\|Stapleemptier]] ([[User talk:Stapleemptier\|talk]]) 00:38, 17 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. --[[User:Stapleemptier\|Stapleemptier]] ([[User talk: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?

Stapleemptier at 00:38, 17 February 2020

2020-02-17T00:38:56Z

← Older revision		Revision as of 00:38, 17 February 2020
Line 9:		Line 9:
	----		----
	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. --[[User:Stapleemptier\|Stapleemptier]] ([[User talk:Stapleemptier\|talk]]) 09:09, 16 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. --[[User:Stapleemptier\|Stapleemptier]] ([[User talk: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. --[[User:Stapleemptier\|Stapleemptier]] ([[User talk:Stapleemptier\|talk]]) 00:38, 17 February 2020 (UTC)

Stapleemptier: commends on grub2 and encrypted boot

2020-02-16T09:09:03Z

commends on grub2 and encrypted boot

← Older revision		Revision as of 09:09, 16 February 2020
Line 7:		Line 7:
	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.		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.
	--[[User:Sadbadman\|Sadbadman]] ([[User talk:Sadbadman\|talk]]) 06:45, 2 February 2020 (UTC)		--[[User:Sadbadman\|Sadbadman]] ([[User talk: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. --[[User:Stapleemptier\|Stapleemptier]] ([[User talk:Stapleemptier\|talk]]) 09:09, 16 February 2020 (UTC)

Sadbadman at 06:46, 2 February 2020

2020-02-02T06:46:31Z

← Older revision		Revision as of 06:46, 2 February 2020
Line 4:		Line 4:
	Hello! While following the directions for installing grub (via grub-install) I found the package efibootmgr is longer available using apk. Help!		Hello! While following the directions for installing grub (via grub-install) I found the package efibootmgr is longer available using apk. Help!
	--[[User:Mnemolyst\|Mnemolyst]] ([[User talk:Mnemolyst\|talk]]) 22:40, 07 Nov 2019 (UTC)		--[[User:Mnemolyst\|Mnemolyst]] ([[User talk: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.		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.
	--[[User:Sadbadman\|Sadbadman]] ([[User talk:Sadbadman\|talk]]) 06:45, 2 February 2020 (UTC)		--[[User:Sadbadman\|Sadbadman]] ([[User talk:Sadbadman\|talk]]) 06:45, 2 February 2020 (UTC)