|
|
| (4 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {{Draft}} | | {{Draft}}{{Guide |
| | | 0 = Intermediate |
| | }} |
| | Some external information that may also be helpful is the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki]. |
|
| |
|
| This page is written with [[Tiers|Intermediate]] users in mind, but of course everyone is encouraged to try to understand.
| | == Guide to Decent LUKS [[Security]] on [[Linux]] == |
| | | LUKS is the Linux Unified Key Setup. This guide explains all of the different part of the LUKS system and why they are important. Check out the advanced guide if you want to know more about how to set these options and what they do in more detail. |
| For more more info on this topic, check the [[LUKS/Advanced|Advanced Guide]].
| |
| | |
| Some external resources that may also be helpful are the [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions cryptsetup FAQ] and [https://wiki.archlinux.org/title/Dm-crypt/Device_encryption Arch Wiki].
| |
| | |
| = Guide to Decent LUKS Security on Linux =
| |
| If you just want to know the "best" command to run, you can skip to the bottom. But reading this Guide is encouraged, as it will give you a better understand of what the options do, and how they will affect the security of your data!
| |
|
| |
|
| == Ciphers == | | == Ciphers == |
| Ciphers scramble the files that will be saved, so it's important to pick a good one. Computers have, for many decades now, had | | Ciphers scramble the [[files]] that will be saved, so it's important to pick a good one. Almost all computers have, for many decades now, have had built in support for [[AES]], making it the fastest and most secure option for pretty much everyone. |
|
| |
|
| built in support for [[AES]], making it the fastest and most secure option for pretty much everyone. | | == On-disk Format == |
| | The on-disk format helps prevent the scrambled files from being modified while the computer is turned off. Since most computers already have built in support for [[XTS]], it makes it the fastest and most secure option. |
|
| |
|
| == Initialization Vectors ( IV ) == | | == Initialization Vectors ( IV ) == |
| The purpose of IV is to ad some randomness different blocks of the disk , so that overall patterns cannot be discovered . ESSIV ( Encrypted salt-sector initialization vector ) was set as default for CBC to mitigate the fingerprinting issue , but this does not help CBC's issues with malleability . For XTS , plain64 is recommended over plain , since it has no performance impact , and plain has some data leaking vulnerabilities that are viable on disks larger than 2TiB . XTS not being vulnerable to fingerprinitng , does not need the added overhead of ESSIV .
| | By looking at the scrambled files on the disk, it is possible to find some patterns like, for example, images. IV helps prevent this! If you're using XTS, [[plain64]] is the fastest and most secure option. |
|
| |
|
| == Password Hashing == | | == [[Password]] [[Hashing]] == |
| The hashing algorithm is intended to make weak passwords harder to break , so a very good password does not really need much hashing . Argon2 is optimized to be impossible to brute-force on devices with limited memory , most notably , graphics cards . The point is to force the attacker to use their CPU , which is not usually not nearly as quick as a GPU for this kind of task . Unless you're primarily concerned about some APT trying to break into your device , it is pretty good tradeoff . If your device is very memory constrained ( like under 4GB ), you ''may'' want to consider using PBKDF2 ( Password-Based Key Derivation Function ) . You will almost certainly want to increase the iteration time more though , as it is far weaker to GPU brute-forcing . For a small note on Argon2 , it has a few different variants . Argon2i is weakest to brute-forcing , but has strong side-channel protection . It's generally not safe to use 2i with anything less than 10 iterations . Conversely , while Argon2d is most secure against brute force attacks , it is more susceptible to side channel timing attacks than Argon2id . Unless you are ''really'' not concerned about side-channel attacks , Argon2id is the most well rounded and therefore the best choice .
| | Password hashing helps make passwords that are not secure harder to break. A ''very'' secure password needs no hashing, but since making a very secure password is difficult, it's a good idea to use hashing. [[Argon2]] is the most secure option for most users. |
|
| |
|
| == Iteration Time == | | == Iteration Time == |
| This defines how long your computer is going to spend hashing the password . More iteration is generally better , and is mostly a question of how long you willing to spend waiting for your computer to initially decrypt the drive . Do note that it doesn't decrease the speed of the drive after the key is decrypted . To be very clear , high iteration count is not an alternative to a secure password ! 2 seconds ( 2000ms ) is generally the recommended default , though of course you are welcome to set it as high as you are willing to tolerate . Make sure your computer is not set to any " low-power mode " when setting up the disk , as this will affect the time it takes to hash .
| | Since some computers are faster than others, your computer will test to see how many times it can hash your password in this amount of time. The default is 2 seconds, and that's usually good enough. If your computer is very slow, and you're OK with waiting a bit longer for a more secure hash, you may wanna set it for a bit longer! |
| | |
| Very important note ! Make sure your password is secure ! Using something short is a very bad idea . Using a string of characters from a well known book is also not a great idea ! Something like a diceware password with at least 6 words is generally a good idea !
| |
| | |
| == Benchmarking ==
| |
| If you want to see for yourself how fast these various algorithms will run on your computer, you can use <code>cryptsetup benchmark .</code><blockquote> # Tests are approximate using memory only (no storage IO).
| |
| | |
| PBKDF2-sha1 1736052 iterations per second for 256-bit key
| |
| | |
| PBKDF2-sha256 3355443 iterations per second for 256-bit key
| |
| | |
| PBKDF2-sha512 1096836 iterations per second for 256-bit key
| |
| | |
| PBKDF2-ripemd160 434733 iterations per second for 256-bit key
| |
| | |
| PBKDF2-whirlpool 364088 iterations per second for 256-bit key
| |
| | |
| argon2i 4 iterations, 735656 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
| |
| | |
| argon2id 4 iterations, 842046 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
| |
| | |
| # Algorithm | Key | Encryption | Decryption
| |
| | |
| aes-cbc 128b 594.1 MiB/s 1434.3 MiB/s
| |
| | |
| serpent-cbc 128b 59.8 MiB/s 371.1 MiB/s
| |
| | |
| twofish-cbc 128b 123.5 MiB/s 200.0 MiB/s
| |
| | |
| aes-cbc 256b 423.9 MiB/s 1284.2 MiB/s
| |
| | |
| serpent-cbc 256b 61.0 MiB/s 394.5 MiB/s
| |
| | |
| twofish-cbc 256b 136.8 MiB/s 240.4 MiB/s
| |
| | |
| aes-xts 256b 2196.7 MiB/s 2414.8 MiB/s
| |
| | |
| serpent-xts 256b 445.6 MiB/s 401.0 MiB/s
| |
| | |
| twofish-xts 256b 220.3 MiB/s 236.9 MiB/s
| |
| | |
| aes-xts 512b 2031.5 MiB/s 2117.4 MiB/s
| |
| | |
| serpent-xts 512b 445.2 MiB/s 437.6 MiB/s
| |
| | |
| twofish-xts 512b 221.9 MiB/s 249.3 MiB/s</blockquote>As you can see from this sample output , aes-xts is the fastest ! Assuming you're on an x86 machine , this will almost certainly also be the case for you . You'll also notice Argon2i only has 4 iterations here , making it unsafe to use . You can add <code>-i 5000</code> to test 5000ms as an example , to see how many iterations it achieves .
| |
| | |
| == /dev/urandom ==
| |
| Though unlikely , to avoid an entropy-starved situation ( meaning the random numbers are not random enough ) , you can use <code>--use-random</code> when setting up the disk .
| |
| | |
| There's apparently a lot of debate and conflicting information online about the difference between /dev/random and /dev/urandom online . The main difference is that /dev/random will wait when it estimates that not enough entropy has been gathered . Since it only affects when you initially setup the disk though , waiting for it to gather enough entropy is generally a good idea . Whether its method of ensuring it has gathered enough data is effective , is also somewhat debated , but it certainly doesn't hurt .
| |
| | |
| = Summary =
| |
| Unless you have a strong reason to doubt AES-256 ( which is also post-quantum resistant ) , AES should be used . Using CBC even with ESSIV does not have any compelling reasons for consideration , so XTS likely your best choice , especially since it will be significantly faster to encrypt / decrypt on x86 . These options are the default for good reason , and unless you have a particularly special setup or threat model ; like if for example , if your CPU does not have hardware accelerated AES , or if it had a known vulnerability . Lastly , Argon2id is generally your best option for hashing .
| |
| | |
| == Disk Setup ==
| |
| Assuming your disk is already correctly partitioned , setting up the disk is as simple as :
| |
| | |
| <code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>
| |
| | |
| As mentioned previously , these settings are the default on the latest cryptsetup ( with the exception of --use-random ) , but setting them manually ensures that they are correct on older versions . You can also check what the defaults are for your system by running cryptsetup --help . You can then verify that it was setup correctly with :
| |
| | |
| <code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>
| |
| | |
| Once it has been setup , it can be opened with :
| |
| | |
| <code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>
| |
| | |
| Note that " dm_name " can be set to whatever you like , and the disk will be available at :
| |
| | |
| <code>/dev/mapper/dm_name</code>
| |
| | |
| Then you will need to format it , via something like :
| |
| | |
| <code>mkfs.ext4 /dev/mapper/dm_name</code>
| |
| | |
| Of course , you'll want to replace mkfs.ext4 with the setup command for your preferred partition type .
| |
This article is currently a draft. It has not yet been completed.
This is an Intermediate difficulty guide. All versions:
Some external information that may also be helpful is the cryptsetup FAQ and Arch Wiki.
LUKS is the Linux Unified Key Setup. This guide explains all of the different part of the LUKS system and why they are important. Check out the advanced guide if you want to know more about how to set these options and what they do in more detail.
Ciphers
Ciphers scramble the files that will be saved, so it's important to pick a good one. Almost all computers have, for many decades now, have had built in support for AES, making it the fastest and most secure option for pretty much everyone.
The on-disk format helps prevent the scrambled files from being modified while the computer is turned off. Since most computers already have built in support for XTS, it makes it the fastest and most secure option.
Initialization Vectors ( IV )
By looking at the scrambled files on the disk, it is possible to find some patterns like, for example, images. IV helps prevent this! If you're using XTS, plain64 is the fastest and most secure option.
Password hashing helps make passwords that are not secure harder to break. A very secure password needs no hashing, but since making a very secure password is difficult, it's a good idea to use hashing. Argon2 is the most secure option for most users.
Iteration Time
Since some computers are faster than others, your computer will test to see how many times it can hash your password in this amount of time. The default is 2 seconds, and that's usually good enough. If your computer is very slow, and you're OK with waiting a bit longer for a more secure hash, you may wanna set it for a bit longer!
