meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
linux:fs:luks [2015/03/28 14:36] – niziaklinux:fs:luks [2021/02/17 08:51] (current) – niziak
Line 1: Line 1:
-[[https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system|https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system]]+[[https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system|https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system|dm-crypt/Encrypting an entire system]] 
 + 
 +====== LUKS on LVM vs LVM on LUKS ======
  
 LUKS on LVM Benefit: LUKS on LVM Benefit:
Line 6: Line 8:
   - good for multiuser environment   - good for multiuser environment
   - root system can be on unencrypted partition (no password to boot). The same can be achieved with LVM on LUKS on separate partition.   - root system can be on unencrypted partition (no password to boot). The same can be achieved with LVM on LUKS on separate partition.
 +  - Volumes can span on multiple drives
 +  - LVM cache is caching encrypted data (no unecnrypted data leak to cache device).
 +    - one common SSD cache device can be used if you have encrypted (data) and unecrypted (system) partitions on LVM
  
-LVM on LUKS (preffered) Block device is encrypted and on top of block device LVM is configured. Benefit:+LVM on LUKS (preffered) 
 + 
 +Block device is encrypted and on top of block device LVM is configured. Benefit:
  
   - one unlock of block device give access to all LVM volume created on it.   - one unlock of block device give access to all LVM volume created on it.
   - it is easier to change volumes sizes without touching encryption layer   - it is easier to change volumes sizes without touching encryption layer
 +  - LVM cache is caching decrypted data
 +    - workaround: encrypt also cache device, but for mixed setup (unencrypted and crypted partition) it is need to divide cache device into 2 volumes to serve unencrypted cache for system (no need to provide unlock password).
  
 +====== Performance ======
 +IT depends on HW acceleration
 <code> <code>
 cryptsetup benchmark cryptsetup benchmark
 </code> </code>
 +Best choice for AMD A4-5300 APU:
 +<code>
 +# Tests are approximate using memory only (no storage IO).
 +PBKDF2-sha1       448876 iterations per second
 +PBKDF2-sha256     352344 iterations per second
 +PBKDF2-sha512     362077 iterations per second
 +PBKDF2-ripemd160  500274 iterations per second
 +#  Algorithm | Key |  Encryption |  Decryption
 +     aes-cbc   128b   429.0 MiB/s  1275.9 MiB/s
 +     aes-cbc   256b   333.0 MiB/s   770.0 MiB/s
 +     aes-xts   256b   903.8 MiB/s  1023.9 MiB/s
 +     aes-xts   512b   902.7 MiB/s   928.5 MiB/s
 +</code>
 +
 +
 +
 ====== Advices ====== ====== Advices ======
 +
 +== Cipher ==
 +  * AES well known, accelerated by common HW
 +  * Twofish (faster SW implementation comparing to AES)
 +
 +== Chaining mode ==
 +
 +  * CBC. Every block will be XOR’ed with the encrypted previous block. This effectively means that every block depends on the output of the previous block. This mode is vulnerable to watermark attack, where attacker can inject own data to crypted block chain (for filesystem, access to block device is needed)
 +
 +  * EBC (Electronic Codebook), each block is encrypted with the same key
 +  * XTS. Is counter-oriented chaining mode. It's an evolution of XEX (actually: "XEX-based tweaked-codebook mode with ciphertext stealing"), while XEX ("xor-encrypt-xor") is a non-trivial counter-based chaining mode; neither of which I can claim to completely understand. XTS is already very widely supported and looks promising, but may have issues. The primary important details are these: No fancy IVs are necessary (plain or plain64 is fine), and half of your key is used by XTS, meaning your original key must be twice as long (hence 512-bit instead of 256-bit). 
 +
 +== IV (Initalisation Vector) calculation ==
 +  * plain
 +
 +  * plain64
 +Is an IV generation mechanism that simply passes the 64-bit sector index directly to the chaining algorithm as the IV. plain truncates that to 32-bit. Certain chaining modes such as XTS don't need the IV to be unpredictable, while modes like CBC would be vulnerable to fingerprinting/watermarking attacks if used with plain IVs.
 +
 +  * ESSIV 
 +
 +("Encrypted salt-sector initialization vector") allows the system to create IVs based on a hash including the sector number and encryption key. This allows you to jump straight to to the sector you want without resorting to predictable IVs, and therefore protects you from watermarking attacks.
 +
 +LUKS' key derivation method
 +  * SHA256
 +
 +
 +plain vs plain64
 +  * Do not use plain for disc greater than 2TB (use plain64 instead)
  
 XTS XTS
  
   * doesn't require ESSIV (aes-xts-plain)   * doesn't require ESSIV (aes-xts-plain)
