cryptsetup 1.6.0-rc1

WARNING: benchmark requires kernel userspace crypto API to be available (kernel af_alg and algif_skcipher modules, introduced in Linux kernel 2.6.38).

Quoted 3 lines · Milan Broz

WARNING: benchmark requires kernel userspace crypto API to be available (kernel af_alg and algif_skcipher modules, introduced in Linux kernel 2.6.38).

This message doesn't help at all when you have a kernel that doesn't have it enabled and thus you can't find any module by that name. (And you CAN have a kernel with it build in, no module in that case too)

The option for algif_skcipher is:
CONFIG_CRYPTO_USER_API_SKCIPHER
"Cryptographic API" -> "User-space interface for symmetric key cipher algorithms"

The other option (that is responsible for af_alg) is hidden and automatically 'select'ed by activating the option above.

Quoted 13 lines · Matthias Schniedermeyer

Quoted 3 lines · Milan Broz

WARNING: benchmark requires kernel userspace crypto API to be available (kernel af_alg and algif_skcipher modules, introduced in Linux kernel 2.6.38).

This message doesn't help at all when you have a kernel that doesn't have it enabled and thus you can't find any module by that name. (And you CAN have a kernel with it build in, no module in that case too)

The option for algif_skcipher is:
CONFIG_CRYPTO_USER_API_SKCIPHER
"Cryptographic API" -> "User-space interface for symmetric key cipher algorithms"

Quoted 2 lines

The other option (that is responsible for af_alg) is hidden and automatically 'select'ed by activating the option above.

I am not sure if it was this way in previous kernels (skcipher was added later, IIRC first was only hash API)
Anyway, I'll fix description in final release here.

   EXAMPLE:
     # cryptsetup benchmark
     # Tests are approximate using memory only (no storage IO).
     PBKDF2-sha1       111077 iterations per second
     PBKDF2-sha256      53718 iterations per second
     PBKDF2-sha512      18832 iterations per second
     PBKDF2-ripemd160   89775 iterations per second
     PBKDF2-whirlpool   23918 iterations per second
     #  Algorithm | Key | Encryption | Decryption
          aes-cbc   128b  212.0 MiB/s  428.0 MiB/s
      serpent-cbc   128b   23.1 MiB/s   66.0 MiB/s
      twofish-cbc   128b   46.1 MiB/s   50.5 MiB/s
          aes-cbc   256b  163.0 MiB/s  350.0 MiB/s
      serpent-cbc   256b   23.1 MiB/s   66.0 MiB/s
      twofish-cbc   256b   47.0 MiB/s   50.0 MiB/s

          aes-xts   256b  190.0 MiB/s  190.0 MiB/s
      serpent-xts   256b   58.4 MiB/s   58.0 MiB/s
      twofish-xts   256b   49.0 MiB/s   49.5 MiB/s
          aes-xts   512b  175.0 MiB/s  175.0 MiB/s
      serpent-xts   512b   59.0 MiB/s   58.0 MiB/s
      twofish-xts   512b   48.5 MiB/s   49.5 MiB/s

     (Note for example AES-NI decryption optimization effect in example above.)

Are you sure (about AES-NI)?

Quoted 1 line · Matthias Schniedermeyer

Are you sure (about AES-NI)?

I meant difference in ecryption/decryption speed, not real numbers (it was an example from virtual machine and in 32bit mode in fact).

Yes, speed should be much higher on recent systems.

At least it motivates people to try it :)

When you are playing with it: you can try to unload/blackist various kernel modules (aesni_intel, aes_x86_64, ...) and check difference.

Btw. The encryption & decryption columns need to be 1 char wider, the aesni-numbers are too big. ;-)

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)
====================================

Changes since version 1.5.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Important changes
~~~~~~~~~~~~~~~~~

* Cryptsetup and libcryptsetup is now released under GPLv2+ (GPL version 2 or any later).
Some internal code handling files (loopaes, verity, tcrypt and crypto backend wrapper) are LGPLv2+.

Previously code was GPL version 2 only.

* Introducing new unified command open and close.

   Example:
      cryptsetup open --type plain|luks|loopaes|tcrypt <device> <name>
      (type defaults to luks)

with backward-compatible aliases plainOpen, luksOpen, loopaesOpen, tcryptOpen. Basically "open --type xyz" has alias "xyzOpen".

The "create" command (plain device create) is DEPRECATED but will be still supported.
(This command is confusing because of switched arguments order.)

The close command is generic command to remove mapping and have backward compatible aliases (remove, luksClose, ...) which behaves exactly the same.

While all old syntax is still supported, I strongly suggest to use new command syntax which is common for all device types (and possible new formats added in future).

* cryptsetup now support directly TCRYPT (TrueCrypt and compatible tc-play) on-disk format
(Code is independent implementation not related to original project).

Only dump (tcryptDump command) and activation (open --type tcrypt or tcryptOpen) of TCRYPT device are supported. No header changes are supported.

It is intended to easily access containers shared with other operating systems without need to install 3rd party software. For native Linux installations LUKS is the preferred format.

WARNING: TCRYPT extension requires kernel userspace crypto API to be available (kernel af_alg and algif_skcipher modules, introduced in Linux kernel 2.6.38).

Because TCRYPT header is encrypted, you have to always provide valid passphrase and keyfiles. Keyfiles are handled exactly the same as in original format (basically, first 1MB of every keyfile is mixed using CRC32 into pool).

