[dm-crypt] [ANNOUNCE] cryptsetup 2.0.0-rc1

[dm-crypt] [ANNOUNCE] cryptsetup 2.0.0-rc1

[Milan Broz]

[-- Attachment #1.1: Type: text/plain, Size: 27243 bytes --]

The TESTING cryptsetup 2.0.0-rc1 release is available at

    https://gitlab.com/cryptsetup/cryptsetup

Please note that release packages are located on kernel.org

    https://www.kernel.org/pub/linux/utils/cryptsetup/v2.0/

Feedback and bug reports are welcomed.

The latest stable version is still 1.7.5.

Cryptsetup 2.0.0 RC1 Release Notes
==================================
Release candidate 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, noncryptographic
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.
Please do not use it without properly configured backup or in
production systems.

Until final 2.0 version is released, the new LUKS2 format
could still internally change if a major problem is found.

The library API calls (versioned symbols) are now stable and
will not change in an incompatible way.

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-random with hmac-sha256 or hmac-sha512 as the authentication tag.
     (Authentication key for HMAC is independently generated. This mode is very slow.)
     $ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-random --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.

  You can also store only random IV in tag without integrity protection.

  Note that using random IV forces the system to pseudorandomly change the whole
  sector on every write without removing parallel processing of XTS mode.
  In cryptography, we can say that this will provide indistinguishability under
  chosen plaintext attack (IND-CPA) that cannot be achieved in legacy
  FDE systems. On the other side, if stored random IV is corrupted, the sector
  is no longer decrypted properly.

  To use only random IV (no integrity protection), just specify "none" integrity.
  $ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-random --integrity none

  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 paralell 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 RC or future
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* 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 supports only LUKS1 format for now (patches are
 on the way).

* There will be online LUKS2 re-encryption tool in future.

* Authenticated encryption will use new algorithms from CAESAR competition,
  once these algorithms are available in kernel.

* 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) will need small updates to support
  LUKS2 format.

* 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).

  We will document these examples later in release notes for next RC.

* The distribution archive is now very big because of some testing images that do not compress
  well. Some cleaning is needed here.

* A lot of ideas are hidden inside the LUKS2 design that is not yet used or
  described here, let's try if the basics work first :-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] [ANNOUNCE] cryptsetup 2.0.0-rc1

[Geo Kozey]

Hi, I have couple questions about new LUKS2 format.
I hope it's the appropriate place to ask them.

> ----------------------------------------
> From: Milan Broz <gmazyland@gmail.com>
> Sent: Wed Nov 01 10:44:29 CET 2017
> To: dm-crypt <dm-crypt@saout.de>
> Subject: [dm-crypt] [ANNOUNCE] cryptsetup 2.0.0-rc1
> 
> 
>   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.)
> 
What are rough estimates for space overhead of metadata? 0,5%, 5%, 15%?
What are rough estimates for writes overhead of journal? 

How concerns about authenticated encryption with FDE were resolved?
i.e disk sector isn't the same size as cipher block, disk errors, see
https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

> 
>   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-random with hmac-sha256 or hmac-sha512 as the authentication tag.
>      (Authentication key for HMAC is independently generated. This mode is very slow.)
>      $ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-random --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
> 
As (1) and (2) algorithms have serious flaws (speed, nonce reuse) why they are implemented at all?
I think number of supported algorithms isn't an advantage if you can't recommend them for actual usage.
Are there included only for testing and will be removed in stable release?

> 
> * 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.
> 

Keeping encryption keys secret is reasonable however there are some serious issues with using kernel keyring for encryption keys storage as it's not easy to share keys between different users, sessions, threads, etc.
Recently fscrypt developers had problems with using it, see https://www.spinics.net/lists/linux-fscrypt/msg00584.html
I'm not sure if it also affects cryptsetup but it's a good thing to check just in case.

Anyway I'm looking forward for stable release. Great work!

Yours sincerely

G. K.

Re: [dm-crypt] [ANNOUNCE] cryptsetup 2.0.0-rc1

[Ondrej Kozina]

On 11/01/2017 05:25 PM, Geo Kozey wrote:
> Hi, I have couple questions about new LUKS2 format.
> I hope it's the appropriate place to ask them.

Actually the best place for asking questions about cryptsetup/LUKS2 :)

>>    For testing of authenticated encryption, these algorithms work for now:
>>
>>    1) aes-xts-random with hmac-sha256 or hmac-sha512 as the authentication tag.
>>       (Authentication key for HMAC is independently generated. This mode is very slow.)
>>       $ cryptsetup luksFormat --type luks2 <device> --cipher aes-xts-random --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
>>
> As (1) and (2) algorithms have serious flaws (speed, nonce reuse) why they are implemented at all?
> I think number of supported algorithms isn't an advantage if you can't recommend them for actual usage.
> Are there included only for testing and will be removed in stable release?

Milan will probably elaborate on this so just few notes from me:

With exception of (and with rc1 it's also optional) bundled 
implementation of Argon2 pbkdf, libcryptsetup doesn't implement any 
(new) algorithm.

Especially for device-mapper targets and encryption performed in 
dm-crypt we use what's available in kernel already (provided via kernel 
crypto API).

