+ overwrite with zeros. For an SSD or FLASH drive (USB stick), you
+ may want to overwrite the complete SSD several times and use
+ physical destruction in addition, see last item. For re-writable
+ CD/DVD, a single overwrite should also be enough, due to the
+ anti-forensic properties of the LUKS keyslots. For write-once
+ media, use physical destruction. For low security requirements,
+ just cut the CD/DVD into several parts. For high security needs,
+ shred or burn the medium. If your backup is on magnetic tape, I
+ advise physical destruction by shredding or burning, after
+ overwriting . The problem with magnetic tape is that it has a
+ higher dynamic range than HDDs and older data may well be
+ recoverable after overwrites. Also write-head alignment issues can
+ lead to data not actually being deleted at all during overwrites.
+
+
+ * 5.6 What about backup? Does it compromise security?
+
+ That depends. See item 6.7.
+
+
+ * 5.7 Why is all my data permanently gone if I overwrite the LUKS
+ header?
+
+ Overwriting the LUKS header in part or in full is the most common
+ reason why access to LUKS containers is lost permanently.
+ Overwriting can be done in a number of fashions, like creating a
+ new filesystem on the raw LUKS partition, making the raw partition
+ part of a raid array and just writing to the raw partition.
+
+ The LUKS header contains a 256 bit "salt" value and without that no
+ decryption is possible. While the salt is not secret, it is
+ key-grade material and cannot be reconstructed. This is a
+ cryptographically strong "cannot". From observations on the
+ cryptsetup mailing-list, people typically go though the usual
+ stages of grief (Denial, Anger, Bargaining, Depression, Acceptance)
+ when this happens to them. Observed times vary between 1 day and 2
+ weeks to complete the cycle. Seeking help on the mailing-list is
+ fine. Even if we usually cannot help with getting back your data,
+ most people found the feedback comforting.
+
+ If your header does not contain an intact salt, best go directly
+ to the last stage ("Acceptance") and think about what to do now.
+ There is one exception that I know of: If your LUKS container is
+ still open, then it may be possible to extract the master key from
+ the running system. See Item "How do I recover the master key from
+ a mapped LUKS container?" in Section "Backup and Data Recovery".
+
+
+ * 5.8 What is a "salt"?
+
+ A salt is a random key-grade value added to the passphrase before
+ it is processed. It is not kept secret. The reason for using salts
+ is as follows: If an attacker wants to crack the password for a
+ single LUKS container, then every possible passphrase has to be
+ tried. Typically an attacker will not try every binary value, but
+ will try words and sentences from a dictionary.
+
+ If an attacker wants to attack several LUKS containers with the
+ same dictionary, then a different approach makes sense: Compute the
+ resulting slot-key for each dictionary element and store it on
+ disk. Then the test for each entry is just the slow unlocking with
+ the slot key (say 0.00001 sec) instead of calculating the slot-key
+ first (1 sec). For a single attack, this does not help. But if you
+ have more than one container to attack, this helps tremendously,
+ also because you can prepare your table before you even have the
+ container to attack! The calculation is also very simple to
+ parallelize. You could, for example, use the night-time unused CPU
+ power of your desktop PCs for this.
+
+ This is where the salt comes in. If the salt is combined with the
+ passphrase (in the simplest form, just appended to it), you
+ suddenly need a separate table for each salt value. With a
+ reasonably-sized salt value (256 bit, e.g.) this is quite
+ infeasible.
+
+
+ * 5.9 Is LUKS secure with a low-entropy (bad) passphrase?
+
+ Note: You should only use the 94 printable characters from 7 bit
+ ASCII code to prevent your passphrase from failing when the
+ character encoding changes, e.g. because of a system upgrade, see
+ also the note at the very start of this FAQ under "WARNINGS".
+
+ This needs a bit of theory. The quality of your passphrase is
+ directly related to its entropy (information theoretic, not
+ thermodynamic). The entropy says how many bits of "uncertainty" or
+ "randomness" are in you passphrase. In other words, that is how
+ difficult guessing the passphrase is.
+
+ Example: A random English sentence has about 1 bit of entropy per
+ character. A random lowercase (or uppercase) character has about
+ 4.7 bit of entropy.
+
+ Now, if n is the number of bits of entropy in your passphrase and t
+ is the time it takes to process a passphrase in order to open the
+ LUKS container, then an attacker has to spend at maximum
+
+ attack_time_max = 2^n * t
+
+ time for a successful attack and on average half that. There is no
+ way getting around that relationship. However, there is one thing
+ that does help, namely increasing t, the time it takes to use a
+ passphrase, see next FAQ item.
+
+ Still, if you want good security, a high-entropy passphrase is the
+ only option. For example, a low-entropy passphrase can never be
+ considered secure against a TLA-level (Three Letter Agency level,
+ i.e. government-level) attacker, no matter what tricks are used in
+ the key-derivation function. Use at least 64 bits for secret stuff.
+ That is 64 characters of English text (but only if randomly chosen)
+ or a combination of 12 truly random letters and digits.
+
+ For passphrase generation, do not use lines from very well-known
+ texts (religious texts, Harry potter, etc.) as they are to easy to
+ guess. For example, the total Harry Potter has about 1'500'000
+ words (my estimation). Trying every 64 character sequence starting
+ and ending at a word boundary would take only something like 20
+ days on a single CPU and is entirely feasible. To put that into
+ perspective, using a number of Amazon EC2 High-CPU Extra Large
+ instances (each gives about 8 real cores), this test costs
+ currently about 50USD/EUR, but can be made to run arbitrarily fast.
+
+ On the other hand, choosing 1.5 lines from, say, the Wheel of Time
+ is in itself not more secure, but the book selection adds quite a
+ bit of entropy. (Now that I have mentioned it here, don't use tWoT
+ either!) If you add 2 or 3 typos or switch some words around, then
+ this is good passphrase material.
+
+
+ * 5.10 What is "iteration count" and why is decreasing it a bad idea?
+
+ Iteration count is the number of PBKDF2 iterations a passphrase is
+ put through before it is used to unlock a key-slot. Iterations are
+ done with the explicit purpose to increase the time that it takes
+ to unlock a key-slot. This provides some protection against use of
+ low-entropy passphrases.
+
+ The idea is that an attacker has to try all possible passphrases.
+ Even if the attacker knows the passphrase is low-entropy (see last
+ item), it is possible to make each individual try take longer. The
+ way to do this is to repeatedly hash the passphrase for a certain
+ time. The attacker then has to spend the same time (given the same
+ computing power) as the user per try. With LUKS, the default is 1
+ second of PBKDF2 hashing.
+
+ Example 1: Lets assume we have a really bad passphrase (e.g. a
+ girlfriends name) with 10 bits of entropy. With the same CPU, an
+ attacker would need to spend around 500 seconds on average to
+ break that passphrase. Without iteration, it would be more like
+ 0.0001 seconds on a modern CPU.
+
+ Example 2: The user did a bit better and has 32 chars of English
+ text. That would be about 32 bits of entropy. With 1 second
+ iteration, that means an attacker on the same CPU needs around 136
+ years. That is pretty impressive for such a weak passphrase.
+ Without the iterations, it would be more like 50 days on a modern
+ CPU, and possibly far less.
+
+ In addition, the attacker can both parallelize and use special
+ hardware like GPUs or FPGAs to speed up the attack. The attack can
+ also happen quite some time after the luksFormat operation and CPUs
+ can have become faster and cheaper. For that reason you want a
+ bit of extra security. Anyways, in Example 1 your are screwed.
+ In example 2, not necessarily. Even if the attack is faster, it
+ still has a certain cost associated with it, say 10000 EUR/USD
+ with iteration and 1 EUR/USD without iteration. The first can be
+ prohibitively expensive, while the second is something you try
+ even without solid proof that the decryption will yield something
+ useful.
+
+ The numbers above are mostly made up, but show the idea. Of course
+ the best thing is to have a high-entropy passphrase.
+
+ Would a 100 sec iteration time be even better? Yes and no.
+ Cryptographically it would be a lot better, namely 100 times better.
+ However, usability is a very important factor for security
+ technology and one that gets overlooked surprisingly often. For
+ LUKS, if you have to wait 2 minutes to unlock the LUKS container,
+ most people will not bother and use less secure storage instead. It
+ is better to have less protection against low-entropy passphrases
+ and people actually use LUKS, than having them do without
+ encryption altogether.
+
+ Now, what about decreasing the iteration time? This is generally a
+ very bad idea, unless you know and can enforce that the users only
+ use high-entropy passphrases. If you decrease the iteration time
+ without ensuring that, then you put your users at increased risk,
+ and considering how rarely LUKS containers are unlocked in a
+ typical work-flow, you do so without a good reason. Don't do it.
+ The iteration time is already low enough that users with entropy
+ low passphrases are vulnerable. Lowering it even further increases
+ this danger significantly.
+
+
+ * 5.11 Some people say PBKDF2 is insecure?
+
+ There is some discussion that a hash-function should have a "large
+ memory" property, i.e. that it should require a lot of memory to be
+ computed. This serves to prevent attacks using special programmable
+ circuits, like FPGAs, and attacks using graphics cards. PBKDF2
+ does not need a lot of memory and is vulnerable to these attacks.
+ However, the publication usually referred in these discussions is
+ not very convincing in proving that the presented hash really is
+ "large memory" (that may change, email the FAQ maintainer when it
+ does) and it is of limited usefulness anyways. Attackers that use
+ clusters of normal PCs will not be affected at all by a "large
+ memory" property. For example the US Secret Service is known to
+ use the off-hour time of all the office PCs of the Treasury for
+ password breaking. The Treasury has about 110'000 employees.
+ Assuming every one has an office PC, that is significant computing
+ power, all of it with plenty of memory for computing "large
+ memory" hashes. Bot-net operators also have all the memory they
+ want. The only protection against a resourceful attacker is a
+ high-entropy passphrase, see items 5.9 and 5.10.
+
+
+ * 5.12 What about iteration count with plain dm-crypt?
+
+ Simple: There is none. There is also no salting. If you use plain
+ dm-crypt, the only way to be secure is to use a high entropy
+ passphrase. If in doubt, use LUKS instead.
+
+
+ * 5.13 Is LUKS with default parameters less secure on a slow CPU?
+
+ Unfortunately, yes. However the only aspect affected is the
+ protection for low-entropy passphrase or master-key. All other
+ security aspects are independent of CPU speed.
+
+ The master key is less critical, as you really have to work at it
+ to give it low entropy. One possibility is to supply the master key
+ yourself. If that key is low-entropy, then you get what you
+ deserve. The other known possibility is to use /dev/urandom for
+ key generation in an entropy-starved situation (e.g. automatic
+ installation on an embedded device without network and other entropy
+ sources).
+
+ For the passphrase, don't use a low-entropy passphrase. If your
+ passphrase is good, then a slow CPU will not matter. If you insist
+ on a low-entropy passphrase on a slow CPU, use something like
+ "--iter-time=10" or higher and wait a long time on each LUKS unlock
+ and pray that the attacker does not find out in which way exactly
+ your passphrase is low entropy. This also applies to low-entropy
+ passphrases on fast CPUs. Technology can do only so much to
+ compensate for problems in front of the keyboard.
+
+
+ * 5.14 Why was the default aes-cbc-plain replaced with aes-cbc-essiv?
+
+ Note: This item applies both to plain dm-crypt and to LUKS