Cryptsetup should recognize all TCRYPT header variants ever released, except legacy cipher chains using LRW encryption mode with 64 bits encryption block (namely Blowfish in LRW mode is not recognized, this is limitation of kernel crypto API).

Device activation is supported only for LRW/XTS modes (again, limitation of kernel dmcrypt which do not implements TCRYPT extensions to CBC mode). (So old containers cannot be activated, but you can use libcryptsetup for lost password search, example of such code is included in misc directory.)

Hidden header are supported using --tcrypt-hidden option, system encryption using --tcrypt-system option.

For detailed description see man page.

EXAMPLE:
* Dump device parameters of container in file:

# cryptsetup tcryptDump tst
Enter passphrase:

TCRYPT header information for tst
Version: 5
Driver req.: 7
Sector size: 512
MK offset: 131072
PBKDF2 hash: sha512
Cipher chain: serpent-twofish-aes
Cipher mode: xts-plain64
MK bits: 1536

You can also dump master key using --dump-master-key. Dump does not require superuser privilege.

* Activation of this container

# cryptsetup tcryptOpen tst tcrypt_dev
Enter passphrase:
(Chain of dmcrypt devices is activated as /dev/mapper/tcrypt_dev.)

* See status of active TCRYPT device

# cryptsetup status tcrypt_dev

/dev/mapper/tcrypt_dev is active.
type: TCRYPT
cipher: serpent-twofish-aes-xts-plain64
keysize: 1536 bits
device: /dev/loop0
loop: /tmp/tst
offset: 256 sectors
size: 65024 sectors
skipped: 256 sectors
mode: read/write

* And plaintext filesystem now ready to mount

# blkid /dev/mapper/tcrypt_dev
/dev/mapper/tcrypt_dev: SEC_TYPE="msdos" UUID="9F33-2954" TYPE="vfat"

* Add (optional) support for lipwquality for new LUKS passwords.

If password is entered through terminal (no keyfile specified) and cryptsetup is compiled with --enable-pwquality, default system pwquality settings are used to check password quality.

You can always override this check by using new --force-password option.

For more info about pwquality project see http://libpwquality.fedorahosted.org/

* Proper handle interrupt signals (ctrl+c and TERM signal) in tools

Code should now handle interrupt properly, release and explicitly wipe in-memory key materials on interrupt.
(Direct users of libcryptsetup should always call crypt_free() when code is interrupted to wipe all resources. There is no signal handling in library, it is up to the tool using it.)

* Add new benchmark command

The "benchmark" command now tries to benchmark PBKDF2 and some block cipher variants. You can specify you own parameters (--cipher/--key-size for block ciphers, --hash for PBKDF2).

See man page for detailed description.

WARNING: benchmark requires kernel userspace crypto API to be available (kernel af_alg and algif_skcipher modules, introduced in Linux kernel 2.6.38).

EXAMPLE:

     # cryptsetup benchmark
     # Tests are approximate using memory only (no storage IO).
     PBKDF2-sha1       111077 iterations per second
     PBKDF2-sha256      53718 iterations per second
     PBKDF2-sha512      18832 iterations per second
     PBKDF2-ripemd160   89775 iterations per second
     PBKDF2-whirlpool   23918 iterations per second
     #  Algorithm | Key | Encryption | Decryption
          aes-cbc   128b  212.0 MiB/s  428.0 MiB/s
      serpent-cbc   128b   23.1 MiB/s   66.0 MiB/s
      twofish-cbc   128b   46.1 MiB/s   50.5 MiB/s
          aes-cbc   256b  163.0 MiB/s  350.0 MiB/s
      serpent-cbc   256b   23.1 MiB/s   66.0 MiB/s
      twofish-cbc   256b   47.0 MiB/s   50.0 MiB/s
          aes-xts   256b  190.0 MiB/s  190.0 MiB/s
      serpent-xts   256b   58.4 MiB/s   58.0 MiB/s
      twofish-xts   256b   49.0 MiB/s   49.5 MiB/s
          aes-xts   512b  175.0 MiB/s  175.0 MiB/s
      serpent-xts   512b   59.0 MiB/s   58.0 MiB/s
      twofish-xts   512b   48.5 MiB/s   49.5 MiB/s

Or you can specify cipher yourself:
# cryptsetup benchmark --cipher cast5-cbc-essiv:sha256 -s 128 # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption
cast5-cbc 128b 32.4 MiB/s 35.0 MiB/s

WARNING: these tests do not use dmcrypt, only crypto API.
You have to benchmark the whole device stack and you can get completely different results. But is is usable for basic comparison. (Note for example AES-NI decryption optimization effect in example above.)

Features
~~~~~~~~

* Do not maintain ChangeLog file anymore, see git log for detailed changes, e.g. here http://code.google.com/p/cryptsetup/source/list

* Move change key into library, add crypt_keyslot_change_by_passphrase(). This change is useful mainly in FIPS mode, where we cannot extract volume key directly from libcryptsetup.

* Add verbose messages during reencryption.

* Default LUKS PBKDF2 iteration time is now configurable.

* Add simple cipher benchmarking API.

* Add kernel skcipher backend.

* Add CRC32 implementation (for TCRYPT).

* Move PBKDF2 into crypto backend wrapper.
This allows use it in other formats, use library implementations and also possible use of different KDF function in future.

* New PBKDF2 benchmark using getrusage().

Fixes
~~~~~

* Avoid O_DIRECT open if underlying storage doesn't support it.

* Fix some non-translated messages.

* Fix regression in header backup (1.5.1) with container in file.

