mirror of
https://gitlab.com/cryptsetup/cryptsetup.git
synced 2025-12-10 02:10:01 +01:00
minor fixes, global spellcheck
git-svn-id: https://cryptsetup.googlecode.com/svn/trunk@710 36d66b0a-2a48-0410-832c-cd162a569da5
This commit is contained in:
Arno Wagner
77
FAQ
77
FAQ
@@ -49,13 +49,13 @@ A. Contributors
|
||||
installers after a complete backup of all LUKS containers has been
|
||||
made.
|
||||
|
||||
NO WARNING ON NON-INERACTIVE FORMAT: If you feed cryptsetup from
|
||||
NO WARNING ON NON-INTERACTIVE 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
|
||||
used from a script. In this scenario, the responsibility for
|
||||
warning the user and possibly checking for an existing LUKS header
|
||||
goes over to the script. This is a more general form of the
|
||||
is shifted to the script. This is a more general form of the
|
||||
previous item.
|
||||
|
||||
LUKS PASSPHRASE IS NOT THE MASTER KEY: The LUKS passphrase is not
|
||||
@@ -73,7 +73,7 @@ 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 caracters can, e.g. be found on
|
||||
128 ASCII characters can, e.g. be found on
|
||||
http://en.wikipedia.org/wiki/ASCII
|
||||
|
||||
|
||||
@@ -146,7 +146,7 @@ A. Contributors
|
||||
* What is the difference between "plain" and LUKS format?
|
||||
|
||||
Plain format is just that: It has no metadata on disk, reads all
|
||||
paramters from the commandline (or the defaults), derives a
|
||||
parameters 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 ath the begining of the disk, see below under "What
|
||||
being placed at the beginning of the disk, see below under "What
|
||||
does the LUKS on-disk format looks like?". The passphrases are used
|
||||
to decryt a single master key that is stored in the anti-forensic
|
||||
to decrypt 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 passhrases, and others.
|
||||
the ability to change passphrases, 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
|
||||
@@ -233,14 +233,14 @@ A. Contributors
|
||||
new key-slot.
|
||||
|
||||
|
||||
* Encrytion on top of RAID or the other way round?
|
||||
* 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
|
||||
way round, but you have to be aware that you then need to give the
|
||||
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 .
|
||||
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 .
|
||||
|
||||
|
||||
* How do I read a dm-crypt key from file?
|
||||
@@ -343,7 +343,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 typicaly works. This
|
||||
resize an encrypted partition is slow, but typically works. This
|
||||
will not change the size of the filesystem hidden under the
|
||||
encryption though.
|
||||
|
||||
@@ -440,7 +440,7 @@ A. Contributors
|
||||
|
||||
* cryptsetup segfaults on Gentoo amd64 hardened ...
|
||||
|
||||
There seems to be some inteference between the hardening and and
|
||||
There seems to be some interference 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
|
||||
@@ -455,7 +455,7 @@ A. Contributors
|
||||
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 contaner is on. Refer to Section "Backup and
|
||||
the device the LUKS container 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.
|
||||
|
||||
@@ -591,7 +591,7 @@ A. Contributors
|
||||
(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 diferent offset stems from
|
||||
512 bit key) this is 2MiB. (The different 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 +613,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 reseach results on erasing SSDs and FLASH
|
||||
drives:
|
||||
is a link to some current research 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.
|
||||
@@ -838,7 +838,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-startved situation (e.g. automatic
|
||||
key generation in an entropy-starved situation (e.g. automatic
|
||||
installation on an embedded device without network and other entropy
|
||||
sources).
|
||||
|
||||
@@ -927,10 +927,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 occuurence. For example an
|
||||
impossible. This is a frequent occurrence. 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 inacessible. See more below on LUKS
|
||||
LUKS partition permanently inaccessible. See more below on LUKS
|
||||
header damage.
|
||||
|
||||
So, data-backup in some form is non-optional. For LUKS, you may
|
||||
@@ -961,7 +961,7 @@ A. Contributors
|
||||
cryptsetup -v isLuks <device>
|
||||
|
||||
on the device. Without the "-v" it just signals its result via
|
||||
exit-status. You can alos use the more general test
|
||||
exit-status. You can also use the more general test
|
||||
|
||||
blkid -p <device>
|
||||
|
||||
@@ -1003,7 +1003,7 @@ A. Contributors
|
||||
|
||||
cat backup.tbz2.gpg | gpg - | tar djf -
|
||||
|
||||
Note: Allways verify backups, especially encrypted ones.
|
||||
Note: Always 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,9 +1015,9 @@ 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 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
|
||||
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
|
||||
between both mounted containers. Also see next item.
|
||||
|
||||
|
||||
@@ -1075,7 +1075,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 methid that encrypts the whole backup in
|
||||
filesystem level backup method 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
|
||||
@@ -1109,7 +1109,7 @@ A. Contributors
|
||||
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
|
||||
irretrivable, unless you have a LUKS header backup. You may also
|
||||
irretrievable, unless you have a LUKS header backup. You may also
|
||||
damage the key-slots in part or in full. See also last item.
|
||||
|
||||
|
||||
@@ -1131,7 +1131,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 automatizes the whole
|
||||
First, there is a script by Milan that automates the whole
|
||||
process, except generating a new LUKS header with the old master
|
||||
key (it prints the command for that though):
|
||||
|
||||
@@ -1239,9 +1239,9 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
|
||||
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 aligmnet to 2k secors and typical Flash/SSD sectors,
|
||||
result in alignment to 2k sectors and typical Flash/SSD sectors,
|
||||
which is highly desirable for a number of reasons. Changing the
|
||||
alignment is not recomended.
|
||||
alignment is not recommended.
|
||||
|
||||
That said, with default parameters, the data area starts at
|
||||
exactly 2MB offset (at 0x101000 for cryptsetup versions before
|
||||
@@ -1283,7 +1283,7 @@ 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 conatiner size of 260kiB + 512B or
|
||||
bytes, with a minimal LUKS container size of 260kiB + 512B or
|
||||
266752 bytes.
|
||||
|
||||
|
||||
@@ -1304,14 +1304,14 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
|
||||
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 somtimes works and sometimes does not. This section
|
||||
collects insights into what works, what does not and where more
|
||||
information is required.
|
||||
losetup. This sometimes 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 intertested, please email the FAQ maintainer.
|
||||
audience may be interested, please email the FAQ maintainer.
|
||||
|
||||
|
||||
* loop-aes: General observations.
|
||||
@@ -1320,7 +1320,7 @@ http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-ac
|
||||
loop-aes is a patch for losetup. Possible problems and deviations
|
||||
from cryptsetup option syntax include:
|
||||
|
||||
- Offsets specifed in bytes (cryptsetup: 512 byte sectors)
|
||||
- Offsets specified in bytes (cryptsetup: 512 byte sectors)
|
||||
|
||||
- The need to specify an IV offset
|
||||
|
||||
@@ -1338,12 +1338,11 @@ 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
|
||||
* 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 losetupp
|
||||
command
|
||||
takes it in sectors of 512 bytes each. Example: The losetup command
|
||||
|
||||
losetup -e twofish -o 2560 /dev/loop0 /dev/sdb1
|
||||
mount /dev/loop0 mountpoint
|
||||
|
||||
Reference in New Issue
Block a user