Debian User Forums

4.8 Algorithm Definition Examples
The LUKS2 specification supports all algorithms that are provided by the cryptographic backend (in the Linux case by kernel dm-crypt and userspace cryptographic library).
[..]
AEAD algorithms are experimental and require dm-integrity support.

[..]
* Authenticated disk (sector) encryption (EXPERIMENTAL)

Legacy Full disk encryption (FDE), for example, LUKS1, is a length-preserving encryption (plaintext is the same size as a ciphertext). Such FDE can provide data confidentiality, but cannot provide sound data integrity protection.

Full disk authenticated encryption is a way how to provide both confidentiality and data integrity protection. Integrity protection here means not only detection of random data corruption (silent data corruption) but also prevention of an unauthorized intentional change of disk sector content.

NOTE: Integrity protection of this type cannot prevent a replay attack. An attacker can replace the device or its part of the old content, and it cannot be detected. If you need such protection, better use integrity protection on a higher layer.

For data integrity protection on the sector level, we need additional per-sector metadata space. In LUKS2 this space is provided by a new device-mapper dm-integrity target (available since kernel 4.12). Here the integrity target provides only reliable per-sector metadata store, and the whole authenticated encryption is performed inside dm-crypt stacked over the dm-integrity device.

For encryption, Authenticated Encryption with Additional Data (AEAD) is used.

Every sector is processed as a encryption request of this format:

|----- AAD -------|------ DATA -------|-- AUTH TAG --|
| (authenticated) | (auth+encryption) | |
| sector_LE | IV | sector in/out | tag in/out |

AEAD encrypts the whole sector and also authenticates sector number (to detect sector relocation) and also authenticates Initialization Vector.

AEAD encryption produces encrypted data and authentication tag. The authenticated tag is then stored in per-sector metadata space provided by dm-integrity.

Most of the current AEAD algorithms requires IV as a nonce, value that is never reused. Because sector number, as an IV, cannot be used in this environment, we use a new random IV (IV is a random value generated by system RNG on every write). This random IV is then stored in the per-ector metadata as well.

Because the authentication tag (and IV) requires additional space, the device provided for a user has less capacity. Also, the data journalling means that writes are performed twice, decreasing throughput.

This integrity protection works better with SSDs. If you want to ignore dm-integrity data journal (because journalling is performed on some higher layer or you just want to trade-off performance to safe recovery), you can switch journal off with --integrity-no-journal option. (This flag can be stored persistently as well.)

Note that (similar to integritysetup) the device read will fail if authentication tag is not initialized (no previous write). By default cryptsetup run wipe of a device (writing zeroes) to initialize authentication tags. This operation can be very time-consuming. You can skip device wipe using --integrity-no-wipe option.

To format LUKS2 device with integrity protection, use new --integrity option.

For now, there are very few AEAD algorithms that can be used, and some of them are known to be problematic. In this release we support only a few of AEAD algorithms (options are for now hard coded), later this extension will be completely algorithm-agnostic.

For testing of authenticated encryption, these algorithms work for now:

1) aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the authentication tag.
(Common FDE mode + independent authentication tag. Authentication key for HMAC is independently generated. This mode is very slow.)

Code: Select all

$ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-plain64 --integrity hmac-sha256

2) aes-gcm-random (native AEAD mode)
DO NOT USE in production! The GCM mode uses only 96-bit nonce, and possible collision means fatal security problem. GCM mode has very good hardware support through AES-NI, so it is useful for performance testing.

Code: Select all

$ cryptsetup luksFormat --type luks2 <device> --cipher aes-gcm-random --integrity aead

3) ChaCha20 with Poly1305 authenticator (according to RFC7539)

Code: Select all

$ cryptsetup luksFormat --type luks2 <device> --cipher chacha20-random --integrity poly1305

To specify AES128/AES256 just specify proper key size (without possible authentication key). Other symmetric ciphers, like Serpent or Twofish, should work as well. The mode 1) and 2) should be compatible with IEEE 1619.1 standard recommendation.

$  cryptsetup luksFormat --type luks2 /dev/sdX $PARAMS

• Code: Select all

   --cipher aes-xts-plain64 --integrity hmac-sha256

• Code: Select all

   --cipher chacha20-random --integrity poly1305

# fallocate -l 50Mib image
# losetup /dev/loop0 $PWD/image
# cryptsetup luksFormat --type luks2 /dev/loop0 --cipher chacha20-random --integrity poly1305
# cryptsetup luksOpen /dev/loop0 encrypted_patition 
# mkfs.ext4 /dev/mapper/encrypted_patition
# lsblk /dev/loop0 
NAME                     MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
loop0                      7:0    0   50M  0 loop  
└─encrypted_patition_dif 253:0    0 31,6M  0 crypt 
  └─encrypted_patition   253:1    0 31,6M  0 crypt 
# mount /dev/mapper/encrypted_patition /mnt
# cd mnt
# touch file
# umount /mnt
# cryptsetup luksClose encrypted_patition
# losetup -d  /dev/loop0