-  * <font 14px line-height: 18.2000007629395px;/ ;;rgb(51, 51, 51) font-family: 'Helvetica Neue', Arial, sans-serif; font-size: 14px; line-height: 18.2000007629395px;;;inherit>half of your key is used by XTS, meaning your original key must be twice as long (hence 512-bit instead of 256-bit).</font>+  * half of your key is used by XTS, meaning your original key must be twice as long (hence 512-bit instead of 256-bit).</font>
  
 CBC CBC
Line 26: Line 81:
   * should be protected with ESSIV (aes-cbc-essiv)   * should be protected with ESSIV (aes-cbc-essiv)
  
-​If password are used instead of keyfile:+​If password are used instead of keyfile, to prevent brute force attack:
  
   * choose very long password to prevent dictionary attacks.   * choose very long password to prevent dictionary attacks.
-  * use big hash like SHA512 +  * use big hash like SHA512 (--hash=sha512) 
- +  * increase number of iterations (default it is set to 1000 ms)
-<font 12px line-height: 17px; white-space: pre-wrap; background-color: rgb(243, 243, 243);/ ;;rgb(51, 51, 51) font-family: 'Helvetica Neue', Arial, sans-serif; font-size: 14px; line-height: 18.2000007629395px;;;rgb(243, 243, 243)>aes-cbc-essiv:sha256</font> +
- +
-===== Setup /dev/sda5 as LUKS device: =====+
  
 +===== Fill with random data =====
 +<code bash>badblocks -c 10240 -s -w -t random -v /dev/sda5</code>
 +or (faster, only writes). Block size for dd has to be big, to avoid re-reading data from encrypted block.
 <code> <code>
-cryptsetup -y -v luksFormat /dev/sda5+cryptsetup open --type plain /dev/sda5 tempcontainer 
 +dd if=/dev/zero of=/dev/mapper/tempcontainer bs=64M 
 +cryptsetup luksClose tempcontainer
 </code> </code>
  
-will create aes-xts-plain64 256bits +===== Setup /dev/sda5 as LUKS device: ===== 
- +<code bash> 
-<code> +cryptsetup luksFormat -y -v /dev/sda5
-cryptsetup luksFormat -c aes-cbc-plain -s 256 /dev/sda5 +
-cryptsetup luksFormat -c aes-cbc-plain -s 256 --hash sha1 /dev/sda5+
 </code> </code>
  
-TOOD:+will create by default **aes-xts-plain64**  256bits.
  
-- SHA512+Another examples:
  
-cryptsetup -v -c aes-cbc-essiv:sha256 -s 256 -y luksFormat /dev/loop0+<code bash> 
 +cryptsetup luksFormat --cipher aes-cbc-plain --key-size 256 /dev/sda5 
 +cryptsetup luksFormat --cipher aes-cbc-plain --key-size 256 --hash sha1 -i 2000 --use-random /dev/sda5 
 +cryptsetup luksFormat --cipher aes-cbc-essiv:sha256 --key-size 256 --verify-passphrase -v /dev/sda5 
 +cryptsetup luksFormat --cipher aes-xts-plain --key-size 256 --verify-passphrase -v /dev/sda5 
 +cryptsetup luksFormat --cipher aes-xts-plain --key-size 512 --verify-passphrase -v /dev/sda5 
 +</code>
  
-- iterations+<code bash> 
 +cryptsetup --verify-passphrase -v --cipher aes-cbc-plain64 --key-size 128 --hash sha512 --iter-time 3000 --use-random luksFormat /dev/sda5 
 +</code> 
 + 
 +<code bash> 
 +cryptsetup luksFormat --cipher aes-xts-plain --verify-passphrase -v  --key-size 512  --hash sha512 --iter-time 3000 --use-random /dev/sdb6 
 +</code>
  
 ===== Open LUKS device ===== ===== Open LUKS device =====
  
 +<code>
 cryptsetup luksOpen /dev/sda5 sda5 cryptsetup luksOpen /dev/sda5 sda5
 +</code>
  
 ===== Examing status of LUKS ===== ===== Examing status of LUKS =====
  
-cryptsetup status sda5 cryptsetup luksDump /dev/sda5+<code> 
 +cryptsetup status sda5  
 +cryptsetup luksDump /dev/sda5 
 +</code>
  
 ===== Closing LUKS device ===== ===== Closing LUKS device =====
  
 +<code>
 cryptsetup luksClose sda5 cryptsetup luksClose sda5
 +</code>
 +
 +====== References ======
 +[[security.stackexchange.com/questions/40208/recommended-options-for-luks-cryptsetup]]
 +
 +[[https://kiza.eu/journal/entry/697]]
 +
 +