* Fix blockwise read/write for end writes near end of device. (was not used in previous versions)

* Ignore setpriority failure.

* Code changes to fix/ignore problems found by Coverity static analysis, including
- Get page size should never fail.
- Fix time of check/use (TOCTOU test) in tools
- Fix time of check/use in loop/wipe utils.
- Fix time of check/use in device utils.

* Disallow header restore if context is non-LUKS device.
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Hmm. Fails to build because it does not find linux/if_alg.h This is on Debian with a self-compiled 3.4.19. I suspect some link to the kernel-headers is missing. Can anybody tell me what I should link where? Kernel dir is linked to /usr/src/linux as traditional.

Arno

Quoted 264 lines · Milan Broz

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)
====================================

Changes since version 1.5.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Important changes
~~~~~~~~~~~~~~~~~

* Cryptsetup and libcryptsetup is now released under GPLv2+ (GPL version 2 or any later).
Some internal code handling files (loopaes, verity, tcrypt and crypto backend wrapper) are LGPLv2+.

Previously code was GPL version 2 only.

* Introducing new unified command open and close.

   Example:
      cryptsetup open --type plain|luks|loopaes|tcrypt <device> <name>
      (type defaults to luks)

with backward-compatible aliases plainOpen, luksOpen, loopaesOpen, tcryptOpen. Basically "open --type xyz" has alias "xyzOpen".

The "create" command (plain device create) is DEPRECATED but will be still supported.
(This command is confusing because of switched arguments order.)

The close command is generic command to remove mapping and have backward compatible aliases (remove, luksClose, ...) which behaves exactly the same.

While all old syntax is still supported, I strongly suggest to use new command syntax which is common for all device types (and possible new formats added in future).

* cryptsetup now support directly TCRYPT (TrueCrypt and compatible
tc-play)
on-disk format
(Code is independent implementation not related to original project).

Only dump (tcryptDump command) and activation (open --type tcrypt or
tcryptOpen)
of TCRYPT device are supported. No header changes are supported.

It is intended to easily access containers shared with other
operating systems
without need to install 3rd party software. For native Linux
installations LUKS
is the preferred format.

WARNING: TCRYPT extension requires kernel userspace crypto API to
be available
(kernel af_alg and algif_skcipher modules, introduced in Linux kernel
2.6.38).

Because TCRYPT header is encrypted, you have to always provide
valid
passphrase and keyfiles. Keyfiles are handled exactly the same as in
original
format (basically, first 1MB of every keyfile is mixed using CRC32
into pool).

Cryptsetup should recognize all TCRYPT header variants ever released,
except
legacy cipher chains using LRW encryption mode with 64 bits
encryption block
(namely Blowfish in LRW mode is not recognized, this is limitation of
kernel
crypto API).

Device activation is supported only for LRW/XTS modes (again,
limitation
of kernel dmcrypt which do not implements TCRYPT extensions to CBC
mode).
(So old containers cannot be activated, but you can use libcryptsetup for lost password search, example of such code is included in misc
directory.)

Hidden header are supported using --tcrypt-hidden option, system
encryption
using --tcrypt-system option.

For detailed description see man page.

EXAMPLE:
* Dump device parameters of container in file:

# cryptsetup tcryptDump tst
Enter passphrase:

TCRYPT header information for tst
Version: 5
Driver req.: 7
Sector size: 512
MK offset: 131072
PBKDF2 hash: sha512
Cipher chain: serpent-twofish-aes
Cipher mode: xts-plain64
MK bits: 1536

You can also dump master key using --dump-master-key. Dump does not require superuser privilege.

* Activation of this container

# cryptsetup tcryptOpen tst tcrypt_dev
Enter passphrase:
(Chain of dmcrypt devices is activated as /dev/mapper/tcrypt_dev.)

* See status of active TCRYPT device

# cryptsetup status tcrypt_dev

/dev/mapper/tcrypt_dev is active.
type: TCRYPT
cipher: serpent-twofish-aes-xts-plain64
keysize: 1536 bits
device: /dev/loop0
loop: /tmp/tst
offset: 256 sectors
size: 65024 sectors
skipped: 256 sectors
mode: read/write

* And plaintext filesystem now ready to mount

# blkid /dev/mapper/tcrypt_dev /dev/mapper/tcrypt_dev: SEC_TYPE="msdos" UUID="9F33-2954"
TYPE="vfat"

* Add (optional) support for lipwquality for new LUKS passwords.

If password is entered through terminal (no keyfile specified) and cryptsetup is compiled with --enable-pwquality, default system pwquality settings are used to check password quality.

You can always override this check by using new --force-password
option.

For more info about pwquality project see
http://libpwquality.fedorahosted.org/

* Proper handle interrupt signals (ctrl+c and TERM signal) in tools

Code should now handle interrupt properly, release and explicitly
wipe
in-memory key materials on interrupt.
(Direct users of libcryptsetup should always call crypt_free() when code is interrupted to wipe all resources. There is no signal
handling
in library, it is up to the tool using it.)

* Add new benchmark command

The "benchmark" command now tries to benchmark PBKDF2 and some block cipher variants. You can specify you own parameters
(--cipher/--key-size
for block ciphers, --hash for PBKDF2).

See man page for detailed description.

