On 11/01/2017 05:25 PM, Geo Kozey wrote:
Hi, I have couple questions about new LUKS2 format.
I hope it's the appropriate place to ask them.
Actually the best place for asking questions about cryptsetup/LUKS2 :)
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?
Milan will probably elaborate on this so just few notes from me:
With exception of (and with rc1 it's also optional) bundled
implementation of Argon2 pbkdf, libcryptsetup doesn't implement any
(new) algorithm.
Especially for device-mapper targets and encryption performed in
dm-crypt we use what's available in kernel already (provided via kernel
crypto API).
* 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.
We don't need to share it currently among processes. What cryptsetup
2.0.0 does with volume key is this:
1) we load volume key (encryption key) in thread keyring (as type
'logon' thus unreadable from userspace)
2) while loading dm-crypt mapping we pass key reference (description)
instead of loading volume key itself in hexbyte representation (as
cryptsetup did before 2.0.0 release) in dm-crypt table.
3) while in kernel we lookup the key referenced by description and load
it in crypto layer.
4) as long as dm-crypt mapping is active the key is always in crypto
layer (unless the device is suspended with key wiped).
IOW we have one less volume key copy in system memory and the key can't
be exposed accidentally via "dmsetup table" command anymore. Also we're
going to use kernel keyring more in later LUKS2 features like
online-reencryption where we need to update dm-crypt mappings frequently.
The second use case when we store user passphrase in kernel keyring
(tokens): The similar use case is in sysmted-cryptsetup utility for
activating LUKS devices early during boot. They store the passphrase in
kernel keyring and later try to activate LUKS volume with that
passphrase. I haven't seen any severe issue with that so far. But as
always bug reports are welcome!
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.
I believe this is unrelated due to fact that for normal operation (after
dm-crypt gets activated) the volume key is used exactly the same as
before. From crypto layer.
Kind regards
Ondrej
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
