mirror of
https://gitlab.com/cryptsetup/cryptsetup.git
synced 2025-12-11 10:50:01 +01:00
updated to match web
This commit is contained in:
234
FAQ
234
FAQ
@@ -14,7 +14,7 @@ A. Contributors
|
||||
1. General Questions
|
||||
|
||||
|
||||
* What is this?
|
||||
* 1.1 What is this?
|
||||
|
||||
This is the FAQ (Frequently Asked Questions) for cryptsetup. It
|
||||
covers Linux disk encryption with plain dm-crypt (one passphrase,
|
||||
@@ -25,7 +25,7 @@ A. Contributors
|
||||
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
|
||||
|
||||
|
||||
* WARNINGS
|
||||
* 1.2 WARNINGS
|
||||
|
||||
ATTENTION: If you are going to read just one thing, make it the
|
||||
section on Backup and Data Recovery. By far the most questions on
|
||||
@@ -49,7 +49,7 @@ A. Contributors
|
||||
installers after a complete backup of all LUKS containers has been
|
||||
made.
|
||||
|
||||
NO WARNING ON NON-INTERACTIVE FORMAT: If you feed cryptsetup from
|
||||
NO WARNING ON NON-INERACTIVE FORMAT: If you feed cryptsetup from
|
||||
STDIN (e.g. via GnuPG) on LUKS format, it does not give you the
|
||||
warning that you are about to format (and e.g. will lose any
|
||||
pre-existing LUKS container on the target), as it assumes it is
|
||||
@@ -73,11 +73,11 @@ A. Contributors
|
||||
representation. Other characters may have different encoding
|
||||
depending on system configuration and your passphrase will not
|
||||
work with a different encoding. A table of the standardized first
|
||||
128 ASCII characters can, e.g. be found on
|
||||
128 ASCII caracters can, e.g. be found on
|
||||
http://en.wikipedia.org/wiki/ASCII
|
||||
|
||||
|
||||
* System Specific warnings
|
||||
* 1.3 System Specific warnings
|
||||
|
||||
- Ubuntu as of 4/2011: It seems the installer offers to create
|
||||
LUKS partitions in a way that several people mistook for an offer
|
||||
@@ -90,7 +90,7 @@ A. Contributors
|
||||
http://launchpad.net/bugs/420080
|
||||
|
||||
|
||||
* Who wrote this?
|
||||
* 1.4 Who wrote this?
|
||||
|
||||
Current FAQ maintainer is Arno Wagner <arno@wagner.name>. Other
|
||||
contributors are listed at the end. If you want to contribute, send
|
||||
@@ -113,14 +113,14 @@ A. Contributors
|
||||
least problems.
|
||||
|
||||
|
||||
* Where is the project website?
|
||||
* 1.5 Where is the project website?
|
||||
|
||||
There is the project website at http://code.google.com/p/cryptsetup/
|
||||
Please do not post questions there, nobody will read them. Use
|
||||
the mailing-list instead.
|
||||
|
||||
|
||||
* Is there a mailing-list?
|
||||
* 1.6 Is there a mailing-list?
|
||||
|
||||
Instructions on how to subscribe to the mailing-list are at on the
|
||||
project website. People are generally helpful and friendly on the
|
||||
@@ -143,10 +143,10 @@ A. Contributors
|
||||
2. Setup
|
||||
|
||||
|
||||
* What is the difference between "plain" and LUKS format?
|
||||
* 2.1 What is the difference between "plain" and LUKS format?
|
||||
|
||||
Plain format is just that: It has no metadata on disk, reads all
|
||||
parameters from the commandline (or the defaults), derives a
|
||||
paramters from the commandline (or the defaults), derives a
|
||||
master-key from the passphrase and then uses that to de-/encrypt
|
||||
the sectors of the device, with a direct 1:1 mapping between
|
||||
encrypted and decrypted sectors.
|
||||
@@ -173,15 +173,15 @@ A. Contributors
|
||||
properties like key-slot diffusion and salts, etc..
|
||||
|
||||
LUKS format uses a metadata header and 8 key-slot areas that are
|
||||
being placed at the beginning of the disk, see below under "What
|
||||
being placed ath the begining of the disk, see below under "What
|
||||
does the LUKS on-disk format looks like?". The passphrases are used
|
||||
to decrypt a single master key that is stored in the anti-forensic
|
||||
to decryt a single master key that is stored in the anti-forensic
|
||||
stripes.
|
||||
|
||||
Advantages are a higher usability, automatic configuration of
|
||||
non-default crypto parameters, defenses against low-entropy
|
||||
passphrases like salting and iterated PBKDF2 passphrase hashing,
|
||||
the ability to change passphrases, and others.
|
||||
the ability to change passhrases, and others.
|
||||
|
||||
Disadvantages are that it is readily obvious there is encrypted
|
||||
data on disk (but see side note above) and that damage to the
|
||||
@@ -193,7 +193,8 @@ A. Contributors
|
||||
non-default XTS mode).
|
||||
|
||||
|
||||
* Can I encrypt an already existing, non-empty partition to use LUKS?
|
||||
* 2.2 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
|
||||
this is to make a backup of the device in question, securely wipe
|
||||
@@ -207,7 +208,7 @@ A. Contributors
|
||||
to be in a filesystem.
|
||||
|
||||
|
||||
* How do I use LUKS with a loop-device?
|
||||
* 2.3 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
|
||||
@@ -221,7 +222,7 @@ A. Contributors
|
||||
To unmap the file when done, use "losetup -d /dev/loop0".
|
||||
|
||||
|
||||
* When I add a new key-slot to LUKS, it asks for a passphrase but
|
||||
* 2.4 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?
|
||||
|
||||
@@ -233,17 +234,17 @@ A. Contributors
|
||||
new key-slot.
|
||||
|
||||
|
||||
* Encryption on top of RAID or the other way round?
|
||||
* 2.5 Encrytion 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
|
||||
way round, but you have to be aware that you then need to give the
|
||||
passphrase for each individual disk and RAID autodetection will
|
||||
not work anymore. Therefore it is better to encrypt the RAID
|
||||
device, e.g. /dev/dm0 .
|
||||
pasphrase for each individual disk and RAID autotetection will not
|
||||
work anymore. Therefore it is better to encrypt the RAID device,
|
||||
e.g. /dev/dm0 .
|
||||
|
||||
|
||||
* How do I read a dm-crypt key from file?
|
||||
* 2.6 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:
|
||||
@@ -251,7 +252,7 @@ A. Contributors
|
||||
cryptsetup create --key-file keyfile e1 /dev/loop0
|
||||
|
||||
|
||||
* How do I read a LUKS slot key from file?
|
||||
* 2.7 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
|
||||
@@ -277,7 +278,7 @@ A. Contributors
|
||||
cryptsetup luksOpen --key-file keyfile /dev/loop0 e1
|
||||
|
||||
|
||||
* How do I read the LUKS master key from file?
|
||||
* 2.8 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
|
||||
@@ -288,7 +289,7 @@ A. Contributors
|
||||
do this here.
|
||||
|
||||
|
||||
* What are the security requirements for a key read from file?
|
||||
* 2.9 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
|
||||
@@ -300,8 +301,8 @@ A. Contributors
|
||||
head -c 256 /dev/random > keyfile
|
||||
|
||||
|
||||
* If I map a journaled file system using dm-crypt/LUKS, does it still
|
||||
provide its usual transactional guarantees?
|
||||
* 2.10 If I map a journaled file system using dm-crypt/LUKS, does it
|
||||
still provide its usual transactional guarantees?
|
||||
|
||||
As far as I know it does (but I may be wrong), but please note that
|
||||
these "guarantees" are far weaker than they appear to be. For
|
||||
@@ -323,8 +324,8 @@ A. Contributors
|
||||
locking. Kernel 2.6.38 is expected to have more improvements here.
|
||||
|
||||
|
||||
* Can I use LUKS or cryptsetup with a more secure (external) medium
|
||||
for key storage, e.g. TPM or a smartcard?
|
||||
* 2.11 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
|
||||
write the glue-logic yourself though. Basically you can have
|
||||
@@ -333,7 +334,7 @@ A. Contributors
|
||||
storage.
|
||||
|
||||
|
||||
* Can I resize a dm-crypt or LUKS partition?
|
||||
* 2.12 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
|
||||
@@ -343,7 +344,7 @@ A. Contributors
|
||||
LUKS container does not resize the filesystem in it. The backup is
|
||||
really non-optional here, as a lot can go wrong, resulting in
|
||||
partial or complete data loss. Using something like gparted to
|
||||
resize an encrypted partition is slow, but typically works. This
|
||||
resize an encrypted partition is slow, but typicaly works. This
|
||||
will not change the size of the filesystem hidden under the
|
||||
encryption though.
|
||||
|
||||
@@ -356,7 +357,7 @@ A. Contributors
|
||||
3. Common Problems
|
||||
|
||||
|
||||
* My dm-crypt/LUKS mapping does not work! What general steps are
|
||||
* 3.1 My dm-crypt/LUKS mapping does not work! What general steps are
|
||||
there to investigate the problem?
|
||||
|
||||
If you get a specific error message, investigate what it claims
|
||||
@@ -375,15 +376,15 @@ A. Contributors
|
||||
the kernel. The output of "cat /proc/crypto" needs to list them.
|
||||
|
||||
|
||||
* My dm-crypt mapping suddenly stopped when upgrading cryptsetup.
|
||||
* 3.2 My dm-crypt mapping suddenly stopped when upgrading cryptsetup.
|
||||
|
||||
The default cipher, hash or mode may have changed (the mode changed
|
||||
from 1.0.x to 1.1.x). See under "Issues With Specific Versions of
|
||||
cryptsetup".
|
||||
|
||||
|
||||
* When I call cryptsetup from cron/CGI, I get errors about unknown
|
||||
features?
|
||||
* 3.3 When I call cryptsetup from cron/CGI, I get errors about
|
||||
unknown features?
|
||||
|
||||
If you get errors about unknown parameters or the like that are not
|
||||
present when cryptsetup is called from the shell, make sure you
|
||||
@@ -395,7 +396,7 @@ A. Contributors
|
||||
version gets called.
|
||||
|
||||
|
||||
* Unlocking a LUKS device takes very long. Why?
|
||||
* 3.4 Unlocking a LUKS device takes very long. Why?
|
||||
|
||||
The iteration time for a key-slot (see Section 5 for an explanation
|
||||
what iteration does) is calculated when setting a passphrase. By
|
||||
@@ -424,8 +425,8 @@ A. Contributors
|
||||
matter.
|
||||
|
||||
|
||||
* "blkid" sees a LUKS UUID and an ext2/swap UUID on the same device.
|
||||
What is wrong?
|
||||
* 3.5 "blkid" sees a LUKS UUID and an ext2/swap UUID on the same
|
||||
device. What is wrong?
|
||||
|
||||
Some old versions of cryptsetup have a bug where the header does
|
||||
not get completely wiped during LUKS format and an older ext2/swap
|
||||
@@ -438,9 +439,9 @@ A. Contributors
|
||||
cryptsetup luksHeaderRestore --header-backup-file <file> <device>
|
||||
|
||||
|
||||
* cryptsetup segfaults on Gentoo amd64 hardened ...
|
||||
* 3.6 cryptsetup segfaults on Gentoo amd64 hardened ...
|
||||
|
||||
There seems to be some interference between the hardening and and
|
||||
There seems to be some inteference between the hardening and and
|
||||
the way cryptsetup benchmarks PBKDF2. The solution to this is
|
||||
currently not quite clear for an encrypted root filesystem. For
|
||||
other uses, you can apparently specify USE="dynamic" as compile
|
||||
@@ -450,17 +451,18 @@ A. Contributors
|
||||
4. Troubleshooting
|
||||
|
||||
|
||||
* I get the error "LUKS keyslot x is invalid." What does that mean?
|
||||
* 4.1 I get the error "LUKS keyslot x is invalid." What does that
|
||||
mean?
|
||||
|
||||
This means that the given keyslot has an offset that points
|
||||
outside the valid keyslot area. Typically, the reason is a
|
||||
corrupted LUKS header because something was written to the start of
|
||||
the device the LUKS container is on. Refer to Section "Backup and
|
||||
the device the LUKS contaner is on. Refer to Section "Backup and
|
||||
Data Recovery" and ask on the mailing list if you have trouble
|
||||
diagnosing and (if still possible) repairing this.
|
||||
|
||||
|
||||
* Can a bad RAM module cause problems?
|
||||
* 4.2 Can a bad RAM module cause problems?
|
||||
|
||||
LUKS and dm-crypt can give the RAM quite a workout, especially when
|
||||
combined with software RAID. In particular the combination RAID5 +
|
||||
@@ -502,7 +504,7 @@ A. Contributors
|
||||
did a verify.
|
||||
|
||||
|
||||
* How do I test RAM?
|
||||
* 4.3 How do I test RAM?
|
||||
|
||||
First you should know that overclocking often makes memory
|
||||
problems worse. So if you overclock (which I strongly recommend
|
||||
@@ -540,7 +542,7 @@ A. Contributors
|
||||
5. Security Aspects
|
||||
|
||||
|
||||
* Is LUKS insecure? Everybody can see I have encrypted data!
|
||||
* 5.1 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
|
||||
@@ -565,7 +567,7 @@ A. Contributors
|
||||
difference between "plain" and LUKS format?"
|
||||
|
||||
|
||||
* Should I initialize (overwrite) a new LUKS/dm-crypt partition?
|
||||
* 5.2 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
|
||||
@@ -584,14 +586,14 @@ A. Contributors
|
||||
dd if=/dev/zero of=/dev/mapper/e1
|
||||
|
||||
|
||||
* How do I securely erase a LUKS (or other) partition?
|
||||
* 5.3 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
|
||||
(keyslots x stripes x keysize) + offset bytes. For the default
|
||||
parameters, this is the 1'052'672 bytes, i.e. 1MiB + 4096 of the
|
||||
LUKS partition. For 512 bit key length (e.g. for aes-xts-plain with
|
||||
512 bit key) this is 2MiB. (The different offset stems from
|
||||
512 bit key) this is 2MiB. (The diferent offset stems from
|
||||
differences in the sector alignment of the key-slots.) If in doubt,
|
||||
just be generous and overwrite the first 10MB or so, it will likely
|
||||
still be fast enough. A single overwrite with zeros should be
|
||||
@@ -613,8 +615,8 @@ A. Contributors
|
||||
in this regard. Still, due to the anti-forensic properties of the
|
||||
LUKS key-slots, a single overwrite of an SSD or FLASH drive could
|
||||
be enough. If in doubt, use physical destruction in addition. Here
|
||||
is a link to some current research results on erasing SSDs and
|
||||
FLASH drives:
|
||||
is a link to some current reseach results on erasing SSDs and FLASH
|
||||
drives:
|
||||
http://www.usenix.org/events/fast11/tech/full_papers/Wei.pdf
|
||||
|
||||
Keep in mind to also erase all backups.
|
||||
@@ -625,7 +627,7 @@ A. Contributors
|
||||
dd_rescue -w /dev/zero /dev/sde1
|
||||
|
||||
|
||||
* How do I securely erase a backup of a LUKS partition or header?
|
||||
* 5.4 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
|
||||
@@ -643,12 +645,13 @@ A. Contributors
|
||||
lead to data not actually being deleted at all during overwrites.
|
||||
|
||||
|
||||
* What about backup? Does it compromise security?
|
||||
* 5.5 What about backup? Does it compromise security?
|
||||
|
||||
That depends. See next section.
|
||||
That depends. See item 6.7.
|
||||
|
||||
|
||||
* Why is all my data permanently gone if I overwrite the LUKS header?
|
||||
* 5.6 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.
|
||||
@@ -675,7 +678,7 @@ A. Contributors
|
||||
a mapped LUKS container?" in Section "Backup and Data Recovery".
|
||||
|
||||
|
||||
* What is a "salt"?
|
||||
* 5.7 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
|
||||
@@ -703,7 +706,7 @@ A. Contributors
|
||||
infeasible.
|
||||
|
||||
|
||||
* Is LUKS secure with a low-entropy (bad) passphrase?
|
||||
* 5.8 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
|
||||
@@ -756,7 +759,7 @@ A. Contributors
|
||||
this is good passphrase material.
|
||||
|
||||
|
||||
* What is "iteration count" and why is decreasing it a bad idea?
|
||||
* 5.9 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
|
||||
@@ -821,14 +824,36 @@ A. Contributors
|
||||
this danger significantly.
|
||||
|
||||
|
||||
* What about iteration count with plain dm-crypt?
|
||||
* 5.10 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 refered 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.
|
||||
Asuming 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 resouceful attacker is a
|
||||
high-entropy passphrase, see items 5.8 and 5.9.
|
||||
|
||||
|
||||
* 5.11 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.
|
||||
|
||||
|
||||
* Is LUKS with default parameters less secure on a slow CPU?
|
||||
* 5.12 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
|
||||
@@ -838,7 +863,7 @@ A. Contributors
|
||||
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
|
||||
key generation in an entropy-startved situation (e.g. automatic
|
||||
installation on an embedded device without network and other entropy
|
||||
sources).
|
||||
|
||||
@@ -852,7 +877,7 @@ A. Contributors
|
||||
compensate for problems in front of the keyboard.
|
||||
|
||||
|
||||
* Why was the default aes-cbc-plain replaced with aes-cbc-essiv?
|
||||
* 5.13 Why was the default aes-cbc-plain replaced with aes-cbc-essiv?
|
||||
|
||||
The problem is that cbc-plain has a fingerprint vulnerability, where
|
||||
a specially crafted file placed into the crypto-container can be
|
||||
@@ -880,7 +905,7 @@ A. Contributors
|
||||
knowing the encryption key and the watermarking attack fails.
|
||||
|
||||
|
||||
* Are there any problems with "plain" IV? What is "plain64"?
|
||||
* 5.14 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.
|
||||
@@ -896,7 +921,7 @@ A. Contributors
|
||||
does not cause any performance penalty compared to "plain".
|
||||
|
||||
|
||||
* What about XTS mode?
|
||||
* 5.15 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
|
||||
@@ -918,7 +943,7 @@ A. Contributors
|
||||
6. Backup and Data Recovery
|
||||
|
||||
|
||||
* Why do I need Backup?
|
||||
* 6.1 Why do I need Backup?
|
||||
|
||||
First, disks die. The rate for well-treated (!) disk is about 5%
|
||||
per year, which is high enough to worry about. There is some
|
||||
@@ -927,10 +952,10 @@ A. Contributors
|
||||
|
||||
Second, for LUKS, if anything damages the LUKS header or the
|
||||
key-stripe area then decrypting the LUKS device can become
|
||||
impossible. This is a frequent occurrence. For example an
|
||||
impossible. This is a frequent occuurence. For example an
|
||||
accidental format as FAT or some software overwriting the first
|
||||
sector where it suspects a partition boot sector typically makes a
|
||||
LUKS partition permanently inaccessible. See more below on LUKS
|
||||
LUKS partition permanently inacessible. See more below on LUKS
|
||||
header damage.
|
||||
|
||||
So, data-backup in some form is non-optional. For LUKS, you may
|
||||
@@ -938,7 +963,7 @@ A. Contributors
|
||||
only needs an update if you change passphrases.
|
||||
|
||||
|
||||
* How do I backup a LUKS header?
|
||||
* 6.2 How do I backup a LUKS header?
|
||||
|
||||
While you could just copy the appropriate number of bytes from the
|
||||
start of the LUKS partition, the best way is to use command option
|
||||
@@ -954,14 +979,14 @@ A. Contributors
|
||||
cryptsetup luksHeaderRestore --header-backup-file h <device>
|
||||
|
||||
|
||||
* How do I test a LUKS header?
|
||||
* 6.3 How do I test a LUKS header?
|
||||
|
||||
Use
|
||||
|
||||
cryptsetup -v isLuks <device>
|
||||
|
||||
on the device. Without the "-v" it just signals its result via
|
||||
exit-status. You can also use the more general test
|
||||
exit-status. You can alos use the more general test
|
||||
|
||||
blkid -p <device>
|
||||
|
||||
@@ -969,7 +994,7 @@ A. Contributors
|
||||
"-p" for old versions of blkid that do not support it.
|
||||
|
||||
|
||||
* How do I backup a LUKS or dm-crypt partition?
|
||||
* 6.4 How do I backup a LUKS or dm-crypt partition?
|
||||
|
||||
There are two options, a sector-image and a plain file or
|
||||
filesystem backup of the contents of the partition. The sector
|
||||
@@ -1003,7 +1028,7 @@ A. Contributors
|
||||
|
||||
cat backup.tbz2.gpg | gpg - | tar djf -
|
||||
|
||||
Note: Always verify backups, especially encrypted ones.
|
||||
Note: Allways verify backups, especially encrypted ones.
|
||||
|
||||
In both cases GnuPG will ask you interactively for your symmetric
|
||||
key. The verify will only output errors. Use "tar dvjf -" to get
|
||||
@@ -1015,13 +1040,13 @@ A. Contributors
|
||||
an asymmetric key if you have one and have a backup of the secret
|
||||
key that belongs to it.
|
||||
|
||||
A second option for a filesystem-level backup that can be used
|
||||
when the backup is also on local disk (e.g. an external USB drive)
|
||||
is to use a LUKS container there and copy the files to be backed up
|
||||
A second option for a filestem-level backup that can be used when
|
||||
the backup is also on local disk (e.g. an external USB drive) is
|
||||
to use a LUKS container there and copy the files to be backed up
|
||||
between both mounted containers. Also see next item.
|
||||
|
||||
|
||||
* Do I need a backup of the full partition? Would the header and
|
||||
* 6.5 Do I need a backup of the full partition? Would the header and
|
||||
key-slots not be enough?
|
||||
|
||||
Backup protects you against two things: Disk loss or corruption
|
||||
@@ -1037,7 +1062,7 @@ A. Contributors
|
||||
backup to protect against this case.
|
||||
|
||||
|
||||
* *What do I need to backup if I use "decrypt_derived"?
|
||||
* *6.6 What do I need to backup if I use "decrypt_derived"?
|
||||
|
||||
This is a script in Debian, intended for mounting /tmp or swap with
|
||||
a key derived from the master key of an already decrypted device.
|
||||
@@ -1054,7 +1079,7 @@ A. Contributors
|
||||
device with the new LUKS header.
|
||||
|
||||
|
||||
* Does a backup compromise security?
|
||||
* 6.7 Does a backup compromise security?
|
||||
|
||||
Depends on how you do it. However if you do not have one, you are
|
||||
going to eventually lose your encrypted data.
|
||||
@@ -1075,7 +1100,7 @@ A. Contributors
|
||||
In both cases, there is an additional (usually small) risk with
|
||||
binary backups: An attacker can see how many sectors and which
|
||||
ones have been changed since the backup. To prevent this, use a
|
||||
filesystem level backup method that encrypts the whole backup in
|
||||
filesystem level backup methid that encrypts the whole backup in
|
||||
one go, e.g. as described above with tar and GnuPG.
|
||||
|
||||
My personal advice is to use one USB disk (low value data) or
|
||||
@@ -1090,8 +1115,8 @@ A. Contributors
|
||||
is under your control...)
|
||||
|
||||
|
||||
* What happens if I overwrite the start of a LUKS partition or damage
|
||||
the LUKS header or key-slots?
|
||||
* 6.8 What happens if I overwrite the start of a LUKS partition or
|
||||
damage the LUKS header or key-slots?
|
||||
|
||||
There are two critical components for decryption: The salt values
|
||||
in the header itself and the key-slots. If the salt values are
|
||||
@@ -1104,16 +1129,16 @@ A. Contributors
|
||||
4-6 bits in random locations of its 128kiB size is quite enough.
|
||||
|
||||
|
||||
* What happens if I (quick) format a LUKS partition?
|
||||
* 6.9 What happens if I (quick) format a LUKS partition?
|
||||
|
||||
I have not tried the different ways to do this, but very likely you
|
||||
will have written a new boot-sector, which in turn overwrites the
|
||||
LUKS header, including the salts, making your data permanently
|
||||
irretrievable, unless you have a LUKS header backup. You may also
|
||||
irretrivable, unless you have a LUKS header backup. You may also
|
||||
damage the key-slots in part or in full. See also last item.
|
||||
|
||||
|
||||
* How do I recover the master key from a mapped LUKS container?
|
||||
* 6.10 How do I recover the master key from a mapped LUKS container?
|
||||
|
||||
This is typically only needed if you managed to damage your LUKS
|
||||
header, but the container is still mapped, i.e. "luksOpen"ed. It
|
||||
@@ -1131,7 +1156,7 @@ A. Contributors
|
||||
key afterwards. Changing the master key requires a full data
|
||||
backup, luksFormat and then restore of the backup.
|
||||
|
||||
First, there is a script by Milan that automates the whole
|
||||
First, there is a script by Milan that automatizes the whole
|
||||
process, except generating a new LUKS header with the old master
|
||||
key (it prints the command for that though):
|
||||
|
||||
@@ -1183,7 +1208,7 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
You may want to disable the old one afterwards.
|
||||
|
||||
|
||||
* What does the on-disk structure of dm-crypt look like?
|
||||
* 6.11 What does the on-disk structure of dm-crypt look like?
|
||||
|
||||
There is none. dm-crypt takes a block device and gives encrypted
|
||||
access to each of its blocks with a key derived from the passphrase
|
||||
@@ -1196,7 +1221,7 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
overwrote.
|
||||
|
||||
|
||||
* What does the on-disk structure of LUKS look like?
|
||||
* 6.12 What does the on-disk structure of LUKS look like?
|
||||
|
||||
A LUKS partition consists of a header, followed by 8 key-slot
|
||||
descriptors, followed by 8 key slots, followed by the encrypted
|
||||
@@ -1235,13 +1260,13 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
http://code.google.com/p/cryptsetup/wiki/Specification
|
||||
|
||||
|
||||
* What is the smallest possible LUKS container?
|
||||
* 6.13 What is the smallest possible LUKS container?
|
||||
|
||||
Note: From cryptsetup 1.3 onwards, alignment is set to 1MB. With
|
||||
modern Linux partitioning tools that also align to 1MB, this will
|
||||
result in alignment to 2k sectors and typical Flash/SSD sectors,
|
||||
result in aligmnet to 2k secors and typical Flash/SSD sectors,
|
||||
which is highly desirable for a number of reasons. Changing the
|
||||
alignment is not recommended.
|
||||
alignment is not recomended.
|
||||
|
||||
That said, with default parameters, the data area starts at
|
||||
exactly 2MB offset (at 0x101000 for cryptsetup versions before
|
||||
@@ -1283,11 +1308,11 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
cryptsetup luksFormat -c blowfish -s 64 --align-payload=8 /dev/loop0
|
||||
|
||||
This results in a data offset of 0x41000, i.e. 260kiB or 266240
|
||||
bytes, with a minimal LUKS container size of 260kiB + 512B or
|
||||
bytes, with a minimal LUKS conatiner size of 260kiB + 512B or
|
||||
266752 bytes.
|
||||
|
||||
|
||||
* I think this is overly complicated. Is there an alternative?
|
||||
* 6.14 I think this is overly complicated. Is there an alternative?
|
||||
|
||||
Not really. Encryption comes at a price. You can use plain
|
||||
dm-crypt to simplify things a bit. It does not allow multiple
|
||||
@@ -1300,27 +1325,27 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
7. Interoperability with other Disk Encryption Tools
|
||||
|
||||
|
||||
* What is this section about?
|
||||
* 7.1 What is this section about?
|
||||
|
||||
Cryptsetup for plain dm-crypt can be used to access a number of
|
||||
on-disk formats created by tools like loop-aes patched into
|
||||
losetup. This sometimes works and sometimes does not. This
|
||||
section collects insights into what works, what does not and where
|
||||
more information is required.
|
||||
losetup. This somtimes works and sometimes does not. This section
|
||||
collects insights into what works, what does not and where more
|
||||
information is required.
|
||||
|
||||
Additional information may be found in the mailing-list archives,
|
||||
mentioned at the start of this FAQ document. If you have a
|
||||
solution working that is not yet documented here and think a wider
|
||||
audience may be interested, please email the FAQ maintainer.
|
||||
audience may be intertested, please email the FAQ maintainer.
|
||||
|
||||
|
||||
* loop-aes: General observations.
|
||||
* 7.2 loop-aes: General observations.
|
||||
|
||||
One problem is that there are different versions of losetup around.
|
||||
loop-aes is a patch for losetup. Possible problems and deviations
|
||||
from cryptsetup option syntax include:
|
||||
|
||||
- Offsets specified in bytes (cryptsetup: 512 byte sectors)
|
||||
- Offsets specifed in bytes (cryptsetup: 512 byte sectors)
|
||||
|
||||
- The need to specify an IV offset
|
||||
|
||||
@@ -1338,11 +1363,12 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
give you the information you need.
|
||||
|
||||
|
||||
* loop-aes patched into losetup on Debian 5.x, kernel 2.6.32
|
||||
* 7.3 loop-aes patched into losetup on debian 5.x, kernel 2.6.32
|
||||
|
||||
In this case, the main problem seems to be that this variant of
|
||||
losetup takes the offset (-o option) in bytes, while cryptsetup
|
||||
takes it in sectors of 512 bytes each. Example: The losetup command
|
||||
takes it in sectors of 512 bytes each. Example: The losetupp
|
||||
command
|
||||
|
||||
losetup -e twofish -o 2560 /dev/loop0 /dev/sdb1
|
||||
mount /dev/loop0 mountpoint
|
||||
@@ -1353,7 +1379,7 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
mount /dev/mapper/e1 mountpoint
|
||||
|
||||
|
||||
* loop-aes with 160 bit key
|
||||
* 7.4 loop-aes with 160 bit key
|
||||
|
||||
This seems to be sometimes used with twofish and blowfish and
|
||||
represents a 160 bit ripemed160 hash output padded to 196 bit key
|
||||
@@ -1365,9 +1391,9 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
8. Issues with Specific Versions of cryptsetup
|
||||
|
||||
|
||||
* When using the create command for plain dm-crypt with cryptsetup
|
||||
1.1.x, the mapping is incompatible and my data is not accessible
|
||||
anymore!
|
||||
* 8.1 When using the create command for plain dm-crypt with
|
||||
cryptsetup 1.1.x, the mapping is incompatible and my data is not
|
||||
accessible anymore!
|
||||
|
||||
With cryptsetup 1.1.x, the distro maintainer can define different
|
||||
default encryption modes for LUKS and plain devices. You can check
|
||||
@@ -1386,7 +1412,7 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
problem.
|
||||
|
||||
|
||||
* cryptsetup on SLED 10 has problems...
|
||||
* 8.2 cryptsetup on SLED 10 has problems...
|
||||
|
||||
SLED 10 is missing an essential kernel patch for dm-crypt, which
|
||||
is broken in its kernel as a result. There may be a very old
|
||||
|
||||
Reference in New Issue
Block a user