WARNING: benchmark requires kernel userspace crypto API to be
available
(kernel af_alg and algif_skcipher modules, introduced in Linux
kernel 2.6.38).

   EXAMPLE:
     # cryptsetup benchmark
     # Tests are approximate using memory only (no storage IO).
     PBKDF2-sha1       111077 iterations per second
     PBKDF2-sha256      53718 iterations per second
     PBKDF2-sha512      18832 iterations per second
     PBKDF2-ripemd160   89775 iterations per second
     PBKDF2-whirlpool   23918 iterations per second
     #  Algorithm | Key | Encryption | Decryption
          aes-cbc   128b  212.0 MiB/s  428.0 MiB/s
      serpent-cbc   128b   23.1 MiB/s   66.0 MiB/s
      twofish-cbc   128b   46.1 MiB/s   50.5 MiB/s
          aes-cbc   256b  163.0 MiB/s  350.0 MiB/s
      serpent-cbc   256b   23.1 MiB/s   66.0 MiB/s
      twofish-cbc   256b   47.0 MiB/s   50.0 MiB/s
          aes-xts   256b  190.0 MiB/s  190.0 MiB/s
      serpent-xts   256b   58.4 MiB/s   58.0 MiB/s
      twofish-xts   256b   49.0 MiB/s   49.5 MiB/s
          aes-xts   512b  175.0 MiB/s  175.0 MiB/s
      serpent-xts   512b   59.0 MiB/s   58.0 MiB/s
      twofish-xts   512b   48.5 MiB/s   49.5 MiB/s

     Or you can specify cipher yourself:
     # cryptsetup benchmark --cipher cast5-cbc-essiv:sha256 -s 128
     # Tests are approximate using memory only (no storage IO).
     #  Algorithm | Key | Encryption | Decryption
        cast5-cbc   128b   32.4 MiB/s   35.0 MiB/s

     WARNING: these tests do not use dmcrypt, only crypto API.
     You have to benchmark the whole device stack and you can get

completely
different results. But is is usable for basic comparison. (Note for example AES-NI decryption optimization effect in example
above.)

Features
~~~~~~~~

* Do not maintain ChangeLog file anymore, see git log for detailed
changes,
e.g. here http://code.google.com/p/cryptsetup/source/list

* Move change key into library, add
crypt_keyslot_change_by_passphrase().
This change is useful mainly in FIPS mode, where we cannot extract volume key directly from libcryptsetup.

* Add verbose messages during reencryption.

* Default LUKS PBKDF2 iteration time is now configurable.

* Add simple cipher benchmarking API.

* Add kernel skcipher backend.

* Add CRC32 implementation (for TCRYPT).

* Move PBKDF2 into crypto backend wrapper.
This allows use it in other formats, use library implementations and also possible use of different KDF function in future.

* New PBKDF2 benchmark using getrusage().

Fixes
~~~~~

* Avoid O_DIRECT open if underlying storage doesn't support it.

* Fix some non-translated messages.

* Fix regression in header backup (1.5.1) with container in file.

* Fix blockwise read/write for end writes near end of device. (was not used in previous versions)

* Ignore setpriority failure.

* Code changes to fix/ignore problems found by Coverity static
analysis, including
- Get page size should never fail.
- Fix time of check/use (TOCTOU test) in tools
- Fix time of check/use in loop/wipe utils.
- Fix time of check/use in device utils.

Quoted 5 lines

* Disallow header restore if context is non-LUKS device.
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected]
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Hi Arno,

On my sys I have the file /usr/include/linux/if_alg.h in the kernel-headers package (not debian).

And the source file in the kernel is:
/usr/src/linux-3.4.13/include/linux/if_alg.h
or /usr/src/linux/include/linux/if_alg.h for that matter

The question though is, whether your /usr/include/linux is a link or provided by a kernel header package. If it's a proper link you should not run into the problem described.

Hope this helps.

-Sven

Quoted 279 lines · Arno Wagner

Hmm. Fails to build because it does not find linux/if_alg.h This is on Debian with a self-compiled 3.4.19. I suspect some link to the kernel-headers is missing. Can anybody tell me what I should link where? Kernel dir is linked to /usr/src/linux as traditional.

Arno

Quoted 264 lines · Milan Broz

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)
====================================

Changes since version 1.5.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Important changes
~~~~~~~~~~~~~~~~~

* Cryptsetup and libcryptsetup is now released under GPLv2+ (GPL version 2 or any later).
Some internal code handling files (loopaes, verity, tcrypt and crypto backend wrapper) are LGPLv2+.

Previously code was GPL version 2 only.

* Introducing new unified command open and close.

   Example:
      cryptsetup open --type plain|luks|loopaes|tcrypt <device> <name>
      (type defaults to luks)

with backward-compatible aliases plainOpen, luksOpen, loopaesOpen, tcryptOpen. Basically "open --type xyz" has alias "xyzOpen".

The "create" command (plain device create) is DEPRECATED but will be still supported.
(This command is confusing because of switched arguments order.)

The close command is generic command to remove mapping and have backward compatible aliases (remove, luksClose, ...) which behaves exactly the same.

While all old syntax is still supported, I strongly suggest to use new command syntax which is common for all device types (and possible new formats added in future).

* cryptsetup now support directly TCRYPT (TrueCrypt and compatible
tc-play)
on-disk format
(Code is independent implementation not related to original project).

Only dump (tcryptDump command) and activation (open --type tcrypt or
tcryptOpen)
of TCRYPT device are supported. No header changes are supported.

It is intended to easily access containers shared with other
operating systems
without need to install 3rd party software. For native Linux
installations LUKS
is the preferred format.

WARNING: TCRYPT extension requires kernel userspace crypto API to
be available
(kernel af_alg and algif_skcipher modules, introduced in Linux kernel
2.6.38).

