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/29 22:25] – 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 vs LVM on LUKS ======
Line 8: 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) LVM on LUKS (preffered)
Line 15: Line 18:
   - 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>
 +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> </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 plain vs plain64
Line 37: Line 84:
  
   * 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 +  * increase number of iterations (default it is set to 1000 ms)
- +
-===== 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 open --type plain /dev/sda5 tempcontainer
 +dd if=/dev/zero of=/dev/mapper/tempcontainer bs=64M
 +cryptsetup luksClose tempcontainer
 +</code>
 +
 +===== Setup /dev/sda5 as LUKS device: =====
 +<code bash>
 cryptsetup luksFormat -y -v /dev/sda5 cryptsetup luksFormat -y -v /dev/sda5
 </code> </code>
  
-will create by default **aes-xts-plain64**  256bits+will create by default **aes-xts-plain64**  256bits.
  
-<code> +Another examples: 
-cryptsetup luksFormat -c aes-cbc-plain -s 256 /dev/sda5 + 
-cryptsetup luksFormat -c aes-cbc-plain -s 256 --hash sha1 -i 2000 --use-random /dev/sda5 +<code bash> 
-cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 -y -v /dev/sda5 +cryptsetup luksFormat --cipher aes-cbc-plain --key-size 256 /dev/sda5 
-cryptsetup -y -v -c aes-xts-plain:sha256 -s 256 luksFormat /dev/sda5 +cryptsetup luksFormat --cipher aes-cbc-plain --key-size 256 --hash sha1 -i 2000 --use-random /dev/sda5 
-cryptsetup -y -v -c aes-xts-plain:sha256 -s 512 luksFormat /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> 
 + 
 +<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> </code>
  
Line 65: Line 130:
  
 <code> <code>
-cryptsetup status sda5 cryptsetup luksDump /dev/sda5+cryptsetup status sda5  
 +cryptsetup luksDump /dev/sda5
 </code> </code>
  
Line 73: Line 139:
 cryptsetup luksClose sda5 cryptsetup luksClose sda5
 </code> </code>
 +
 +====== References ======
 +[[security.stackexchange.com/questions/40208/recommended-options-for-luks-cryptsetup]]
 +
 +[[https://kiza.eu/journal/entry/697]]
 +
 +