How is LUKS dm-crypt secure if the key is stored with the encrypted data?

I'm not a an expert in cryptography, but I've read the project's faqs.

How is LUKS dm-crypt secure if the key is stored with the encrypted data? To me, this seems like hanging a door key on the door it locks. Is a passphrase enough to secure it?

And a continuation: If it is secure to keep the key with the encrypted partition/container, am I correct in assuming that LUKS header backups can also be treated as normal files and not secret data?

Solution 1:

How is LUKS dm-crypt secure if the key is stored with the encrypted data? [...] Is a passphrase enough to secure it?

Yes, it is, if you choose a sufficiently strong passphrase. Ideally, the passphrase should be as strong as the (symmetric) key. Current minimum recommendation is to use 128 bit, so ideally you should use a 128-bit passphrase. How long that is in practice depends on how you generate your key.

• If you use a random list of lowercase letters, uppercase letters (a-z) and numbers, each character will give you about log2(62)=~5.95 bits of entropy, so you'd need 22 characters, for example: asl3486nysdllk23bh2jl4 . Secure, but rather difficult to remember...
• If you use a list of random words, it depends on the word lists' size. For example, if you use the american-english file from Debian's wamerican package: The file has about 99,000 words, so each word gives you log2(99,000)=16.6 bits of entropy, meaning you'd need eight words. For example: orthogonal Seoul Pygmalion's abuse flints yachtsman's classicists outsource. Still not nice, but probably better than the solution above...

If you choose a shorter passphrase, then yes, security will be reduced (though it might still be acceptable). Note that LUKS employs a key stretching algorithm to make even a "weak" key more resistant against attack. However, there are some attacks against it, so ideally you should still choose a 128-bit passphrase.

If it is secure to keep the key with the encrypted partition/container, am I correct in assuming that LUKS header backups can also be treated as normal files and not secret data?

Yes, that is correct. The header backups contain the key, but it is protected with the passphrase.