HOME

Mini Shell 1.0
DIR:/proc/self/root/usr/share/doc/cryptsetup-2.0.3/
Current File : //proc/self/root/usr/share/doc/cryptsetup-2.0.3/v1.4.3-ReleaseNotes
Cryptsetup 1.4.3 Release Notes
==============================

Changes since version 1.4.2

* Fix readonly activation if underlying device is readonly (1.4.0).

* Fix loop mapping on readonly file.

* Include stddef.h in libdevmapper.h (size_t definition).

* Fix keyslot removal for device with 4k hw block (1.4.0).
(Wipe keyslot failed in this case.)

* Relax --shared flag to allow mapping even for overlapping segments.

  The --shared flag (and API CRYPT_ACTIVATE_SHARED flag) is now able
  to map arbitrary overlapping area. From API it is even usable
  for LUKS devices.
  It is user responsibility to not cause data corruption though.

  This allows e.g. scubed to work again and also allows some
  tricky extensions later.

* Allow empty cipher (cipher_null) for testing.

  You can now use "null" (or directly cipher_null-ecb) in cryptsetup.
  This means no encryption, useful for performance tests
  (measure dm-crypt layer overhead).

* Switch on retry on device remove for libdevmapper.
  Device-mapper now retry removal if device is busy.

* Allow "private" activation (skip some udev global rules) flag.
  Cryptsetup library API now allows to specify CRYPT_ACTIVATE_PRIVATE,
  which means that some udev rules are not processed.
  (Used for temporary devices, like internal keyslot mappings where
  it is not desirable to run any device scans.)

* This release also includes some Red Hat/Fedora specific extensions
related to FIPS140-2 compliance.

In fact, all these patches are more formal changes and are just subset
of building blocks for FIPS certification. See FAQ for more details
about FIPS.

FIPS extensions are enabled by using --enable-fips configure switch.

In FIPS mode (kernel booted with fips=1 and gcrypt in FIPS mode)

  - it provides library and binary integrity verification using
  libfipscheck (requires pre-generated checksums)

  - it uses FIPS approved RNG for encryption key and salt generation
  (note that using /dev/random is not formally FIPS compliant RNG).

 - only gcrypt crypto backend is currently supported in FIPS mode.

The FIPS RNG requirement for salt comes from NIST SP 800-132 recommendation.
(Recommendation for Password-Based Key Derivation. Part 1: Storage Applications.
http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf)
LUKS should be aligned to this recommendation otherwise.