6. Backup and Data Recovery
7. Interoperability with other Disk Encryption Tools
8. Issues with Specific Versions of cryptsetup
+9. References and Further Reading
A. Contributors
SSDs/FLASH DRIVES: SSDs and Flash are different. Currently it is
unclear how to get LUKS or plain dm-crypt to run on them with the
full set of security features intact. This may or may not be a
- problem, depending on the attacher model. See Section 5.17.
+ problem, depending on the attacher model. See Section 5.19.
BACKUP: Yes, encrypted disks die, just as normal ones do. A full
backup is mandatory, see Section "6. Backup and Data Recovery" on
PASSPHRASE CHARACTER SET: Some people have had difficulties with
this when upgrading distributions. It is highly advisable to only
- use the 94 printable characters from the first 128 characters of
+ use the 95 printable characters from the first 128 characters of
the ASCII table, as they will always have the same binary
representation. Other characters may have different encoding
depending on system configuration and your passphrase will not
http://dir.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt
+ * 1.7 Unsubscribe from the mailing-list
+
+ Send mail to dm-crypt-unsubscribe@saout.de from the subscribed
+ account. You will get an email with instructions.
+
+ Basically, you just have to respond to it unmodified to get
+ unsubscribed. The listserver admin functions are not very fast. It
+ can take 15 minutes or longer for a reply to arrive (I suspect
+ greylisting is in use), so be patient.
+
+ Also note that nobody on the list can unsubscribe you, sending
+ demands to be unsubscribed to the list just annoys people that are
+ entirely blameless for you being subscribed.
+
+ If you are subscribed, a subscription confirmation email was sent
+ to your email account and it had to be answered before the
+ subscription went active. The confirmation emails from the
+ listserver have subjects like these (with other numbers):
+
+ Subject: confirm 9964cf10.....
+
+ and are sent from dm-crypt-request@saout.de. You should check
+ whether you have anything like it in your sent email folder. If
+ you find nothing and are sure you did not confirm, then you should
+ look into a possible compromise of your email account.
+
+
2. Setup
- * 2.1 What is the difference between "plain" and LUKS format?
+ * 2.1 LUKS Container Setup mini-HOWTO
+
+ This item tries to give you a very brief list of all the steps you
+ should go though when creating a new LUKS encrypted container, i.e.
+ encrypted disk, partition or loop-file.
+
+ 01) All data will be lost, if there is data on the target, make a
+ backup.
+
+ 02) Make very sure you have the right target disk, partition or
+ loop-file.
+
+ 03) If the target was in use previously, it is a good idea to
+ wipe it before creating the LUKS container in order to remove any
+ trace of old file systems and data. For example, some users have
+ managed to run e2fsck on a partition containing a LUKS container,
+ possibly because of residual ext2 superblocks from an earlier use.
+ This can do arbitrary damage up to complete and permanent loss of
+ all data in the LUKS container.
+
+ To just quickly wipe file systems (old data may remain), use
+
+ wipefs -a <target device>
+
+ To wipe file system and data, use something like
+
+ cat /dev/zero > <target device>
+
+ This can take a while. To get a progress indicator, you can use
+ the tool dd_rescue (->google) instead or use my stream meter "wcs"
+ (source here: http://www.tansi.org/tools/index.html) in the
+ following fashion:
+
+ cat /dev/zero | wcs > <target device>
+
+ Be very sure you have the right target, all data will be lost!
+
+ Note that automatic wiping is on the TODO list for cryptsetup, so
+ at some time in the future this will become unnecessary.
+
+ 04) Create the LUKS container:
+ cryptsetup luksFormat <target device>
+
+ Just follow the on-screen instructions.
+
+ 05) Map the container. Here it will be mapped to /dev/mapper/c1:
+ cryptsetup luksOpen <target device> c1
+
+ 06) (Optionally) wipe the container (make sure you have the right target!):
+ cat /dev/zero > /dev/mapper/c1
+
+ Note that this creates a small information leak, as an attacker can
+ determine whether a 512 byte block is zero if the attacker has
+ access to the encrypted container multiple times. Typically a
+ competent attacker that has access multiple times can install a
+ passphrase sniffer anyways, so this leakage is not very
+ significant. For getting a progress indicator, see step 03.
+
+ Note that at some time in the future, cryptsetup will do this for
+ you, but currently it is a TODO list item.
+
+ 07) Create a file system in the mapped container, for example an
+ ext3 file system (any other file system is possible):
+
+ mke2fs -j /dev/mapper/c1
+
+ 08) Mount your encrypted file system, here on /mnt:
+ mount /dev/mapper/c1 /mnt
+
+ Done. You can now use the encrypted file system to store data. Be
+ sure to read though the rest of the FAQ, these are just the very
+ basics. In particular, there are a number of mistakes that are
+ easy to make, but will compromise your security.
+
+
+ * 2.2 What is the difference between "plain" and LUKS format?
First, unless you happen to understand the cryptographic background
well, you should use LUKS. It does protect the user from a lot of
non-default XTS mode).
- * 2.2 Can I encrypt an already existing, non-empty partition to use
+ * 2.3 Can I encrypt an already existing, non-empty partition to use
LUKS?
There is no converter, and it is not really needed. The way to do
to be in a filesystem.
- * 2.3 How do I use LUKS with a loop-device?
+ * 2.4 How do I use LUKS with a loop-device?
This can be very handy for experiments. Setup is just the same as
with any block device. If you want, for example, to use a 100MiB
To unmap the file when done, use "losetup -d /dev/loop0".
- * 2.4 When I add a new key-slot to LUKS, it asks for a passphrase but
+ * 2.5 When I add a new key-slot to LUKS, it asks for a passphrase but
then complains about there not being a key-slot with that
passphrase?
new key-slot.
- * 2.5 Encryption on top of RAID or the other way round?
+ * 2.6 Encryption on top of RAID or the other way round?
Unless you have special needs, place encryption between RAID and
filesystem, i.e. encryption on top of RAID. You can do it the other
device, e.g. /dev/dm0 .
- * 2.6 How do I read a dm-crypt key from file?
+ * 2.7 How do I read a dm-crypt key from file?
Note that the file will still be hashed first, just like keyboard
input. Use the --key-file option, like this:
cryptsetup create --key-file keyfile e1 /dev/loop0
- * 2.7 How do I read a LUKS slot key from file?
+ * 2.8 How do I read a LUKS slot key from file?
What you really do here is to read a passphrase from file, just as
you would with manual entry of a passphrase for a key-slot. You can
cryptsetup luksOpen --key-file keyfile /dev/loop0 e1
- * 2.8 How do I read the LUKS master key from file?
+ * 2.9 How do I read the LUKS master key from file?
The question you should ask yourself first is why you would want to
do this. The only legitimate reason I can think of is if you want
do this here.
- * 2.9 What are the security requirements for a key read from file?
+ * 2.10 What are the security requirements for a key read from file?
A file-stored key or passphrase has the same security requirements
as one entered interactively, however you can use random bytes and
head -c 256 /dev/random > keyfile
- * 2.10 If I map a journaled file system using dm-crypt/LUKS, does it
+ * 2.11 If I map a journaled file system using dm-crypt/LUKS, does it
still provide its usual transactional guarantees?
Yes, it does, unless a very old kernel is used. The required flags
should improve further and eventually the problem should go away.
- * 2.11 Can I use LUKS or cryptsetup with a more secure (external)
+ * 2.12 Can I use LUKS or cryptsetup with a more secure (external)
medium for key storage, e.g. TPM or a smartcard?
Yes, see the answers on using a file-supplied key. You do have to
storage.
- * 2.12 Can I resize a dm-crypt or LUKS partition?
+ * 2.13 Can I resize a dm-crypt or LUKS partition?
Yes, you can, as neither dm-crypt nor LUKS stores partition size.
Whether you should is a different question. Personally I recommend
for that.
+ * 2.14 How do I Benchmark the Ciphers, Hashes and Modes?
+
+ Since version 1.60 cryptsetup supports the "benchmark" command.
+ Simply run as root:
+
+ cryptsetup benchmark
+
+ It will output first iterations/second for the key-derivation
+ function PBKDF2 parameterized with different hash-functions, and
+ then the raw encryption speed of ciphers with different modes and
+ key-sizes. You can get more than the default benchmarks, see the
+ man-page for the relevant parameters. Note that XTS mode takes two
+ keys, hence the listed key sizes are double that for other modes
+ and half of it is the cipher key, the other half is the XTS key.
+
+
3. Common Problems
5. Security Aspects
- * 5.1 Is LUKS insecure? Everybody can see I have encrypted data!
+ * 5.1 How long is a secure passphrase ?
+
+ This is just the short answer. For more info and explanation of
+ some of the terms used in this item, read the rest of Section 5.
+ The actual recommendation is at the end of this item.
+
+ First, passphrase length is not really the right measure,
+ passphrase entropy is. For example, a random lowercase letter (a-z)
+ gives you 4.7 bit of entropy, one element of a-z0-9 gives you 5.2
+ bits of entropy, an element of a-zA-Z0-9 gives you 5.9 bits and
+ a-zA-Z0-9!@#$%^&:-+ gives you 6.2 bits. On the other hand, a random
+ English word only gives you 0.6...1.3 bits of entropy per
+ character. Using sentences that make sense gives lower entropy,
+ series of random words gives higher entropy. Do not use sentences
+ that can be tied to you or found on your computer. This type of
+ attack is done routinely today.
+
+ That said, it does not matter too much what scheme you use, but it
+ does matter how much entropy your passphrase contains, because an
+ attacker has to try on average
+
+ 1/2 * 2^(bits of entropy in passphrase)
+
+ different passphrases to guess correctly.
+
+ Historically, estimations tended to use computing time estimates,
+ but more modern approaches try to estimate cost of guessing a
+ passphrase.
+
+ As an example, I will try to get an estimate from the numbers in
+ http://it.slashdot.org/story/12/12/05/0623215/new-25-gpu-monster-devours-strong-passwords-in-minutes
+ More references can be found a the end of this document. Note that
+ these are estimates from the defender side, so assuming something
+ is easier than it actually is is fine. An attacker may still have
+ vastly higher cost than estimated here.
+
+ LUKS uses SHA1 for hasing per default. The claim in the reference is
+ 63 billion tries/second for SHA1. We will leave aside the check
+ whether a try actually decrypts a key-slot. Now, the machine has 25
+ GPUs, which I will estimate at an overall lifetime cost of USD/EUR
+ 1000 each, and an useful lifetime of 2 years. (This is on the low
+ side.) Disregarding downtime, the machine can then break
+
+ N = 63*10^9 * 3600 * 24 * 365 * 2 ~ 4*10^18
+
+ passphrases for EUR/USD 25k. That is one 62 bit passphrase hashed
+ once with SHA1 for EUR/USD 25k. Note that as this can be
+ parallelized, it can be done faster than 2 years with several of
+ these machines.
+
+ For plain dm-crypt (no hash iteration) this is it. This gives (with
+ SHA1, plain dm-crypt default is ripemd160 which seems to be
+ slightly slower than SHA1):
+
+ Passphrase entropy Cost to break
+ 60 bit EUR/USD 6k
+ 65 bit EUR/USD 200K
+ 70 bit EUR/USD 6M
+ 75 bit EUR/USD 200M
+ 80 bit EUR/USD 6B
+ 85 bit EUR/USD 200B
+ ... ...
+
+ For LUKS, you have to take into account hash iteration in PBKDF2.
+ For a current CPU, there are about 100k iterations (as can be
+ queried with ''cryptsetup luksDump''.
+
+ The table above then becomes:
+
+ Passphrase entropy Cost to break
+ 50 bit EUR/USD 600k
+ 55 bit EUR/USD 20M
+ 60 bit EUR/USD 600M
+ 65 bit EUR/USD 20B
+ 70 bit EUR/USD 600B
+ 75 bit EUR/USD 20T
+ ... ...
+
+ Recommendation:
+
+ To get reasonable security for the next 10 years, it is a good idea
+ to overestimate by a factor of at least 1000.
+
+ Then there is the question of how much the attacker is willing to
+ spend. That is up to your own security evaluation. For general use,
+ I will assume the attacker is willing to spend up to 1 million
+ EUR/USD. Then we get the following recommendations:
+
+ Plain dm-crypt: Use > 80 bit. That is e.g. 17 random chars from a-z
+ or a random English sentence of > 135 characters length.
+
+ LUKS: Use > 65 bit. That is e.g. 14 random chars from a-z or a
+ random English sentence of > 108 characters length.
+
+ If paranoid, add at least 20 bit. That is roughly four additional
+ characters for random passphrases and roughly 32 characters for a
+ random English sentence.
+
+
+ * 5.2 Is LUKS insecure? Everybody can see I have encrypted data!
In practice it does not really matter. In most civilized countries
you can just refuse to hand over the keys, no harm done. In some
difference between "plain" and LUKS format?"
- * 5.2 Should I initialize (overwrite) a new LUKS/dm-crypt partition?
+ * 5.3 Should I initialize (overwrite) a new LUKS/dm-crypt partition?
If you just create a filesystem on it, most of the old data will
still be there. If the old data is sensitive, you should overwrite
dd if=/dev/zero of=/dev/mapper/e1
- * 5.3 How do I securely erase a LUKS (or other) partition?
+ * 5.4 How do I securely erase a LUKS (or other) partition?
For LUKS, if you are in a desperate hurry, overwrite the LUKS
header and key-slot area. This means overwriting the first
dd_rescue -w /dev/zero /dev/sde1
- * 5.4 How do I securely erase a backup of a LUKS partition or header?
+ * 5.5 How do I securely erase a backup of a LUKS partition or header?
That depends on the medium it is stored on. For HDD and SSD, use
overwrite with zeros. For an SSD or FLASH drive (USB stick), you
lead to data not actually being deleted at all during overwrites.
- * 5.5 What about backup? Does it compromise security?
+ * 5.6 What about backup? Does it compromise security?
That depends. See item 6.7.
- * 5.6 Why is all my data permanently gone if I overwrite the LUKS
+ * 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
a mapped LUKS container?" in Section "Backup and Data Recovery".
- * 5.7 What is a "salt"?
+ * 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
infeasible.
- * 5.8 Is LUKS secure with a low-entropy (bad) passphrase?
+ * 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
this is good passphrase material.
- * 5.9 What is "iteration count" and why is decreasing it a bad idea?
+ * 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
this danger significantly.
- * 5.10 Some people say PBKDF2 is insecure?
+ * 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
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.8 and 5.9.
+ high-entropy passphrase, see items 5.9 and 5.10.
- * 5.11 What about iteration count with plain dm-crypt?
+ * 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.12 Is LUKS with default parameters less secure on a slow CPU?
+ * 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
compensate for problems in front of the keyboard.
- * 5.13 Why was the default aes-cbc-plain replaced with aes-cbc-essiv?
+ * 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
knowing the encryption key and the watermarking attack fails.
- * 5.14 Are there any problems with "plain" IV? What is "plain64"?
+ * 5.15 Are there any problems with "plain" IV? What is "plain64"?
First, "plain" and "plain64" are both not secure to use with CBC,
see previous FAQ item.
does not cause any performance penalty compared to "plain".
- * 5.15 What about XTS mode?
+ * 5.16 What about XTS mode?
XTS mode is potentially even more secure than cbc-essiv (but only if
cbc-essiv is insecure in your scenario). It is a NIST standard and
apply.
- * 5.16 Is LUKS FIPS-140-2 certified?
+ * 5.17 Is LUKS FIPS-140-2 certified?
No. But that is more a problem of FIPS-140-2 than of LUKS. From a
technical point-of-view, LUKS with the right parameters would be
entropy-starved situation.
- * 5.16 What about Plausible Deniability?
+ * 5.18 What about Plausible Deniability?
First let me attempt a definition for the case of encrypted
filesystems: Plausible deniability is when you hide encrypted data
foot, you can figure out how to do it yourself.
- * 5.17 What about SSDs or Flash Drives?
+ * 5.19 What about SSDs or Flash Drives?
The problem is that you cannot reliably erase parts of these
devices, mainly due to wear-leveling and possibly defect
- Passphrase hash algorithm needs specifying
Also note that because plain dm-crypt and loop-aes format does not
- have metadata, autodetection, while feasible in most cases, would
- be a lot of work that nobody really wants to do. If you still have
- the old set-up, using a verbosity option (-v) on mapping with the
- old tool or having a look into the system logs after setup could
- give you the information you need.
+ have metadata, and while the loopAES extension for cryptsetup tries
+ autodetection (see command loopaesOpen), it may not always work.
+ If you still have the old set-up, using a verbosity option (-v)
+ on mapping with the old tool or having a look into the system logs
+ after setup could give you the information you need. Below, there
+ are also some things that worked for somebody.
* 7.3 loop-aes patched into losetup on Debian 5.x, kernel 2.6.32
--cipher twofish-cbc-null -s 192 -h ripemd160:20
+ * 7.5 loop-aes v1 format OpenSUSE
+
+ Apparently this is done by older OpenSUSE distros and stopped
+ working from OpenSUSE 12.1 to 12.2. One user had success with the
+ following:
+
+ cryptsetup create <target> <device> -c aes -s 128 -h sha256
+
+
+ * 7.6 Kernel encrypted loop device (cryptoloop)
+
+ There are a number of different losetup implementations for using
+ encrypted loop devices so getting this to work may need a bit of
+ experimentation.
+
+ NOTE: Do NOT use this for new containers! Some of the existing
+ implementations are insecure and future support is uncertain.
+
+ Example for a compatible mapping:
+
+ losetup -e twofish -N /dev/loop0 /image.img
+
+ translates to
+
+ cryptsetup create image_plain /image.img -c twofish-cbc-plain -H plain
+
+ with the mapping being done to /dev/mapper/image_plain instead of
+ to /dev/loop0.
+
+ More details:
+
+ Cipher, mode and pasword hash (or no hash):
+
+ -e cipher [-N] => -c cipher-cbc-plain -H plain [-s 256]
+ -e cipher => -c cipher-cbc-plain -H ripemd160 [-s 256]
+
+ Key size and offsets (losetup: bytes, cryptsetuop: sectors of 512
+ bytes):
+
+ -k 128 => -s 128
+ -o 2560 => -o 5 -p 5 # 2560/512 = 5
+
+ There is no replacement for --pass-fd, it has to be emulated using
+ keyfiles, see the cryptsetup man-page.
+
+
8. Issues with Specific Versions of cryptsetup
version of cryptsetup (1.0.x) provided by SLED, which should also
not be used anymore as well. My advice would be to drop SLED 10.
+
+9. References and Further Reading
+
+
+ * Purpose of this Section
+
+ The purpose of this section is to collect references to all
+ materials that do not fit the FAQ but are relevant in some fashion.
+ This can be core topics like the LUKS spec or disk encryption, but
+ it can also be more tangential, like secure storage management or
+ cryptography used in LUKS. It should still have relevance to
+ cryptsetup and its applications.
+
+ If you wan to see something added here, send email to the
+ maintainer (or the cryptsetup mailing list) giving an URL, a
+ description (1-3 lines preferred) and a section to put it in. You
+ can also propose new sections.
+
+ At this time I would like to limit the references to things that
+ are available on the web.
+
+
+ * Specifications
+
+ - LUKS on-disk format spec:
+ http://code.google.com/p/cryptsetup/wiki/Specification
+
+
+ * Code Examples
+
+ - Some code examples are in the source package under docs/examples
+
+
+ * Brute-forcing passphrases
+
+ -
+ http://news.electricalchemy.net/2009/10/password-cracking-in-cloud-part-5.html
+
+ -
+ http://it.slashdot.org/story/12/12/05/0623215/new-25-gpu-monster-devours-strong-passwords-in-minutes
+
+
+ * Tools
+
+
+ * SSD and Flash Disk Related
+
+
+ * Disk Encryption
+
+
+ * Attacks Against Disk Encryption
+
+
+ * Risk Management as Relevant for Disk Encryption
+
+
+ * Cryptography
+
+
+ * Secure Storage
+
A. Contributors In no particular order:
- Arno Wagner
projects / platform / upstream / cryptsetup.git / blobdiff