>>
>> * 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.
>>
> 
> Keeping encryption keys secret is reasonable however there are some serious issues with using kernel keyring for encryption keys storage as it's not easy to share keys between different users, sessions, threads, etc.

We don't need to share it currently among processes. What cryptsetup 
2.0.0 does with volume key is this:

1) we load volume key (encryption key) in thread keyring (as type 
'logon' thus unreadable from userspace)
2) while loading dm-crypt mapping we pass key reference (description) 
instead of loading volume key itself in hexbyte representation (as 
cryptsetup did before 2.0.0 release) in dm-crypt table.
3) while in kernel we lookup the key referenced by description and load 
it in crypto layer.
4) as long as dm-crypt mapping is active the key is always in crypto 
layer (unless the device is suspended with key wiped).

IOW we have one less volume key copy in system memory and the key can't 
be exposed accidentally via "dmsetup table" command anymore. Also we're 
going to use kernel keyring more in later LUKS2 features like 
online-reencryption where we need to update dm-crypt mappings frequently.

The second use case when we store user passphrase in kernel keyring 
(tokens): The similar use case is in sysmted-cryptsetup utility for 
activating LUKS devices early during boot. They store the passphrase in 
kernel keyring and later try to activate LUKS volume with that 
passphrase. I haven't seen any severe issue with that so far. But as 
always bug reports are welcome!

> Recently fscrypt developers had problems with using it, see https://www.spinics.net/lists/linux-fscrypt/msg00584.html
> I'm not sure if it also affects cryptsetup but it's a good thing to check just in case.

I believe this is unrelated due to fact that for normal operation (after 
dm-crypt gets activated) the volume key is used exactly the same as 
before. From crypto layer.

Kind regards
Ondrej

Re: [dm-crypt] [ANNOUNCE] cryptsetup 2.0.0-rc1

[Milan Broz]

Hi,

some answers below - I will be probably without access to mail for
a few days so I will answer other questions next week if needed.

On 11/01/2017 05:25 PM, Geo Kozey wrote:
...
> What are rough estimates for space overhead of metadata? 0,5%, 5%, 15%?
> What are rough estimates for writes overhead of journal? 

I wish I can link my paper, unfortunately it is still in review.

Anyway,  this is table from it - metadata per-sector overhead

Metadata [bytes]  Space (512 sector)[%] Space (4k sector)[%]
 4 (32 bits)     0.78                   0.10
16 (128 bits)    3.03                   0.39
28 (224 bits)    5.26                   0.68 
32 (256 bits)    5.88                   0.78
48 (284 bits)    9.09                   1.16
64 (512 bits)   11.11                   1.54
80 (640 bits)   14.29                   1.92

Journal is usually ~100 MB or so per device.

For the performance overhead it is more complicated, but for SSD it is quite
usable. More once I can just put the pdf somewhere...
 
> 
> How concerns about authenticated encryption with FDE were resolved?
> i.e disk sector isn't the same size as cipher block, disk errors, see
> https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

With random IV, actually even XTS (without authenticatoin) mode performs
very well, and you got all properties that are missing.
(Random IV can be stored stored in per-sector metadata.)

IOW every write will pseudoramdomly change the whole sector without
losing XTS internal parallelization.
(XTS was designed to allow internal parallel encryption/decryption
of the blocks - this is not mentioned in the blog IIRC.)

The same applies for all AEAD modes.
And there we ARE authenticating sector data.

...

> As (1) and (2) algorithms have serious flaws (speed, nonce reuse) why they are implemented at all?
> I think number of supported algorithms isn't an advantage if you can't recommend them for actual usage.
> Are there included only for testing and will be removed in stable release?

Yes, more or less it is for testing that it can be really used.

We do not "remove" anything - you can use whatever kernel crypto API provides.
And these are algorithms we have now in kernel - it was used to test that this
idea is usable in reality.

So it is like you can use AES-ECB for FDE - you can use it, but it is stupid.

Once there is something usable (and actually we have student that implements authenticated
algorithms from CAESAR competition for kernel crypto API), perhaps we will go this way.

For the context, why I am doing all of this - please read (preprint) of discussion I had
during SPW2017 workshop (https://www.cl.cam.ac.uk/events/spw2017/)

http://www.fi.muni.cz/~xbroz/spw2017-intro-auth-fde.pdf
(It is in print now, so I hope I can put at least this authored preprint here...)


For the keyring - Ondra can answer this better.
But you can switch it off completely off and use old way of sending key through
dm-ioctl. And if keyring does not work, it need to be fixed (we already
hit several problems).

Milan

Re: [dm-crypt] [ANNOUNCE] cryptsetup 2.0.0-rc1

[Geo Kozey]

Thank you both Ondrej & Milan for the answers you provided. I'll wait for 
publication of Milan paper for further info.

I read in linked conference  material about lack of AE and integrity 
protection in linux filesystems. Meanwhile AE recently landed in linux 
port of ZFS filesystem [1][2].  It's currently based on AES-CCM/GCM.
You probably know that already. I inform you just in case.

[1] https://dqtpg127g2l9y.cloudfront.net/wp-content/uploads/2017/01/zfs-encryption-nov-2016.pdf
[2] https://github.com/zfsonlinux/zfs

Yours sincerely

G. K.