Путеводитель по Руководству Linux
  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |


   cryptsetup    ( 8 )

управлять обычными dm-crypt и зашифрованными томами LUKS (manage plain dm-crypt and LUKS encrypted volumes)
  Name  |  Synopsis  |  Description  |  Plain dm-crypt or luks?  |    Warning    |  Basic actions  |  Plain mode  |  Luks extension  |  Loop-aes extension  |  Tcrypt (truecrypt-compatible and veracrypt) extension  |  Bitlk (windows bitlocker-compatible) extension (experimental)  |  Miscellaneous  |  Options  |  Examples  |  Return value  |  Notes on passphrase processing for plain mode  |  Notes on passphrase processing for luks  |  Incoherent behavior for invalid passphrases/keys  |  Notes on supported ciphers, modes, hashes and key sizes  |  Notes on passphrases  |  Notes on random number generators  |  Authenticated disk encryption (experimental)  |  Notes on loopback device use  |  Luks2 header locking  |  Deprecated actions  |  Reporting bugs  |

Предупреждение (Warning)

A lot of good information on the risks of using encrypted storage, on handling problems and on security aspects can be found in the Cryptsetup FAQ. Read it. Nonetheless, some risks deserve to be mentioned here.

Backup: Storage media die. Encryption has no influence on that. Backup is mandatory for encrypted data as well, if the data has any worth. See the Cryptsetup FAQ for advice on how to do a backup of an encrypted volume.

Character encoding: If you enter a passphrase with special symbols, the passphrase can change depending on character encoding. Keyboard settings can also change, which can make blind input hard or impossible. For example, switching from some ASCII 8-bit variant to UTF-8 can lead to a different binary encoding and hence different passphrase seen by cryptsetup, even if what you see on the terminal is exactly the same. It is therefore highly recommended to select passphrase characters only from 7-bit ASCII, as the encoding for 7-bit ASCII stays the same for all ASCII variants and UTF-8.

LUKS header: If the header of a LUKS volume gets damaged, all data is permanently lost unless you have a header-backup. If a key-slot is damaged, it can only be restored from a header-backup or if another active key-slot with known passphrase is undamaged. Damaging the LUKS header is something people manage to do with surprising frequency. This risk is the result of a trade-off between security and safety, as LUKS is designed for fast and secure wiping by just overwriting header and key-slot area.

Previously used partitions: If a partition was previously used, it is a very good idea to wipe filesystem signatures, data, etc. before creating a LUKS or plain dm-crypt container on it. For a quick removal of filesystem signatures, use "wipefs". Take care though that this may not remove everything. In particular, MD RAID signatures at the end of a device may survive. It also does not remove data. For a full wipe, overwrite the whole partition before container creation. If you do not know how to do that, the cryptsetup FAQ describes several options.