Because TCRYPT header is encrypted, you have to always provide
valid
passphrase and keyfiles. Keyfiles are handled exactly the same as in
original
format (basically, first 1MB of every keyfile is mixed using CRC32
into pool).

Cryptsetup should recognize all TCRYPT header variants ever released,
except
legacy cipher chains using LRW encryption mode with 64 bits
encryption block
(namely Blowfish in LRW mode is not recognized, this is limitation of
kernel
crypto API).

Device activation is supported only for LRW/XTS modes (again,
limitation
of kernel dmcrypt which do not implements TCRYPT extensions to CBC
mode).
(So old containers cannot be activated, but you can use libcryptsetup for lost password search, example of such code is included in misc
directory.)

Hidden header are supported using --tcrypt-hidden option, system
encryption
using --tcrypt-system option.

For detailed description see man page.

EXAMPLE:
* Dump device parameters of container in file:

# cryptsetup tcryptDump tst
Enter passphrase:

TCRYPT header information for tst
Version: 5
Driver req.: 7
Sector size: 512
MK offset: 131072
PBKDF2 hash: sha512
Cipher chain: serpent-twofish-aes
Cipher mode: xts-plain64
MK bits: 1536

You can also dump master key using --dump-master-key. Dump does not require superuser privilege.

* Activation of this container

# cryptsetup tcryptOpen tst tcrypt_dev
Enter passphrase:
(Chain of dmcrypt devices is activated as /dev/mapper/tcrypt_dev.)

* See status of active TCRYPT device

# cryptsetup status tcrypt_dev

/dev/mapper/tcrypt_dev is active.
type: TCRYPT
cipher: serpent-twofish-aes-xts-plain64
keysize: 1536 bits
device: /dev/loop0
loop: /tmp/tst
offset: 256 sectors
size: 65024 sectors
skipped: 256 sectors
mode: read/write

* And plaintext filesystem now ready to mount

# blkid /dev/mapper/tcrypt_dev /dev/mapper/tcrypt_dev: SEC_TYPE="msdos" UUID="9F33-2954"
TYPE="vfat"

* Add (optional) support for lipwquality for new LUKS passwords.

If password is entered through terminal (no keyfile specified) and cryptsetup is compiled with --enable-pwquality, default system pwquality settings are used to check password quality.

You can always override this check by using new --force-password
option.

For more info about pwquality project see
http://libpwquality.fedorahosted.org/

* Proper handle interrupt signals (ctrl+c and TERM signal) in tools

Code should now handle interrupt properly, release and explicitly
wipe
in-memory key materials on interrupt.
(Direct users of libcryptsetup should always call crypt_free() when code is interrupted to wipe all resources. There is no signal
handling
in library, it is up to the tool using it.)

* Add new benchmark command

The "benchmark" command now tries to benchmark PBKDF2 and some block cipher variants. You can specify you own parameters
(--cipher/--key-size
for block ciphers, --hash for PBKDF2).

See man page for detailed description.

WARNING: benchmark requires kernel userspace crypto API to be
available
(kernel af_alg and algif_skcipher modules, introduced in Linux
kernel 2.6.38).

   EXAMPLE:
     # cryptsetup benchmark
     # Tests are approximate using memory only (no storage IO).
     PBKDF2-sha1       111077 iterations per second
     PBKDF2-sha256      53718 iterations per second
     PBKDF2-sha512      18832 iterations per second
     PBKDF2-ripemd160   89775 iterations per second
     PBKDF2-whirlpool   23918 iterations per second
     #  Algorithm | Key | Encryption | Decryption
          aes-cbc   128b  212.0 MiB/s  428.0 MiB/s
      serpent-cbc   128b   23.1 MiB/s   66.0 MiB/s
      twofish-cbc   128b   46.1 MiB/s   50.5 MiB/s
          aes-cbc   256b  163.0 MiB/s  350.0 MiB/s
      serpent-cbc   256b   23.1 MiB/s   66.0 MiB/s
      twofish-cbc   256b   47.0 MiB/s   50.0 MiB/s
          aes-xts   256b  190.0 MiB/s  190.0 MiB/s
      serpent-xts   256b   58.4 MiB/s   58.0 MiB/s
      twofish-xts   256b   49.0 MiB/s   49.5 MiB/s
          aes-xts   512b  175.0 MiB/s  175.0 MiB/s
      serpent-xts   512b   59.0 MiB/s   58.0 MiB/s
      twofish-xts   512b   48.5 MiB/s   49.5 MiB/s

     Or you can specify cipher yourself:
     # cryptsetup benchmark --cipher cast5-cbc-essiv:sha256 -s 128
     # Tests are approximate using memory only (no storage IO).
     #  Algorithm | Key | Encryption | Decryption
        cast5-cbc   128b   32.4 MiB/s   35.0 MiB/s

     WARNING: these tests do not use dmcrypt, only crypto API.
     You have to benchmark the whole device stack and you can get

completely
different results. But is is usable for basic comparison. (Note for example AES-NI decryption optimization effect in example
above.)

Features
~~~~~~~~

* Do not maintain ChangeLog file anymore, see git log for detailed
changes,
e.g. here http://code.google.com/p/cryptsetup/source/list

* Move change key into library, add
crypt_keyslot_change_by_passphrase().
This change is useful mainly in FIPS mode, where we cannot extract volume key directly from libcryptsetup.

* Add verbose messages during reencryption.

* Default LUKS PBKDF2 iteration time is now configurable.

