Arch Linux

860lacov

Member

Registered: 2020-05-02

Posts: 497

[SOLVED] Need a little help with cryptsetup understanding

Wiki says:
Defaults for cryptsetup are:

--type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase

--key-size -s
    256 (512 for XTS)     512     By default a 512 bit key-size is used for XTS ciphers. Note however that XTS splits the supplied key in half, so this results in AES-256 being used.

1. Does that mean that default key size is going to be 128 bit? I suppose it is more than enough for me, but in benchmark I get the best result for 256bit. So do I have to set -s 512 if I want 256 bit key?
2. Are bkdf-memory and pbkdf-parallel important only when drive is opened and closed or for file operations too?
3. I read that sha256 has is more than enough currently, but I wasn't able to understand why. Could anyone please try to explain why to use sha256 and not sha512 or sha3-512?

Last edited by 860lacov (2024-05-12 12:28:40)

loqs

Member

Registered: 2014-03-06

Posts: 18,913

Re: [SOLVED] Need a little help with cryptsetup understanding

1. Does that mean that default key size is going to be 128 bit? I suppose it is more than enough for me, but in benchmark I get the best result for 256bit. So do I have to set -s 512 if I want 256 bit key?

I think for xts cryptsetup doubles the value internally or do not set it:

$ cryptsetup --help
....
default compiled-in device cipher parameters:
	loop-AES: aes, Key 256 bits
	plain: aes-xts-plain64, Key: 256 bits, Password hashing: sha256
	LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
	LUKS: Default keysize with XTS mode (two internal keys) will be doubled.

You can check what has been used with `cryptsetup luksDump`.

2. Are bkdf-memory and pbkdf-parallel important only when drive is opened and closed or for file operations too?

Not used on an open device.

3. I read that sha256 has is more than enough currently, but I wasn't able to understand why. Could anyone please try to explain why to use sha256 and not sha512 or sha3-512?

Beyond compatibility and that you still have to match hash size to key size you would need to ask the author.

Last edited by loqs (2024-05-10 18:59:08)

860lacov

Member

Registered: 2020-05-02

Posts: 497

Re: [SOLVED] Need a little help with cryptsetup understanding

1. Does that mean that default key size is going to be 128 bit? I suppose it is more than enough for me, but in benchmark I get the best result for 256bit. So do I have to set -s 512 if I want 256 bit key?

I think for xts cryptsetup doubles the value internally or do not set it:

$ cryptsetup --help
....
default compiled-in device cipher parameters:
	loop-AES: aes, Key 256 bits
	plain: aes-xts-plain64, Key: 256 bits, Password hashing: sha256
	LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
	LUKS: Default keysize with XTS mode (two internal keys) will be doubled.

You can check what has been used with `cryptsetup luksDump`.

2. Are bkdf-memory and pbkdf-parallel important only when drive is opened and closed or for file operations too?

Not used on an open device.

3. I read that sha256 has is more than enough currently, but I wasn't able to understand why. Could anyone please try to explain why to use sha256 and not sha512 or sha3-512?

Beyond compatibility and that you still have to match hash size to key size you would need to ask the author.

Thank you.
One more thing.
With defaults
cryptsetup luksFormat device I get:

Keyslots:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2id
        Time cost:  8
        Memory:     1048576
        Threads:    4
        Salt:       07 da d8 4f f9 28 4d 8f 4e 0f d1 b8 89 92 9a 8c 
                    d1 2a 62 ce df 6d 51 84 c3 7d d9 9d 3f 94 aa b1 
        AF stripes: 4000
        AF hash:    sha256
        Area offset:32768 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0

Wiki says:

# cryptsetup luksFormat device

As of cryptsetup 2.4.0, this is equivalent to:

# cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase luksFormat device

But with
cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase luksFormat device
I get:

Keyslots:
  0: luks2
        Key:        256 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 256 bits
        PBKDF:      argon2id
        Time cost:  9
        Memory:     1048576
        Threads:    4
        Salt:       69 c9 ef 6e ea 4d ab 86 7a 7e 7f a4 52 9c eb 76 
                    e5 10 2c 49 22 b2 fa 1f 31 7e a8 c6 5a aa a7 cd 
        AF stripes: 4000
        AF hash:    sha256
        Area offset:32768 [bytes]
        Area length:131072 [bytes]
        Digest ID:  0

Is there a mistake on Arch wiki?

loqs

Member

Registered: 2014-03-06

Posts: 18,913

Re: [SOLVED] Need a little help with cryptsetup understanding

I agree the stated defaults on the wiki do not produce the same result as using the compiled in defaults.

frostschutz

