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
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
* 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.
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
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?
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.
* 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
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.
(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
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.
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).
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
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>
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
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\7f-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.
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
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.
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):
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
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.
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.
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
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
projects / platform / upstream / cryptsetup.git / commitdiff