1

When i use only a passphrase in luks for my whole system partition encryption, so i need to insert a password to decrypt my system partition to boot up my os, is this unsecure and can it be cracked with bruteforce if someone stole the laptop?

What is the best way to do this, with a keyfile and store the keyfile to an usb stick, do i have to consider something about the length?

Can i load this keyfile with grub from my usb stick and how?

UPDATE | If there are to much questions, i can splitt them!

I read now that i need to store a header file to.

So i need to store 2 files now?

Can i restore a password from this header file or decrypt the partition only with this header file?

Blockchain Office
  • 149
  • 1
  • 11

2 Answers2

1

The luks header and keyslot area is placed at and near the front of the partition. (I believe when you talk about the "header" you're referring to a backup of the header, which you should seriously consider doing after you create the volume - read about cryptsetup luksHeaderBackup.)

This answer gives a good overview as well as details about the LUKS header arif '19.

Without a key file the ability to decrypt partition rests on the complexity of the password. As long as the password in use is randomised with high degree of uncertainty (aka high-entropy) the ability for another to decrypt the secret key is greatly limited.

You don't need a key file, but it will add security to your setup if you store a copy of the partition in some other location, and meanwhile keep your keyfile (and its backups) separate. If you do use a keyfile it should be made up of (at least) 16 random bytes (32 is better).

I talk about password strength in much more detail in this answer: https://security.stackexchange.com/a/248326/. Meanwhile, in this answer I discuss the cryptsetup options for increasing the hardness of your password-based kdf (key derivation function) https://security.stackexchange.com/a/245146/.

At the time of writing, booting requires a luks1 partition (luks2 isn't an option at this stage), and for some reason (?) the boot-time kdf is a lot slower. Something to note is that when using LUKS1 and GRUB, the time it takes PBKDF2 to run is much slower, for eg. I find that I can only tolerate a cryptsetup --type luks1 --pbkdf pbkdf2 --pbkdf-force-iterations 250000 when unlocking using GRUB, yet this is almost too quick for weaker passwords.

brynk
  • 1,016
  • 4
  • 14
1

The security of your filesystem mostly depends on two main things: the algorithms that you are using for encryption and key derivation, and the implementation of those algorithms.

The algorithms that dm-crypt supports are well known, audited, and have been around for a while, so we consider them cryptographically secure because the only known way to attack them is through a brute-force attack, to perform a brute-force attack on a algorithm that has 256bit key (like AES-256), there are 2^256 possibilities that the attacker needs to guess, which is a really huge number and probably nobody has enough resources to do so.

But the attacker doesn't have to guess the key itself, attacker only needs to guess the passphrase that your key derived from, and passwords/passphrases have less amount of entropy, and they are usually short, so it will be easier for the attacker to guess the passphrase/password because it's less expensive and requires less resources, but that is not something you can't fix, you can configure your KDF(Key Derivation Function) to require more resources to derive the key, so the attacker will have to use more resources to guess the passphrase/password, or you can choose a better passphrase/password.

Note: making the key derivation process more expensive will make it more expensive for you as well, and you will have to wait a few more seconds to derive the key.

Note: you can use memory-hard KDFs like argon2 or scrypt to make it more expensive for the attacker.

And archlinux wiki has a good guide on setting up keyfile on a external media: https://wiki.archlinux.org/title/Dm-crypt/Device_encryption#With_a_keyfile_stored_on_an_external_media

Zola Gonano
  • 36
  • 4