Member

Registered: 2013-11-15

Posts: 1,647

Re: [SOLVED] Need a little help with cryptsetup understanding

cryptsetup --help shows the defaults. Always check them or verify with cryptsetup luksDump.

cryptsetup benchmark already shows the correct key size (benchmark results for aes-xts 256, aes-xts 512). Yes AES sees only 128 / 256 bits (because XTS uses the other half). That's just how it works.

pbkdf and hash have no influence on the device once it's open.

The hash is used iteratively (for pbkdf2 and master key digests), the input is random data / salt, so a lot of concerns that apply to hashing files do not apply here. You can use sha3 if you like, it won't make a difference in practice. Just don't use a dumb hash... it still has to be cryptographically secure.

cryptsetup supports several different crypto backends, not all of them might support sha3 yet (I never tested it), so it's possible that some systems will fail to open such a LUKS header.

PS: for some things also there aren't reliable defaults. e.g. the sector size, cryptsetup picks 4096 or 512 depending on what the device reports (or 4096 if its a container file). I'm not sure if it uses 512bit key because --help states "Default keysize with XTS mode (two internal keys) will be doubled."... that's a confusing way to print this info, for sure.

Last edited by frostschutz (2024-05-10 20:39:36)

860lacov

Member

Registered: 2020-05-02

Posts: 497

Re: [SOLVED] Need a little help with cryptsetup understanding

cryptsetup --help shows the defaults. Always check them or verify with cryptsetup luksDump.

cryptsetup benchmark already shows the correct key size (benchmark results for aes-xts 256, aes-xts 512). Yes AES sees only 128 / 256 bits (because XTS uses the other half). That's just how it works.

pbkdf and hash have no influence on the device once it's open.

The hash is used iteratively (for pbkdf2 and master key digests), the input is random data / salt, so a lot of concerns that apply to hashing files do not apply here. You can use sha3 if you like, it won't make a difference in practice. Just don't use a dumb hash... it still has to be cryptographically secure.

cryptsetup supports several different crypto backends, not all of them might support sha3 yet (I never tested it), so it's possible that some systems will fail to open such a LUKS header.

PS: for some things also there aren't reliable defaults. e.g. the sector size, cryptsetup picks 4096 or 512 depending on what the device reports (or 4096 if its a container file). I'm not sure if it uses 512bit key because --help states "Default keysize with XTS mode (two internal keys) will be doubled."... that's a confusing way to print this info, for sure.

benchmark gives me:

cryptsetup benchmark                
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      3366215 iterations per second for 256-bit key
PBKDF2-sha256    6123071 iterations per second for 256-bit key
PBKDF2-sha512    2592276 iterations per second for 256-bit key
PBKDF2-ripemd160 1236528 iterations per second for 256-bit key
PBKDF2-whirlpool  929588 iterations per second for 256-bit key
argon2i       9 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      9 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1535.6 MiB/s      4501.1 MiB/s
    serpent-cbc        128b       153.7 MiB/s      1043.7 MiB/s
    twofish-cbc        128b       301.8 MiB/s       627.1 MiB/s
        aes-cbc        256b      1164.4 MiB/s      4170.6 MiB/s
    serpent-cbc        256b       153.5 MiB/s      1039.4 MiB/s
    twofish-cbc        256b       301.7 MiB/s       626.3 MiB/s
        aes-xts        256b      4195.6 MiB/s      4185.5 MiB/s
    serpent-xts        256b       931.4 MiB/s       922.4 MiB/s
    twofish-xts        256b       572.9 MiB/s       579.2 MiB/s
        aes-xts        512b      3864.3 MiB/s      3816.0 MiB/s
    serpent-xts        512b       928.1 MiB/s       919.2 MiB/s
    twofish-xts        512b       571.4 MiB/s       577.4 MiB/s
cryptsetup benchmark  29.51s user 23.22s system 147% cpu 35.735 totale]

So if I want fastest and very secure option I could go with:

cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 3000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase --pbkdf-memory=4194304 --pbkdf-parallel=4 luksFormat device

Is that correct?

frostschutz

Member

Registered: 2013-11-15

Posts: 1,647

Re: [SOLVED] Need a little help with cryptsetup understanding

You could...

It's more important to pick a strong passphrase, than hoping to achieve anything by giving argon2id gigabytes of ram... this will serve more as a memtest than actually improve security in any way.

You won't be able to open it at all on a system with low ram. Even on a system with lots of ram you might run into OOM if you're trying to open multiple such containers in parallel (cryptsetup open has --serialize-memory-hard-pbkdf to deal with that).

If in doubt, stick to defaults.