* Add simple cipher benchmarking API.

* Add kernel skcipher backend.

* Add CRC32 implementation (for TCRYPT).

* Move PBKDF2 into crypto backend wrapper.
This allows use it in other formats, use library implementations and also possible use of different KDF function in future.

* New PBKDF2 benchmark using getrusage().

Fixes
~~~~~

* Avoid O_DIRECT open if underlying storage doesn't support it.

* Fix some non-translated messages.

* Fix regression in header backup (1.5.1) with container in file.

* Fix blockwise read/write for end writes near end of device. (was not used in previous versions)

* Ignore setpriority failure.

* Code changes to fix/ignore problems found by Coverity static
analysis, including
- Get page size should never fail.
- Fix time of check/use (TOCTOU test) in tools
- Fix time of check/use in loop/wipe utils.
- Fix time of check/use in device utils.

Quoted 5 lines

* Disallow header restore if context is non-LUKS device.
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Quoted 13 lines

--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected]
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Milan: I think presence of if_alg.h should be verified in the configure script, possibly with a brief explanation what the problem is on fail. The compile-error is a bit obscure.

One error on make-check: "lsblk: command not found" => UUID check failed.
Seems lsblk is not available on Debian squeeze. It is in wheezy though, so that should fix itself with a bit of time..

Quoted 3 lines · Arno Wagner

Milan: I think presence of if_alg.h should be verified in the configure script, possibly with a brief explanation what the problem is on fail. The compile-error is a bit obscure.

TBH, I completely forgot to add this... :)

Committed to git - by default configure fails with
...
checking linux/if_alg.h usability... no
checking linux/if_alg.h presence... no
checking for linux/if_alg.h... no
configure: error: You need Linux kernel headers with userspace crypto interface. (Or use --disable-kernel_crypto.)

The switch --disable-kernel_crypto completely removes support, so you can compile it with old kernel or without kernel headers. (But no cipher benchmark and no tcrypt will be available.)

Quoted 3 lines · Milan Broz

The switch --disable-kernel_crypto completely removes support, so you can compile it with old kernel or without kernel headers. (But no cipher benchmark and no tcrypt will be available.)

Is this really the proper fix? Usually, userland needing headers more recent than what's in linux-libc-dev should embed them, and correctly handle at runtime if the interfaces are available.

What happens here if cryptsetup is built on a recent enough kernel where the header is present, and then run on an old kernel? Will it fail gracefully?

Quoted 1 line

Is this really the proper fix? Usually, userland needing headers

more

Quoted 1 line

recent than what's in linux-libc-dev should embed them, and

correctly

Quoted 1 line

handle at runtime if the interfaces are available.

These are two separate problems
- you need to compile it on system where new header/kernel is not available
- you need to detect that current kernel is not able to use userspace crypto API interface (this includes missing module etc.)

Both should be handled already.

Quoted 1 line

What happens here if cryptsetup is built on a recent enough kernel

where

Quoted 2 lines

the header is present, and then run on an old kernel? Will it fail gracefully?

It should print something like
...
Required kernel crypto interface not available. Ensure you have algif_skcipher kernel module loaded.

Quoted 15 lines · Milan Broz

Quoted 1 line

Is this really the proper fix? Usually, userland needing headers

more

Quoted 1 line

recent than what's in linux-libc-dev should embed them, and

correctly

Quoted 1 line

handle at runtime if the interfaces are available.

These are two separate problems
- you need to compile it on system where new header/kernel is not available
- you need to detect that current kernel is not able to use userspace crypto API interface (this includes missing module etc.)

Both should be handled already.

Quoted 1 line

What happens here if cryptsetup is built on a recent enough kernel

Quoted 8 lines

where

Quoted 2 lines

the header is present, and then run on an old kernel? Will it fail gracefully?

It should print something like
...
Required kernel crypto interface not available. Ensure you have algif_skcipher kernel module loaded.

Good. And what happens if cryptsetup is built on an old box not having recent enough headers (typically a buildd) but is run on a box with recent kernels? I guess there's no support, while, when headers are embedded, they would be available.

Quoted 15 lines · Milan Broz

Quoted 1 line

Is this really the proper fix? Usually, userland needing headers

more

Quoted 1 line

recent than what's in linux-libc-dev should embed them, and

correctly

Quoted 1 line

handle at runtime if the interfaces are available.

These are two separate problems
- you need to compile it on system where new header/kernel is not available
- you need to detect that current kernel is not able to use userspace crypto API interface (this includes missing module etc.)

Both should be handled already.

Quoted 1 line

What happens here if cryptsetup is built on a recent enough kernel

Quoted 8 lines

where

Quoted 2 lines

the header is present, and then run on an old kernel? Will it fail gracefully?

It should print something like
...
Required kernel crypto interface not available. Ensure you have algif_skcipher kernel module loaded.

Good. And what happens if cryptsetup is built on an old box not having recent enough headers (typically a buildd) but is run on a box with recent kernels? I guess there's no support, while, when headers are embedded, they would be available.

Regards,
--
Yves-Alexis

Exactly, when the header is missing, you can hardly compile support in, as the compiler does not know the interface. Putting the header into cryptsetup package is not an option, as it is not part of cryptsetup itself, but merely the kernel and possibly changes from time to time.

Usually, a package describes its dependencies and then the builder's job is to provide an adequate build environment to get the build he wants.

Quoted 7 lines · Sven Eschenberg

