Hi, I have couple questions about new LUKS2 format. I hope it's the appropriate place to ask them. > ---------------------------------------- > From: Milan Broz <gmazyland@xxxxxxxxx> > Sent: Wed Nov 01 10:44:29 CET 2017 > To: dm-crypt <dm-crypt@xxxxxxxx> > Subject: [ANNOUNCE] cryptsetup 2.0.0-rc1 > > > 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-sector 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.) > What are rough estimates for space overhead of metadata? 0,5%, 5%, 15%? What are rough estimates for writes overhead of journal? How concerns about authenticated encryption with FDE were resolved? i.e disk sector isn't the same size as cipher block, disk errors, see https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ > > 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-random with hmac-sha256 or hmac-sha512 as the authentication tag. > (Authentication key for HMAC is independently generated. This mode is very slow.) > $ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-random --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. > $ cryptsetup luksFormat --type luks2 <device> --cipher aes-gcm-random --integrity aead > > 3) ChaCha20 with Poly1305 authenticator (according to RFC7539) > $ cryptsetup luksFormat --type luks2 <device> --cipher chacha20-random --integrity poly1305 > As (1) and (2) algorithms have serious flaws (speed, nonce reuse) why they are implemented at all? I think number of supported algorithms isn't an advantage if you can't recommend them for actual usage. Are there included only for testing and will be removed in stable release? > > * Use of kernel keyring > > Kernel keyring is a storage for sensitive material (like cryptographic keys) > inside Linux kernel. > > LUKS2 uses keyring for two major functions: > > - To store volume key for dm-crypt where it avoids sending volume key in > every device-mapper ioctl structure. Volume key is also no longer directly > visible in a dm-crypt mapping table. The key is not available for the user > after dm-crypt configuration (obviously except direct memory scan). > Use of kernel keyring can be disabled in runtime by --disable-keyring option. > > - As a tool to automatically unlock LUKS device if a passphrase is put into > kernel keyring and proper keyring token is configured. > > This allows storing a secret (passphrase) to kernel per-user keyring by > some external tool (for example some TPM handler) and LUKS2, if configured, > will automatically search in the keyring and unlock the system. > For more info see Tokens section below. > Keeping encryption keys secret is reasonable however there are some serious issues with using kernel keyring for encryption keys storage as it's not easy to share keys between different users, sessions, threads, etc. Recently fscrypt developers had problems with using it, see https://www.spinics.net/lists/linux-fscrypt/msg00584.html I'm not sure if it also affects cryptsetup but it's a good thing to check just in case. Anyway I'm looking forward for stable release. Great work! Yours sincerely G. K. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
