How to access volumes encrypted with LUKS/dm-crypt from Windows

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.

There are many, many documents and man pages to read through, but one document that might particularly interest you is the LUKS On-Disk Format Specification (PDF).

Appendix B (which is, naturally, near the end) says,

Cipher and Hash specification registry

Even if the cipher-name and cipher-mode strings are not interpreted by any LUKS operation, they must have the same meaning for all implementations to achieve compatibility among different LUKS-based implementations. LUKS has to ensure that the underlaying cipher system can utilise the cipher name and cipher mode strings, and as these strings might not always be native to the cipher system, LUKS might need to map them into something appropriate.

Valid cipher names are listed in Table 1.

Valid cipher modes are listed in Table 2. By contract, cipher modes using IVs and tweaks must start from the all-zero IV / tweak. This applies for all calls to the encrypt / decrypt primitives especially when handling key material. Further, these IVs / tweaks cipher modes usually cut the cipher stream into independent blocks by reseeding tweaks / IVs at sector boundaries. The all-zero IV / tweak requirement for the first encrypted / decrypted block is equivalent to the requirement that the first block is defined to rest at sector 0.

Table 3 lists valid hash specs for hash-spec field. A compliant implementation does not have to support all cipher, cipher mode or hash specifications.

Table 1: Valid cipher names

• aes - Advanced Encryption Standard - FIPS PUB 197
• twofish - Twofish: A 128-Bit Block Cipher - http://www.schneier.com/paper-twofish-paper.html    (See below)
• serpent - http://www.cl.cam.ac.uk/~rja14/serpent.html
• cast5 - RFC 2144
• cast6 - RFC 2612

Table 2: Valid cipher modes

• ecb - The cipher output is used directly
• cbc-plain - The cipher is operated in CBC mode. The CBC chaining is cut every sector, and reinitialised with the sector number as initial vector (converted to 32-bit and to little-endian). This mode is specified in [Fru05b], Chapter 4.
• cbc-essiv:hash - The cipher is operated in ESSIV mode using hash for generating the IV key for the original key. For instance, when using sha256 as hash, the cipher mode spec is “cbcessiv:sha256”. ESSIV is specified in [Fru05b], Chapter 4.
• xts-plain64 - http://grouper.ieee.org/groups/1619/email/pdf00086.pdf, plain64 is 64-bit version of plain initial vector

Table 3: Valid hash specifications

• sha1 - RFC 3174 - US Secure Hash Algorithm 1 (SHA1)
• sha256 - SHA variant according to FIPS 180-2
• sha512 - SHA variant according to FIPS 180-2
• ripemd160 - http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html   (See below)

Editor’s Note: The above is copied from the specification.  Subsequent to its writing, these documents’ URLs have changed:

• Twofish: A 128-Bit Block Cipher   (new URL)
• The hash function RIPEMD-160   (new URL)