18
19
This is the FAQ (Frequently Asked Questions) for cryptsetup. It
19
20
covers Linux disk encryption with plain dm-crypt (one passphrase,
20
no management, no descriptor on disk) and LUKS (multiple user keys
21
with one master key, anti-forensics, descriptor block at start of
22
device, ...). The latest version should usually be available at
21
no management, no metadata on disk) and LUKS (multiple user keys
22
with one master key, anti-forensic features, metadata block at
23
start of device, ...). The latest version of this FAQ should
24
usually be available at
23
25
http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
25
30
ATTENTION: If you are going to read just one thing, make it the
26
31
section on Backup and Data Recovery. By far the most questions on
27
the cryptsetup mailing list are from people that just managed to
28
somehow format or overwrite the start of their LUKS partitions. In
32
the cryptsetup mailing list are from people that managed to damage
33
the start of their LUKS partitions, i.e. the LUKS header. In
29
34
most cases, there is nothing that can be done to help these poor
30
35
souls recover their data. Make sure you understand the problem and
31
limitations imposed by the LUKS security model BEFORE you face such
36
limitations imposed by the LUKS security model BEFORE you face
37
such a disaster! In particular, make sure you have a current header
38
backup before doing any potentially dangerous operations.
40
DISTRIBUTION INSTALLERS: Some distribution installers offer to
41
create LUKS containers in a way that can be mistaken as activation
42
of an existing container. Creating a new LUKS container on top of
43
an existing one leads to permanent, complete and irreversible data
44
loss. It is strongly recommended to only use distribution
45
installers after a complete backup of all LUKS containers has been
48
LUKS PASSPHRASE IS NOT THE MASTER KEY: The LUKS passphrase is not
49
used in deriving the master key. It is used in decrypting a master
50
key that is randomly selected on header creation. This means that
51
if you create a new LUKS header on top of an old one with
52
exactly the same parameters and exactly the same passphrase as the
53
old one, it will still have a different master key and your data
54
will be permanently lost.
56
PASSPHRASE CHARACTER SET: Some people have had difficulties with
57
this when upgrading distributions. It is highly advisable to only
58
use the 94 printable characters from the first 128 characters of
59
the ASCII table, as they will always have the same binary
60
representation. Other characters may have different encoding
61
depending on system configuration and your passphrase will not
62
work with a different encoding. A table of the standardized first
63
128 ASCII caracters can, e.g. be found on
64
http://en.wikipedia.org/wiki/ASCII
67
* System Specific warnings
69
- Ubuntu as of 4/2011: It seems the installer offers to create
70
LUKS partitions in a way that several people mistook for an offer
71
to activate their existing LUKS partition. The installer gives no
72
or an inadequate warning and will destroy your old LUKS header,
73
causing permanent data loss. See also the section on Backup and
76
This issue has been acknowledged by the Ubuntu dev team, see here:
77
http://launchpad.net/bugs/420080
455
517
5. Security Aspects
520
* Is LUKS insecure? Everybody can see I have encrypted data!
522
In practice it does not really matter. In most civilized countries
523
you can just refuse to hand over the keys, no harm done. In some
524
countries they can force you to hand over the keys, if they suspect
525
encryption. However the suspicion is enough, they do not have to
526
prove anything. This is for practical reasons, as even the presence
527
of a header (like the LUKS header) is not enough to prove that you
528
have any keys. It might have been an experiment, for example. Or it
529
was used as encrypted swap with a key from /dev/random. So they
530
make you prove you do not have encrypted data. Of course that is
531
just as impossible as the other way round.
533
This means that if you have a large set of random-looking data,
534
they can already lock you up. Hidden containers (encryption hidden
535
within encryption), as possible with Truecrypt, do not help
536
either. They will just assume the hidden container is there and
537
unless you hand over the key, you will stay locked up. Don't have
538
a hidden container? Though luck. Anybody could claim that.
540
Still, if you are concerned about the LUKS header, use plain
541
dm-crypt with a good passphrase. See also Section 2, "What is the
542
difference between "plain" and LUKS format?"
458
545
* Should I initialize (overwrite) a new LUKS/dm-crypt partition?
460
547
If you just create a filesystem on it, most of the old data will
793
892
6. Backup and Data Recovery
895
* Why do I need Backup?
897
First, disks die. The rate for well-treated (!) disk is about 5%
898
per year, which is high enough to worry about. There is some
899
indication that this may be even worse for some SSDs. This applies
900
both to LUKS and plain dm-crypt partitions.
902
Second, for LUKS, if anything damages the LUKS header or the
903
key-stripe area then decrypting the LUKS device can become
904
impossible. This is a frequent occuurence. For example an
905
accidental format as FAT or some software overwriting the first
906
sector where it suspects a partition boot sector typically makes a
907
LUKS partition permanently inacessible. See more below on LUKS
910
So, data-backup in some form is non-optional. For LUKS, you may
911
also want to store a header backup in some secure location. This
912
only needs an update if you change passphrases.
915
* How do I backup a LUKS header?
917
While you could just copy the appropriate number of bytes from the
918
start of the LUKS partition, the best way is to use command option
919
"luksHeaderBackup" of cryptsetup. This protects also against
920
errors when non-standard parameters have been used in LUKS
921
partition creation. Example:
924
cryptsetup luksHeaderBackup --header-backup-file h /dev/mapper/c1
926
To restore, use the inverse command, i.e.
928
cryptsetup luksHeaderRestore --header-backup-file h /dev/mapper/c1
931
* How do I backup a LUKS or dm-crypt partition?
933
There are two options, a sector-image and a plain file or
934
filesystem backup of the contents of the partition. The sector
935
image is already encrypted, but cannot be compressed and contains
936
all empty space. The filesystem backup can be compressed, can
937
contain only part of the encrypted device, but needs to be
938
encrypted separately if so desired.
940
A sector-image will contain the whole partition in encrypted form,
941
for LUKS the LUKS header, the keys-slots and the data area. It can
942
be done under Linux e.g. with dd_rescue (for a direct image copy)
943
and with "cat" or "dd". Example:
945
cat /dev/sda10 > sda10.img
946
dd_rescue /dev/sda10 sda10.img
948
You can also use any other backup software that is capable of making
949
a sector image of a partition. Note that compression is
950
ineffective for encrypted data, hence it does not make sense to
953
For a filesystem backup, you decrypt and mount the encrypted
954
partition and back it up as you would a normal filesystem. In this
955
case the backup is not encrypted, unless your encryption method
956
does that. For example you can encrypt a backup with "tar" as
959
tar cjf - <path> | gpg --cipher-algo AES -c - > backup.tbz2.gpg
961
And verify the backup like this if you are at "path":
963
cat backup.tbz2.gpg | gpg - | tar djf -
965
Note: Allways verify backups, especially encrypted ones.
967
In both cases GnuPG will ask you interactively for your symmetric
968
key. The verify will only output errors. Use "tar dvjf -" to get
969
all comparison results. To make sure no data is written to disk
970
unencrypted, turn off swap if it is not encrypted before doing the
973
You can of course use different or no compression and you can use
974
an asymmetric key if you have one and have a backup of the secret
975
key that belongs to it.
977
A second option for a filestem-level backup that can be used when
978
the backup is also on local disk (e.g. an external USB drive) is
979
to use a LUKS container there and copy the files to be backed up
980
between both mounted containers. Also see next item.
983
* Do I need a backup of the full partition? Would the header and
984
key-slots not be enough?
986
Backup protects you against two things: Disk loss or corruption
987
and user error. By far the most questions on the dm-crypt mailing
988
list about how to recover a damaged LUKS partition are related
989
to user error. For example, if you create a new filesystem on a
990
LUKS partition, chances are good that all data is lost
993
For this case, a header+key-slot backup would often be enough. But
994
keep in mind that a well-treated (!) HDD has roughly a failure
995
risk of 5% per year. It is highly advisable to have a complete
996
backup to protect against this case.
999
* *What do I need to backup if I use "decrypt_derived"?
1001
This is a script in Debian, intended for mounting /tmp or swap with
1002
a key derived from the master key of an already decrypted device.
1003
If you use this for an device with data that should be persistent,
1004
you need to make sure you either do not lose access to that master
1005
key or have a backup of the data. If you derive from a LUKS
1006
device, a header backup of that device would cover backing up the
1007
master key. Keep in mind that this does not protect against disk
1010
Note: If you recreate the LUKS header of the device you derive from
1011
(using luksFormat), the master key changes even if you use the same
1012
passphrase(s) and you will not be able to decrypt the derived
1013
device with the new LUKS header.
796
1016
* Does a backup compromise security?
798
Depends on how you do it. First, a backup is non-optional with
799
encrypted data just the same way it is with non-encrypted data.
800
Disks do break and they do not care whether they make plain or
801
encrypted data inaccessible. As a gideline, a well-treated HDD (!)
802
breaks with about 5% probability per year. This means everybody
803
will be hit sooner or later.
1018
Depends on how you do it. However if you do not have one, you are
1019
going to eventually lose your encrypted data.
805
However there are risks introduced by backups. For example if you
1021
There are risks introduced by backups. For example if you
806
1022
change/disable a key-slot in LUKS, a binary backup of the partition
807
1023
will still have the old key-slot. To deal with this, you have to
808
be able to change the key-slot on the backup as well, or use a
809
different set-up. One option is to have a different passphrase on
810
the backup and to make the backup with both containers open.
811
Another one is to make a backup of the original, opened container
812
to a single file, e.g. with tar, and to encrypt that file with
813
public-key-cryptography, e.g. with GnuPG. You can then keep the
814
secret key in a safe place, because it is only used to decrypt a
815
backup. The key the backup is encrypted with can be stored without
816
special security measures, as long as an attacker cannot replace
1024
be able to change the key-slot on the backup as well, securely
1025
erase the backup or do a filesystem-level backup instead of a binary
819
1028
If you use dm-crypt, backup is simpler: As there is no key
820
1029
management, the main risk is that you cannot wipe the backup when
822
1031
should consist of forgetting the passphrase and that you can do
823
1032
without actual access to the backup.
825
In both cases, there is an additional (usually small) risk: An
826
attacker can see how many sectors and which ones have been changed
827
since the backup. This is not possible with the public-key method
1034
In both cases, there is an additional (usually small) risk with
1035
binary backups: An attacker can see how many sectors and which
1036
ones have been changed since the backup. To prevent this, use a
1037
filesystem level backup methid that encrypts the whole backup in
1038
one go, e.g. as described above with tar and GnuPG.
830
My personal advice is to use one USB disk (low value date) or
1040
My personal advice is to use one USB disk (low value data) or
831
1041
three disks (high value data) in rotating order for backups, and
832
either use different passphrases or keep them easily accessible
833
in case you need to disable a key-slot. If you do network-backup
834
or tape-backup, I strongly recommend to go the public-key path,
835
especially as you typically cannot reliably delete data in these
836
scenarios. (Well, you can burn the tape if it is under your
1042
either use independent LUKS partitions on them, or use encrypted
1043
backup with tar and GnuPG.
1045
If you do network-backup or tape-backup, I strongly recommend to
1046
go the filesystem backup path with independent encryption, as you
1047
typically cannot reliably delete data in these scenarios,
1048
especially in a cloud setting. (Well, you can burn the tape if it
1049
is under your control...)
840
1052
* What happens if I overwrite the start of a LUKS partition or damage
860
1072
damage the key-slots in part or in full. See also last item.
1075
* How do I recover the master key from a mapped LUKS container?
1077
This is typically only needed if you managed to damage your LUKS
1078
header, but the container is still mapped, i.e. "luksOpen"ed.
1080
WARNING: This exposes the master key of the LUKS container. Note
1081
that both ways to recreate a LUKS header with the old master key
1082
described below will write the master key to disk. Unless you are
1083
sure you have securely erased it afterwards, e.g. by writing it to
1084
an encrypted partition, RAM disk or by erasing the filesystem you
1085
wrote it to by a complete overwrite, you should change the master
1086
key afterwards. Changing the master key requires a full data
1087
backup, luksFormat and then restore of the backup.
1089
First, there is a script by Milan that tries to automatize the
1090
whole process, including generating a new LUKS header with the old
1093
http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-active
1095
You can also do this manually. Here is how:
1097
- Get the master key from the device mapper. This is done by the
1098
following command. Substitute c5 for whatever you mapped to:
1100
# dmsetup table --target crypt --showkey /dev/mapper/c5
1102
0 200704 crypt aes-cbc-essiv:sha256
1103
a1704d9715f73a1bb4db581dcacadaf405e700d591e93e2eaade13ba653d0d09
1106
The result is actually one line, wrapped here for clarity. The long
1107
hex string is the master key.
1109
- Convert the master key to a binary file representation. You can
1110
do this manually, e.g. with hexedit. You can also use the tool
1111
"xxd" from vim like this:
1113
echo "a1704d9....53d0d09" | xxd -r -p > master_key
1115
- Do a luksFormat to create a new LUKS header. Unmapthe device
1116
before you do that (luksClose). Replace \dev\dsa10 with the device
1117
the LUKS container is on:
1119
cryptsetup luksFormat --master-key-file=master_key \dev\sda10
1121
Note that if the container was created with other than the default
1122
settings of the cryptsetup version you are using, you need to give
1123
additional parameters specifying the deviations. If in doubt, just
1124
do the first step, keep the whole result safe and try with the
1125
script by Milan. It does recover the other parameters as well.
1127
Side note: This is the way the decrypt_derived script gets at the
1128
master key. It just omits the conversion and hashes the master key
863
1132
* What does the on-disk structure of dm-crypt look like?
865
1134
There is none. dm-crypt takes a block device and gives encrypted
910
1179
http://code.google.com/p/cryptsetup/wiki/Specification
913
* How do I backup a LUKS header?
915
While you could just copy the appropriate number of bytes from the
916
start of the LUKS partition, the best way is to use command option
917
"luksHeaderBackup" of cryptsetup. This protects also against
918
errors when non-standard parameters have been used in LUKS
919
partition creation. Example:
922
cryptsetup luksHeaderBackup --header-backup-file h /dev/mapper/c1
924
To restore, use the inverse command, i.e.
926
cryptsetup luksHeaderRestore --header-backup-file h /dev/mapper/c1
929
* How do I backup a LUKS partition?
931
You do a sector-image of the whole partition. This will contain
932
the LUKS header, the keys-slots and the data ares. It can be done
933
under Linux e.g. with dd_rescue (for a direct image copy) and with
934
"cat" or "dd". Example:
936
cat /dev/sda10 > sda10.img
937
dd_rescue /dev/sda10 sda10.img
939
You can also use any other backup software that is capable of making
940
a sector image of a partition. Note that compression is
941
ineffective for encrypted data, hence it does not make sense to
945
* Do I need a backup of the full partition? Would the header and
946
key-slots not be enough?
948
Backup protects you against two things: Disk loss or corruption
949
and user error. By far the most questions on the dm-crypt mailing
950
list about how to recover a damaged LUKS partition are related
951
to user error. For example, if you create a new filesystem on a
952
LUKS partition, chances are good that all data is lost
955
For this case, a header+key-slot backup would often be enough. But
956
keep in mind that a well-treated (!) HDD has roughly a failure
957
risk of 5% per year. It is highly advisable to have a complete
958
backup to protect against this case.
961
* Are there security risks from a backup of the LUKS header or a
962
whole LUKS partition?
964
Yes. One risk is that if you remove access rights for specific
965
key-slots by deleting their contents, the data can still be
966
accessed with invalidated passphrase and the backup. The other
967
risk is that if you erase a LUKS partition, a backup could still
968
grant access, especially if you only erased the LUKS header and
969
not the whole partition.
972
1182
* I think this is overly complicated. Is there an alternative?
974
Yes, you can use plain dm-crypt. It does not allow multiple
1184
Not really. Encryption comes at a price. You can use plain
1185
dm-crypt to simplify things a bit. It does not allow multiple
975
1186
passphrases, but on the plus side, it has zero on disk description
976
1187
and if you overwrite some part of a plain dm-crypt partition,
977
1188
exactly the overwritten parts are lost (rounded up to sector
981
7. Issues with Specific Versions of cryptsetup
1192
7. Interoperability with other Disk Encryption Tools
1195
* What is this section about?
1197
Cryptsetup for plain dm-crypt can be used to access a number of
1198
on-disk formats created by tools like loop-aes patched into
1199
losetup. This somtimes works and sometimes does not. This section
1200
collects insights into what works, what does not and where more
1201
information is required.
1203
Additional information may be found in the mailing-list archives,
1204
mentioned at the start of this FAQ document. If you have a
1205
solution working that is not yet documented here and think a wider
1206
audience may be intertested, please email the FAQ maintainer.
1209
* loop-aes: General observations.
1211
One problem is that there are different versions of losetup around.
1212
loop-aes is a patch for losetup. Possible problems and deviations
1213
from cryptsetup option syntax include:
1215
- Offsets specifed in bytes (cryptsetup: 512 byte sectors)
1217
- The need to specify an IV offset
1219
- Encryption mode needs specifying (e.g. "-c twofish-cbc-plain")
1221
- Key size needs specifying (e.g. "-s 128" for 128 bit keys)
1223
- Passphrase hash algorithm needs specifying
1225
Also note that because plain dm-crypt and loop-aes format does not
1226
have metadata, autodetection, while feasible in most cases, would
1227
be a lot of work that nobody really wants to do. If you still have
1228
the old set-up, using a verbosity option (-v) on mapping with the
1229
old tool or having a look into the system logs after setup could
1230
give you the information you need.
1233
* loop-aes patched into losetup on debian 5.x, kernel 2.6.32
1235
In this case, the main problem seems to be that this variant of
1236
losetup takes the offset (-o option) in bytes, while cryptsetup
1237
takes it in sectors of 512 bytes each. Example: The losetupp
1240
losetup -e twofish -o 2560 /dev/loop0 /dev/sdb1
1241
mount /dev/loop0 mountpoint
1245
cryptsetup create -c twofish -o 5 --skip 5 e1 /dev/sdb1
1246
mount /dev/mapper/e1 mountpoint
1249
* loop-aes with 160 bit key
1251
This seems to be sometimes used with twofish and blowfish and
1252
represents a 160 bit ripemed160 hash output padded to 196 bit key
1253
length. It seems the corresponding options for cryptsetup are
1255
--cipher twofish-cbc-null -s 192 -h ripemd160:20
1258
8. Issues with Specific Versions of cryptsetup
984
1261
* When using the create command for plain dm-crypt with cryptsetup
added
removed
FAQ