Exactly, when the header is missing, you can hardly compile support in, as the compiler does not know the interface. Putting the header into cryptsetup package is not an option, as it is not part of cryptsetup itself, but merely the kernel and possibly changes from time to time.

Usually, a package describes its dependencies and then the builder's job is to provide an adequate build environment to get the build he wants.

Well, it would be nice to have exact bug report if you see some problem, please test current git version.

The --disable-kernel_crypto switch is required only for systems where kernel with userspace crypto API will never be available.

For other systems it is maintainer's job to set up dependences properly (require proper kernel headers).

FYI: you will see this warning (RHEL5, as example of old system)
...
checking for linux/if_alg.h... no
configure: error: You need Linux kernel headers with userspace crypto interface. (Or use --disable-kernel_crypto.)

Here (RHEL5) the only option is to use --disable-kernel_crypto.

Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Exactly, when the header is missing, you can hardly compile support in, as
the compiler does not know the interface. Putting the header into cryptsetup package is not an option, as it is not part of cryptsetup itself, but merely the kernel and possibly changes from time to time.

Yes, that could be it. /usr/include/linux is a directory under Debian and it has stuff in it even if you do not have a kernel-header or kernel package installed. Apparently these files come from the linux-libc-dev package and seems to be a subset (and older) of what is in /usr/src/linux-3.4.19/include/linux/

Quoted 5 lines

Yes, that could be it. /usr/include/linux is a directory under Debian and it has stuff in it even if you do not have a kernel-header or kernel package installed. Apparently these files come from the linux-libc-dev package and seems to be a subset (and older) of what is in /usr/src/linux-3.4.19/include/linux/

And just one more thing, Debian seems not to have even cryptsetup 1.5.x (even in experimental).

Anyone knows what the plans are?

I can help to build testing packages if needed. (I am using Debian myself, I am just not Debian packager yet.)

Jonas, do you have more info about packaging new cryptsetup in Debian?

Hmm. Fails to build because it does not find linux/if_alg.h This is on Debian with a self-compiled 3.4.19. I suspect some link to the kernel-headers is missing. Can anybody tell me what I should link where? Kernel dir is linked to /usr/src/linux as traditional.

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)

Quoted 7 lines · Milan Broz

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)

I am going to do one more important change to final 1.6.0:
change LUKS _default_ cipher to aes-xts-plain64 with 512bits key.

Most of recent disk encryption systems switched already to XTS mode, also it is preferred by standards (and we are using it for very long time in Fedora/RHEL during installations.)

Distro maintainers can always overwrite this during compilation time, and user can use -c aes-cbc-essiv:sha256 -s 256 to old mode always.

Quoted 11 lines · Milan Broz

Quoted 7 lines · Milan Broz

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)

I am going to do one more important change to final 1.6.0:
change LUKS _default_ cipher to aes-xts-plain64 with 512bits key.

512bits Key?

Quoted 1 line

Quoted 6 lines

Most of recent disk encryption systems switched already to XTS mode, also it is preferred by standards (and we are using it for very long time in Fedora/RHEL during installations.)

Distro maintainers can always overwrite this during compilation time, and user can use -c aes-cbc-essiv:sha256 -s 256 to old mode always.

You mean 256bits, don't you?

Quoted 20 lines · Ralf Ramsauer

Quoted 11 lines · Milan Broz

Quoted 7 lines · Milan Broz

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)

I am going to do one more important change to final 1.6.0:
change LUKS _default_ cipher to aes-xts-plain64 with 512bits key.

512bits Key?

Quoted 7 lines

Most of recent disk encryption systems switched already to XTS mode, also it is preferred by standards (and we are using it for very long time in Fedora/RHEL during installations.)

Distro maintainers can always overwrite this during compilation time, and user can use -c aes-cbc-essiv:sha256 -s 256 to old mode always.

Quoted 1 line

You mean 256bits, don't you?

For XTS? No, I meant 512.

XTS uses 2 keys (for tweak and encryption). So with AES and 512bits we will use 2 x AES-256 in fact.
But yes, question is if AES-128 (IOW 2x128 = 256 bits) is not enough here.

