| Cryptsetup 2.0.0 Release Notes |
| ================================== |
| Stable release with experimental features. |
| |
| This version introduces a new on-disk LUKS2 format. |
| |
| The legacy LUKS (referenced as LUKS1) will be fully supported |
| forever as well as a traditional and fully backward compatible format. |
| |
| NOTE: This version changes soname of libcryptsetup library and increases |
| major version for all public symbols. |
| Most of the old functions are fully backward compatible, so only |
| recompilation of programs should be needed. |
| |
| Please note that authenticated disk encryption, non-cryptographic |
| data integrity protection (dm-integrity), use of Argon2 Password-Based |
| Key Derivation Function and the LUKS2 on-disk format itself are new |
| features and can contain some bugs. |
| |
| To provide all security features of authenticated encryption we need |
| better nonce-reuse resistant algorithm in kernel (see note below). |
| For now, please use authenticated encryption as experimental feature. |
| |
| Please do not use LUKS2 without properly configured backup or in |
| production systems that need to be compatible with older systems. |
| |
| Changes since version 2.0.0-RC1 |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| * Limit KDF requested (for format) memory by available physical memory. |
| On some systems too high requested amount of memory causes OOM killer |
| to kill the process (instead of returning ENOMEM). |
| We never try to use more than half of available physical memory. |
| |
| * Ignore device alignment if it is not multiple of minimal-io. |
| Some USB enclosures seems to report bogus topology info that |
| prevents to use LUKS detached header. |
| |
| Changes since version 2.0.0-RC0 |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| * Enable to use system libargon2 instead of bundled version. |
| Renames --disable-argon2 to --disable-internal-argon2 option |
| and adds --enable-libargon2 flag to allow system libargon2. |
| |
| * Changes in build system (Automake) |
| - The build system now uses non-recursive automake (except for tests). |
| (Tools binaries are now located in buildroot directory.) |
| - New --disable-cryptsetup option to disable build of cryptsetup tool. |
| - Enable build of cryptsetup-reencrypt by default. |
| |
| * Install tmpfiles.d configuration for LUKS2 locking directory. |
| You can overwrite this using --with-tmpfilesdir configure option. |
| If your distro does not support tmpfiles.d directory, you have |
| to create locking directory (/run/lock/cryptsetup) in cryptsetup |
| package (or init scripts). |
| |
| * Adds limited support for offline reencryption of LUKS2 format. |
| |
| * Decrease size of testing images (and the whole release archive). |
| |
| * Fixes for several memory leaks found by Valgrind and Coverity tools. |
| |
| * Fixes for several typos in man pages and error messages. |
| |
| * LUKS header file in luksFormat is now automatically created |
| if it does not exist. |
| |
| * Do not allow resize if device size is not aligned to sector size. |
| |
| Cryptsetup 2.0.0 RC0 Release Notes |
| ================================== |
| |
| Important features |
| ~~~~~~~~~~~~~~~~~~ |
| |
| * New command integritysetup: support for the new dm-integrity kernel target. |
| |
| The dm-integrity is a new kernel device-mapper target that introduces |
| software emulation of per-sector integrity fields on the disk sector level. |
| It is available since Linux kernel version 4.12. |
| |
| The provided per-sector metadata fields can be used for storing a data |
| integrity checksum (for example CRC32). |
| The dm-integrity implements data journal that enforces atomic update |
| of a sector and its integrity metadata. |
| |
| Integritysetup is a CLI utility that can setup standalone dm-integrity |
| devices (that internally check integrity of data). |
| |
| Integritysetup is intended to be used for settings that require |
| non-cryptographic data integrity protection with no data encryption. |
| Fo setting integrity protected encrypted devices, see disk authenticated |
| encryption below. |
| |
| Note that after formatting the checksums need to be initialized; |
| otherwise device reads will fail because of integrity errors. |
| Integritysetup by default tries to wipe the device with zero blocks |
| to avoid this problem. Device wipe can be time-consuming, you can skip |
| this step by specifying --no-wipe option. |
| (But note that not wiping device can cause some operations to fail |
| if a write is not multiple of page size and kernel page cache tries |
| to read sectors with not yet initialized checksums.) |
| |
| The default setting is tag size 4 bytes per-sector and CRC32C protection. |
| To format device with these defaults: |
| $ integritysetup format <device> |
| $ integritysetup open <device> <name> |
| |
| Note that used algorithm (unlike tag size) is NOT stored in device |
| kernel superblock and if you use different algorithm, you MUST specify |
| it in every open command, for example: |
| $ integritysetup format <device> --tag-size 32 --integrity sha256 |
| $ integritysetup open <device> <name> --integrity sha256 |
| |
| For more info, see integrity man page. |
| |
| * Veritysetup command can now format and activate dm-verity devices |
| that contain Forward Error Correction (FEC) (Reed-Solomon code is used). |
| This feature is used on most of Android devices already (available since |
| Linux kernel 4.5). |
| |
| There are new options --fec-device, --fec-offset to specify data area |
| with correction code and --fec-roots that set Redd-Solomon generator roots. |
| This setting can be used for format command (veritysetup will calculate |
| and store RS codes) or open command (veritysetup configures kernel |
| dm-verity to use RS codes). |
| |
| For more info see veritysetup man page. |
| |
| * Support for larger sector sizes for crypt devices. |
| |
| LUKS2 and plain crypt devices can be now configured with larger encryption |
| sector (typically 4096 bytes, sector size must be the power of two, |
| maximal sector size is 4096 bytes for portability). |
| Large sector size can decrease encryption overhead and can also help |
| with some specific crypto hardware accelerators that perform very |
| badly with 512 bytes sectors. |
| |
| Note that if you configure such a larger sector of the device that does use |
| smaller physical sector, there is a possibility of a data corruption during |
| power fail (partial sector writes). |
| |
| WARNING: If you use different sector size for a plain device after data were |
| stored, the decryption will produce garbage. |
| |
| For LUKS2, the sector size is stored in metadata and cannot be changed later. |
| |
| LUKS2 format and features |
| ~~~~~~~~~~~~~~~~~~~~~~~~~ |
| The LUKS2 is an on-disk storage format designed to provide simple key |
| management, primarily intended for Full Disk Encryption based on dm-crypt. |
| |
| The LUKS2 is inspired by LUKS1 format and in some specific situations (most |
| of the default configurations) can be converted in-place from LUKS1. |
| |
| The LUKS2 format is designed to allow future updates of various |
| parts without the need to modify binary structures and internally |
| uses JSON text format for metadata. Compilation now requires the json-c library |
| that is used for JSON data processing. |
| |
| On-disk format provides redundancy of metadata, detection |
| of metadata corruption and automatic repair from metadata copy. |
| |
| NOTE: For security reasons, there is no redundancy in keyslots binary data |
| (encrypted keys) but the format allows adding such a feature in future. |
| |
| NOTE: to operate correctly, LUKS2 requires locking of metadata. |
| Locking is performed by using flock() system call for images in file |
| and for block device by using a specific lock file in /run/lock/cryptsetup. |
| |
| This directory must be created by distribution (do not rely on internal |
| fallback). For systemd-based distribution, you can simply install |
| scripts/cryptsetup.conf into tmpfiles.d directory. |
| |
| For more details see LUKS2-format.txt and LUKS2-locking.txt in the docs |
| directory. (Please note this is just overview, there will be more formal |
| documentation later.) |
| |
| LUKS2 use |
| ~~~~~~~~~ |
| |
| LUKS2 allows using all possible configurations as LUKS1. |
| |
| To format device as LUKS2, you have to add "--type luks2" during format: |
| |
| $ cryptsetup luksFormat --type luks2 <device> |
| |
| All commands issued later will recognize the new format automatically. |
| |
| The newly added features in LUKS2 include: |
| |
| * Authenticated disk (sector) encryption (EXPERIMENTAL) |
| |
| Legacy Full disk encryption (FDE), for example, LUKS1, is a length-preserving |
| encryption (plaintext is the same size as a ciphertext). |
| Such FDE can provide data confidentiality, but cannot provide sound data |
| integrity protection. |
| |
| Full disk authenticated encryption is a way how to provide both |
| confidentiality and data integrity protection. Integrity protection here means |
| not only detection of random data corruption (silent data corruption) but also |
| prevention of an unauthorized intentional change of disk sector content. |
| |
| NOTE: Integrity protection of this type cannot prevent a replay attack. |
| An attacker can replace the device or its part of the old content, and it |
| cannot be detected. |
| If you need such protection, better use integrity protection on a higher layer. |
| |
| For data integrity protection on the sector level, we need additional |
| per-sector metadata space. In LUKS2 this space is provided by a new |
| device-mapper dm-integrity target (available since kernel 4.12). |
| Here the integrity target provides only reliable per-sector metadata store, |
| and the whole authenticated encryption is performed inside dm-crypt stacked |
| over the dm-integrity device. |
| |
| For encryption, Authenticated Encryption with Additional Data (AEAD) is used. |
| Every sector is processed as a encryption request of this format: |
| |
| |----- AAD -------|------ DATA -------|-- AUTH TAG --| |
| | (authenticated) | (auth+encryption) | | |
| | sector_LE | IV | sector in/out | tag in/out | |
| |
| AEAD encrypts the whole sector and also authenticates sector number |
| (to detect sector relocation) and also authenticates Initialization Vector. |
| |
| AEAD encryption produces encrypted data and authentication tag. |
| The authenticated tag is then stored in per-sector metadata space provided |
| by dm-integrity. |
| |
| Most of the current AEAD algorithms requires IV as a nonce, value that is |
| never reused. Because sector number, as an IV, cannot be used in this |
| environment, we use a new random IV (IV is a random value generated by system |
| RNG on every write). This random IV is then stored in the per-sector metadata |
| as well. |
| |
| Because the authentication tag (and IV) requires additional space, the device |
| provided for a user has less capacity. Also, the data journalling means that |
| writes are performed twice, decreasing throughput. |
| |
| This integrity protection works better with SSDs. If you want to ignore |
| dm-integrity data journal (because journalling is performed on some higher |
| layer or you just want to trade-off performance to safe recovery), you can |
| switch journal off with --integrity-no-journal option. |
| (This flag can be stored persistently as well.) |
| |
| Note that (similar to integritysetup) the device read will fail if |
| authentication tag is not initialized (no previous write). |
| By default cryptsetup run wipe of a device (writing zeroes) to initialize |
| authentication tags. This operation can be very time-consuming. |
| You can skip device wipe using --integrity-no-wipe option. |
| |
| To format LUKS2 device with integrity protection, use new --integrity option. |
| |
| For now, there are very few AEAD algorithms that can be used, and some |
| of them are known to be problematic. In this release we support only |
| a few of AEAD algorithms (options are for now hard coded), later this |
| extension will be completely algorithm-agnostic. |
| |
| For testing of authenticated encryption, these algorithms work for now: |
| |
| 1) aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the authentication tag. |
| (Common FDE mode + independent authentication tag. Authentication key |
| for HMAC is independently generated. This mode is very slow.) |
| $ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-plain64 --integrity hmac-sha256 |
| |
| 2) aes-gcm-random (native AEAD mode) |
| DO NOT USE in production! The GCM mode uses only 96-bit nonce, |
| and possible collision means fatal security problem. |
| GCM mode has very good hardware support through AES-NI, so it is useful |
| for performance testing. |
| $ cryptsetup luksFormat --type luks2 <device> --cipher aes-gcm-random --integrity aead |
| |
| 3) ChaCha20 with Poly1305 authenticator (according to RFC7539) |
| $ cryptsetup luksFormat --type luks2 <device> --cipher chacha20-random --integrity poly1305 |
| |
| To specify AES128/AES256 just specify proper key size (without possible |
| authentication key). Other symmetric ciphers, like Serpent or Twofish, |
| should work as well. The mode 1) and 2) should be compatible with IEEE 1619.1 |
| standard recommendation. |
| |
| There will be better suitable authenticated modes available soon |
| For now we are just preparing framework to enable it (and hopefully improve security of FDE). |
| |
| FDE authenticated encryption is not a replacement for filesystem layer |
| authenticated encryption. The goal is to provide at least something because |
| data integrity protection is often completely ignored in today systems. |
| |
| * New memory-hard PBKDF |
| |
| LUKS1 introduced Password-Based Key Derivation Function v2 as a tool to |
| increase attacker cost for a dictionary and brute force attacks. |
| The PBKDF2 uses iteration count to increase time of key derivation. |
| Unfortunately, with modern GPUs, the PBKDF2 calculations can be run |
| in parallel and PBKDF2 can no longer provide the best available protection. |
| Increasing iteration count just cannot prevent massive parallel dictionary |
| password attacks in long-term. |
| |
| To solve this problem, a new PBKDF, based on so-called memory-hard functions |
| can be used. Key derivation with memory-hard function requires a certain |
| amount of memory to compute its output. The memory requirement is very |
| costly for GPUs and prevents these systems to operate ineffectively, |
| increasing cost for attackers. |
| |
| LUKS2 introduces support for Argon2i and Argon2id as a PBKDF. |
| Argon2 is the winner of Password Hashing Competition and is currently |
| in final RFC draft specification. |
| |
| For now, libcryptsetup contains the embedded copy of reference implementation |
| of Argon2 (that is easily portable to all architectures). |
| Later, once this function is available in common crypto libraries, it will |
| switch to external implementation. (This happened for LUKS1 and PBKDF2 |
| as well years ago.) |
| With using reference implementation (that is not optimized for speed), there |
| is some performance penalty. However, using memory-hard PBKDF should still |
| significantly complicate GPU-optimized dictionary and brute force attacks. |
| |
| The Argon2 uses three costs: memory, time (number of iterations) and parallel |
| (number of threads). |
| Note that time and memory cost highly influences each other (accessing a lot |
| of memory takes more time). |
| |
| There is a new benchmark that tries to calculate costs to take similar way as |
| in LUKS1 (where iteration is measured to take 1-2 seconds on user system). |
| Because now there are more cost variables, it prefers time cost (iterations) |
| and tries to find required memory that fits. (IOW required memory cost can be |
| lower if the benchmarks are not able to find required parameters.) |
| The benchmark cannot run too long, so it tries to approximate next step |
| for benchmarking. |
| |
| For now, default LUKS2 PBKDF algorithm is Argon2i (data independent variant) |
| with memory cost set to 128MB, time to 800ms and parallel thread according |
| to available CPU cores but no more than 4. |
| |
| All default parameters can be set during compile time and also set on |
| the command line by using --pbkdf, --pbkdf-memory, --pbkdf-parallel and |
| --iter-time options. |
| (Or without benchmark directly by using --pbkdf-force-iterations, see below.) |
| |
| You can still use PBKDF2 even for LUKS2 by specifying --pbkdf pbkdf2 option. |
| (Then only iteration count is applied.) |
| |
| * Use of kernel keyring |
| |
| Kernel keyring is a storage for sensitive material (like cryptographic keys) |
| inside Linux kernel. |
| |
| LUKS2 uses keyring for two major functions: |
| |
| - To store volume key for dm-crypt where it avoids sending volume key in |
| every device-mapper ioctl structure. Volume key is also no longer directly |
| visible in a dm-crypt mapping table. The key is not available for the user |
| after dm-crypt configuration (obviously except direct memory scan). |
| Use of kernel keyring can be disabled in runtime by --disable-keyring option. |
| |
| - As a tool to automatically unlock LUKS device if a passphrase is put into |
| kernel keyring and proper keyring token is configured. |
| |
| This allows storing a secret (passphrase) to kernel per-user keyring by |
| some external tool (for example some TPM handler) and LUKS2, if configured, |
| will automatically search in the keyring and unlock the system. |
| For more info see Tokens section below. |
| |
| * Persistent flags |
| The activation flags (like allow-discards) can be stored in metadata and used |
| automatically by all later activations (even without using crypttab). |
| |
| To store activation flags permanently, use activation command with required |
| flags and add --persistent option. |
| |
| For example, to mark device to always activate with TRIM enabled, |
| use (for LUKS2 type): |
| |
| $ cryptsetup open <device> <name> --allow-discards --persistent |
| |
| You can check persistent flags in dump command output: |
| |
| $ cryptsetup luksDump <device> |
| |
| * Tokens and auto-activation |
| |
| A LUKS2 token is an object that can be described "how to get passphrase or key" |
| to unlock particular keyslot. |
| (Also it can be used to store any additional metadata, and with |
| the libcryptsetup interface it can be used to define user token types.) |
| |
| Cryptsetup internally implements keyring token. Cryptsetup tries to use |
| available tokens before asking for the passphrase. For keyring token, |
| it means that if the passphrase is available under specified identifier |
| inside kernel keyring, the device is automatically activated using this |
| stored passphrase. |
| |
| Example of using LUKS2 keyring token: |
| |
| # Adding token to metadata with "my_token" identifier (by default it applies to all keyslots). |
| $ cryptsetup token add --key-description "my_token" <device> |
| |
| # Storing passphrase to user keyring (this can be done by an external application) |
| $ echo -n <passphrase> | keyctl padd user my_token @u |
| |
| # Now cryptsetup activates automatically if it finds correct passphrase |
| $ cryptsetup open <device> <name> |
| |
| The main reason to use tokens this way is to separate possible hardware |
| handlers from cryptsetup code. |
| |
| * Keyslot priorities |
| |
| LUKS2 keyslot can have a new priority attribute. |
| The default is "normal". The "prefer" priority tell the keyslot to be tried |
| before other keyslots. Priority "ignore" means that keyslot will never be |
| used if not specified explicitly (it can be used for backup administrator |
| passwords that are used only situations when a user forgets own passphrase). |
| |
| The priority of keyslot can be set with new config command, for example |
| $ cryptsetup config <device> --key-slot 1 --priority prefer |
| |
| Setting priority to normal will reset slot to normal state. |
| |
| * LUKS2 label and subsystem |
| |
| The header now contains additional fields for label and subsystem (additional |
| label). These fields can be used similar to filesystem label and will be |
| visible in udev rules to possible filtering. (Note that blkid do not yet |
| contain the LUKS scanning code). |
| |
| By default both labels are empty. Label and subsystem are always set together |
| (no option means clear the label) with the config command: |
| |
| $ cryptsetup config <device> --label my_device --subsystem "" |
| |
| * In-place conversion form LUKS1 |
| |
| To allow easy testing and transition to the new LUKS2 format, there is a new |
| convert command that allows in-place conversion from the LUKS1 format and, |
| if there are no incompatible options, also conversion back from LUKS2 |
| to LUKS1 format. |
| |
| Note this command can be used only on some LUKS1 devices (some device header |
| sizes are not supported). |
| This command is dangerous, never run it without header backup! |
| If something fails in the middle of conversion (IO error), the header |
| is destroyed. (Note that conversion requires move of keyslot data area to |
| a different offset.) |
| |
| To convert header in-place to LUKS2 format, use |
| $ cryptsetup convert <device> --type luks2 |
| |
| To convert it back to LUKS1 format, use |
| $ cryptsetup convert <device> --type luks1 |
| |
| You can verify LUKS version with luksDump command. |
| $ cryptsetup luksDump <device> |
| |
| Note that some LUKS2 features will make header incompatible with LUKS1 and |
| conversion will be rejected (for example using new Argon2 PBKDF or integrity |
| extensions). Some minor attributes can be lost in conversion. |
| |
| Other changes |
| ~~~~~~~~~~~~~ |
| |
| * Explicit KDF iterations count setting |
| |
| With new PBKDF interface, there is also the possibility to setup PBKDF costs |
| directly, avoiding benchmarks. This can be useful if device is formatted to be |
| primarily used on a different system. |
| |
| The option --pbkdf-force-iterations is available for both LUKS1 and LUKS2 |
| format. Using this option can cause device to have either very low or very |
| high PBKDF costs. |
| In the first case it means bad protection to dictionary attacks, in the second |
| case, it can mean extremely high unlocking time or memory requirements. |
| Use only if you are sure what you are doing! |
| |
| Not that this setting also affects iteration count for the key digest. |
| For LUKS1 iteration count for digest will be approximately 1/8 of requested |
| value, for LUKS2 and "pbkdf2" digest minimal PBKDF2 iteration count (1000) |
| will be used. You cannot set lower iteration count than the internal minimum |
| (1000 for PBKDF2). |
| |
| To format LUKS1 device with forced iteration count (and no benchmarking), use |
| $ cryptsetup luksFormat <device> --pbkdf-force-iterations 22222 |
| |
| For LUKS2 it is always better to specify full settings (do not rely on default |
| cost values). |
| For example, we can set to use Argon2id with iteration cost 5, memory 128000 |
| and parallel set 1: |
| $ cryptsetup luksFormat --type luks2 <device> \ |
| --pbkdf argon2id --pbkdf-force-iterations 5 --pbkdf-memory 128000 --pbkdf-parallel 1 |
| |
| * VeraCrypt PIM |
| |
| Cryptsetup can now also open VeraCrypt device that uses Personal Iteration |
| Multiplier (PIM). PIM is an integer value that user must remember additionally |
| to passphrase and influences PBKDF2 iteration count (without it VeraCrypt uses |
| a fixed number of iterations). |
| |
| To open VeraCrypt device with PIM settings, use --veracrypt-pim (to specify |
| PIM on the command line) or --veracrypt-query-pim to query PIM interactively. |
| |
| * Support for plain64be IV |
| |
| The plain64be is big-endian variant of plain64 Initialization Vector. It is |
| used in some images of hardware-based disk encryption systems. Supporting this |
| variant allows using dm-crypt to map such images through cryptsetup. |
| |
| * Deferral removal |
| |
| Cryptsetup now can mark device for deferred removal by using a new option |
| --deferred. This means that close command will not fail if the device is still |
| in use, but will instruct the kernel to remove the device automatically after |
| use count drops to zero (for example, once the filesystem is unmounted). |
| |
| * A lot of updates to man pages and many minor changes that would make this |
| release notes too long ;-) |
| |
| Libcryptsetup API changes |
| ~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| These API functions were removed, libcryptsetup no longer handles password |
| retries from terminal (application should handle terminal operations itself): |
| crypt_set_password_callback; |
| crypt_set_timeout; |
| crypt_set_password_retry; |
| crypt_set_password_verify; |
| |
| This call is removed (no need to keep typo backward compatibility, |
| the proper function is crypt_set_iteration_time :-) |
| crypt_set_iterarion_time; |
| |
| These calls were removed because are not safe, use per-context |
| error callbacks instead: |
| crypt_last_error; |
| crypt_get_error; |
| |
| The PBKDF benchmark was replaced by a new function that uses new KDF structure |
| crypt_benchmark_kdf; (removed) |
| crypt_benchmark_pbkdf; (new API call) |
| |
| These new calls are now exported, for details see libcryptsetup.h: |
| crypt_keyslot_add_by_key; |
| crypt_keyslot_set_priority; |
| crypt_keyslot_get_priority; |
| |
| crypt_token_json_get; |
| crypt_token_json_set; |
| crypt_token_status; |
| crypt_token_luks2_keyring_get; |
| crypt_token_luks2_keyring_set; |
| crypt_token_assign_keyslot; |
| crypt_token_unassign_keyslot; |
| crypt_token_register; |
| |
| crypt_activate_by_token; |
| crypt_activate_by_keyring; |
| crypt_deactivate_by_name; |
| |
| crypt_metadata_locking; |
| crypt_volume_key_keyring; |
| crypt_get_integrity_info; |
| crypt_get_sector_size; |
| crypt_persistent_flags_set; |
| crypt_persistent_flags_get; |
| crypt_set_pbkdf_type; |
| crypt_get_pbkdf_type; |
| |
| crypt_convert; |
| crypt_keyfile_read; |
| crypt_wipe; |
| |
| Unfinished things & TODO for next releases |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| * There will be better documentation and examples. |
| |
| * There will be some more formal definition of the threat model for integrity |
| protection. (And a link to some papers discussing integrity protection, |
| once it is, hopefully, accepted and published.) |
| |
| * Offline re-encrypt tool LUKS2 support is currently limited. |
| There will be online LUKS2 re-encryption tool in future. |
| |
| * Authenticated encryption will use new algorithms from CAESAR competition |
| (https://competitions.cr.yp.to/caesar.html) once these algorithms are available |
| in kernel (more on this later). |
| NOTE: Currently available authenticated modes (GCM, Chacha20-poly1305) |
| in kernel have too small 96-bit nonces that are problematic with |
| randomly generated IVs (the collison probability is not negligible). |
| For the GCM, nonce collision is a fatal problem. |
| |
| * Authenticated encryption do not set encryption for dm-integrity journal. |
| |
| While it does not influence data confidentiality or integrity protection, |
| an attacker can get some more information from data journal or cause that |
| system will corrupt sectors after journal replay. (That corruption will be |
| detected though.) |
| |
| * Some utilities (blkid, systemd-cryptsetup) have already support for LUKS |
| but not yet in released version (support in crypttab etc). |
| |
| * There are some examples of user-defined tokens inside misc/luks2_keyslot_example |
| directory (like a simple external program that uses libssh to unlock LUKS2 |
| using remote keyfile). |
| |
| * The python binding (pycryptsetup) contains only basic functionality for LUKS1 |
| (it is not updated for new features) and will be deprecated soon in favor |
| of python bindings to libblockdev library (that can already handle LUKS1 devices). |