(With all know analysis to AES256 I still think it is better
to prefer it to AES128.
But not 100% sure if any problems I missed, that's why I sent this mail :-)

XTS mode has some problems too but I am fairly sure it s still better than CBC today (as default).

People who exactly know what they are doing can
always switch the cipher during format time.
(Or later change it with reencrypt tool).

Milan
p.s.
For people (like me :) who have no easy access to final IEEE documents, here is the XTS draft which is enough to understand XTS block mode.
http://grouper.ieee.org/groups/1619/email/pdf00086.pdf

I think the current state is that in absolute terms AES256 is at least as secure than AES128, but maybe not more so.

Quoted 2 lines · Arno Wagner

I think the current state is that in absolute terms AES256 is at least as secure than AES128, but maybe not more so.

What's behind the "maybe", actually? Are there any serious attacks that can be carried out practically which reduces AES-256 to the strength of AES-128? Or are those weaknesses only of theoretical nature?

Quoted 5 lines · Heinz Diehl

Quoted 2 lines · Arno Wagner

I think the current state is that in absolute terms AES256 is at least as secure than AES128, but maybe not more so.

Quoted 4 lines

What's behind the "maybe", actually? Are there any serious attacks that can be carried out practically which reduces AES-256 to the strength of AES-128? Or are those weaknesses only of theoretical nature?

I think it is about related key attacks

I will better
not try to interpret the papers. There is a nice summary:

http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

Quoted 6 lines · Milan Broz

Quoted 5 lines · Heinz Diehl

Quoted 2 lines · Arno Wagner

I think the current state is that in absolute terms AES256 is at least as secure than AES128, but maybe not more so.

Quoted 6 lines

Quoted 4 lines

What's behind the "maybe", actually? Are there any serious attacks that can be carried out practically which reduces AES-256 to the strength of AES-128? Or are those weaknesses only of theoretical nature?

I think it is about related key attacks

Yes.

Quoted 4 lines

I will better
not try to interpret the papers. There is a nice summary:

http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

Hmm, reading this again, and the discussion comments by Schneier, maybe we should use AES128 as default. AES256 might indeed be somewhat weaker than AES128.

Not that either can be broken at this time.

One idea: With AES256+XTS, the keyslot-area is larger. If somebody wants to re-encrypt AES256+CBC in place, they would need to use AES128+XTS anyways. Correct?

That would be a second reason to use AES128.

Well, things are never simple when security is concerned...

On 01/04/2013 11:05 PM, Arno Wagner wrote:

Quoted 3 lines

Hmm, reading this again, and the discussion comments by Schneier, maybe we should use AES128 as default. AES256 might indeed be somewhat weaker than AES128.

But please note this is from 2009. There are some new recent papers related even to AES128.

To cite the same source...
http://www.schneier.com/blog/archives/2011/08/new_attack_on_a_1.html

Dunno. aes128-xts is perhaps enough (and the keyslot size remains the same).

Quoted 1 line

Quoted 5 lines

Not that either can be broken at this time.

One idea: With AES256+XTS, the keyslot-area is larger. If somebody wants to re-encrypt AES256+CBC in place, they would need to use AES128+XTS anyways. Correct?

reencrypt tool supports data shift, so you just need to add some space or reduce fs in advance. But yes, it is more complicated.

Quoted 3 lines

That would be a second reason to use AES128.

Well, things are never simple when security is concerned...

I think there is only one simple situation in cryptography... Once is something broken, it remains broken forever :-)

What does RHEL use and recommend? Do they always use AES256-XTS or is AES128-XTS offered as an option (not when douing this manually via commandline). I think there would be some benefit to have the same defauls in distro-independent cryptsetup.

Quoted 5 lines · Arno Wagner

What does RHEL use and recommend? Do they always use AES256-XTS or is AES128-XTS offered as an option (not when douing this manually via commandline). I think there would be some benefit to have the same defauls in distro-independent cryptsetup.

- Encrypted disk installation is using AES-XTS with 512bit key. (installer overwrites default. But I know there was no real discussion about AES18/256 before this was changed.)

Installed (anaconda) doesn't allow default cipher/key size change but allows to "reuse" existing LUKS device.

- compiled-in cryptsetup default is the same as upstream (CBC with ESSIV) (RHEL7 will use XTS as default, I would like to see the same default as upstream.)
(This was mainly for compatibility reasons but now even RHEL5 can map XTS LUKS discs.)

- RHEL in FIPS mode (dmcrypt/LUKS module is still not validated though) allows CBC (only with ESSIV) and XTS with AES128/192/256

Well, I can get more info from independent people here internally.

My current opinion is to use aes-xts-plain64 with 256bit key (IOW use AES128) as independent default for LUKS.

Any serious objections to not do that now?

Quoted 4 lines · Milan Broz

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Quoted 3 lines

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)

I am going to do one more important change to final 1.6.0:
change LUKS _default_ cipher to aes-xts-plain64 with 512bits key.

Most of recent disk encryption systems switched already to XTS mode, also it is preferred by standards (and we are using it for very long time in Fedora/RHEL during installations.)

Distro maintainers can always overwrite this during compilation time, and user can use -c aes-cbc-essiv:sha256 -s 256 to old mode always.

(Plain mode have to stay with CBC, change would cause compatibility problems.)

Any serious objections to not do that now?

Milan
_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt

Quoted 7 lines · Milan Broz

The testing release candidate cryptsetup 1.6.0-rc1 is available at

http://code.google.com/p/cryptsetup/

Feedback and bug reports are welcomed.

Cryptsetup 1.6.0 Release Notes (RC1)

I am going to do one more important change to final 1.6.0:
change LUKS _default_ cipher to aes-xts-plain64 with 512bits key.

Most of recent disk encryption systems switched already to XTS mode, also it is preferred by standards (and we are using it for very long time in Fedora/RHEL during installations.)

Any serious objections to not do that now?

Quoted 1 line · Milan Broz

Any serious objections to not do that now?

How does it compare to cbc in terms of (real-world) performance?

Quoted 5 lines · Romain Francoise

Quoted 1 line · Milan Broz

Any serious objections to not do that now?

How does it compare to cbc in terms of (real-world) performance?

It is slower but on recent systems it shouldn't not be bottleneck (even with fast storage).

I really prefer security to performance here.

But anyway, there is now benchmark command to test it.

An example (on my 3 year old Thinkpad x201 notebook with AES-NI):

# Tests are approximate using memory only (no storage IO).

#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   789.0 MiB/s  1899.0 MiB/s
     aes-cbc   256b   595.0 MiB/s  1445.0 MiB/s
     aes-xts   256b   572.0 MiB/s   571.4 MiB/s
     aes-xts   512b   465.0 MiB/s   467.0 MiB/s

(I think XTS got some more optimization in recent kernel, this is from 3.6.)

You can try it yourself, just run "cryptsetup benchmark" with 1.6.0-rc1, perhaps we will need some new FAQ entry here.