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

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

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

 * Disallow header restore if context is non-LUKS device.

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

[Matthias Schniedermeyer]

On 29.12.2012 22:40, Milan Broz wrote:
> 
>    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.




-- 

Matthias

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

[Milan Broz]

On 12/29/2012 11:24 PM, Matthias Schniedermeyer wrote:
> On 29.12.2012 22:40, Milan Broz wrote:
>>
>>    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.

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.

Thanks,
Milan

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

[Matthias Schniedermeyer]

On 29.12.2012 22:40, Milan Broz wrote:
> 
>    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)?
I get slightly higher values:

Tested with a self-compiled vanilla 3.7.1 kernel.

Core i7 3770 (Ivy Bridge), 4 cores, HT, no overclocking:
PBKDF2-sha1       393609 iterations per second
PBKDF2-sha256     257003 iterations per second
PBKDF2-sha512      91915 iterations per second
PBKDF2-ripemd160  386073 iterations per second
PBKDF2-whirlpool  154748 iterations per second
#  Algorithm | Key | Encryption | Decryption
     aes-cbc   128b  671.0 MiB/s  2483.0 MiB/s
 serpent-cbc   128b   98.3 MiB/s  320.4 MiB/s
 twofish-cbc   128b  205.0 MiB/s  377.6 MiB/s
     aes-cbc   256b  492.0 MiB/s  1816.0 MiB/s
 serpent-cbc   256b   98.3 MiB/s  319.4 MiB/s
 twofish-cbc   256b  204.4 MiB/s  375.6 MiB/s
     aes-xts   256b  1237.0 MiB/s  1252.0 MiB/s
 serpent-xts   256b  306.7 MiB/s  291.4 MiB/s
 twofish-xts   256b  336.7 MiB/s  338.3 MiB/s
     aes-xts   512b  1065.0 MiB/s  1076.0 MiB/s
 serpent-xts   512b  309.4 MiB/s  293.0 MiB/s
 twofish-xts   512b  336.7 MiB/s  337.7 MiB/s

Even my 2.5 years old low-spec first-generation (for AES-NI) machine 
gets slightly better results:
Core i5 650 (Westmere/Clarkdale), 2 cores, no HT, no overlocking:
PBKDF2-sha1       299251 iterations per second
PBKDF2-sha256     175229 iterations per second
PBKDF2-sha512      58409 iterations per second
PBKDF2-ripemd160  283705 iterations per second
PBKDF2-whirlpool   94568 iterations per second
#  Algorithm | Key | Encryption | Decryption
     aes-cbc   128b  711.3 MiB/s  1749.0 MiB/s
 serpent-cbc   128b   67.6 MiB/s  282.7 MiB/s
 twofish-cbc   128b  165.2 MiB/s  227.8 MiB/s
     aes-cbc   256b  540.0 MiB/s  1340.0 MiB/s
 serpent-cbc   256b   68.0 MiB/s  283.4 MiB/s
 twofish-cbc   256b  165.8 MiB/s  227.8 MiB/s
     aes-xts   256b  957.0 MiB/s  952.0 MiB/s
 serpent-xts   256b  243.8 MiB/s  258.0 MiB/s
 twofish-xts   256b  207.8 MiB/s  207.2 MiB/s
     aes-xts   512b  832.2 MiB/s  835.0 MiB/s
 serpent-xts   512b  243.3 MiB/s  257.2 MiB/s
 twofish-xts   512b  208.2 MiB/s  206.8 MiB/s







-- 

Matthias

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

[Matthias Schniedermeyer]

On 29.12.2012 23:42, Milan Broz wrote:
> On 12/29/2012 11:24 PM, Matthias Schniedermeyer wrote:
> > On 29.12.2012 22:40, Milan Broz wrote:
> >>
> >>    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.
> 
> 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.

I haven't checked that, i only 'grep'ed the current 3.7.1 kernel source 
to find out what was missing from my kernel.




-- 

Matthias

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

[Milan Broz]

On 12/30/2012 12:15 AM, Matthias Schniedermeyer wrote:

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

Milan

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

[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

On Sat, Dec 29, 2012 at 10:40:44PM +0100, Milan Broz wrote:
> 
> 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
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

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

[Sven Eschenberg]

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

On Sun, December 30, 2012 09:38, Arno Wagner wrote:
> 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
>
> On Sat, Dec 29, 2012 at 10:40:44PM +0100, Milan Broz wrote:
>>
>> 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
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> 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
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

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

[Milan Broz]

On 12/30/2012 09:38 AM, Arno Wagner wrote:
> 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.  

Hm. Ok this will need to add test for this, that should not fail
to compile (despite you cannot use new features then).
if_alg is (new) kernel header, so it comes with kernel-headers.

Thanks for report, That's exactly why we have RC1...

Milan

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

[Arno Wagner]

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/

Anyways, moved /usr/include/linux out of the way and linked
/usr/src/linux-3.4.19/include/linux to /usr/include/linux
(via intermediate link to hide kernel version), and 
cryptsetup compiles. 

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

Anyways, good job! I really like the true-crypt stuff, so 
far it was a pain to move anything between Linux and Windows 
(both encrypted) on my laptop.

Arno

On Sun, Dec 30, 2012 at 09:56:20AM +0100, Sven Eschenberg wrote:
> 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
> 
> On Sun, December 30, 2012 09:38, Arno Wagner wrote:
> > 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
> >
> > On Sat, Dec 29, 2012 at 10:40:44PM +0100, Milan Broz wrote:
> >>
> >> 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
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >
> > --
> > Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> > 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
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

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

[Milan Broz]

On 12/30/2012 11:20 AM, Arno Wagner wrote:

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

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

Added requirement for this tool otherwise test is skipped.
(Test are intended for experienced users or distro maintainers only anyway.)

Thanks,
Milan

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

[Milan Broz]

On 12/30/2012 11:20 AM, Arno Wagner wrote:
> 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?

(I built package for Fedora immediately after release, but
Fedora seems to be unusable distro for any "serious" work recently...)

Milan

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

[Matthias Schniedermeyer]

On 30.12.2012 00:31, Milan Broz wrote:
> On 12/30/2012 12:15 AM, Matthias Schniedermeyer wrote:
> 
> > 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.


This was tested on:
Core i7 2600 (Sandy Bridge), 4 cores, HT, no Overclocking
Kernel 3.7.1

First run is with everyting at maxium:
aesni, twofish AVX, serpent AVX:
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       371308 iterations per second
PBKDF2-sha256     215578 iterations per second
PBKDF2-sha512      88204 iterations per second
PBKDF2-ripemd160  355208 iterations per second
PBKDF2-whirlpool  147936 iterations per second
#  Algorithm | Key | Encryption | Decryption
     aes-cbc   128b  633,4 MiB/s  2172,0 MiB/s
 serpent-cbc   128b   80,2 MiB/s  301,7 MiB/s
 twofish-cbc   128b  181,8 MiB/s  336,7 MiB/s
     aes-cbc   256b  457,0 MiB/s  1639,0 MiB/s
 serpent-cbc   256b   78,7 MiB/s  301,0 MiB/s
 twofish-cbc   256b  181,8 MiB/s  332,3 MiB/s
     aes-xts   256b  1149,0 MiB/s  1160,0 MiB/s
 serpent-xts   256b  286,7 MiB/s  279,4 MiB/s
 twofish-xts   256b  298,4 MiB/s  301,4 MiB/s
     aes-xts   512b  1022,0 MiB/s  1020,0 MiB/s
 serpent-xts   512b  294,7 MiB/s  281,4 MiB/s
 twofish-xts   512b  304,0 MiB/s  303,4 MiB/s


Here are the differences after rmmod certain modules:

--- AES ---
aesni_intel:
#  Algorithm | Key | Encryption | Decryption
     aes-cbc   128b  633,4 MiB/s  2172,0 MiB/s
     aes-cbc   256b  457,0 MiB/s  1639,0 MiB/s
     aes-xts   256b  1149,0 MiB/s  1160,0 MiB/s
     aes-xts   512b  1022,0 MiB/s  1020,0 MiB/s

After rmmod aesni_intel:
aes_x86_64:
#  Algorithm | Key | Encryption | Decryption
     aes-cbc   128b  200,4 MiB/s  236,8 MiB/s
     aes-cbc   256b  157,7 MiB/s  178,6 MiB/s
     aes-xts   256b  230,3 MiB/s  231,8 MiB/s
     aes-xts   512b  175,1 MiB/s  175,6 MiB/s

After rmmod aes_x86_64
aes_generic:
#  Algorithm | Key | Encryption | Decryption
     aes-cbc   128b  194,6 MiB/s  228,8 MiB/s
     aes-cbc   256b  154,0 MiB/s  172,7 MiB/s
     aes-xts   256b  232,3 MiB/s  228,0 MiB/s
     aes-xts   512b  175,8 MiB/s  155,0 MiB/s

--- Twofish ---
twofish_avx_x86_64:
#  Algorithm | Key | Encryption | Decryption
 twofish-cbc   128b  181,8 MiB/s  336,7 MiB/s
 twofish-cbc   256b  181,8 MiB/s  332,3 MiB/s
 twofish-xts   256b  298,4 MiB/s  301,4 MiB/s
 twofish-xts   512b  304,0 MiB/s  303,4 MiB/s

After rmmod twofish_avx_x86_64
twofish_x86_64_3way:
#  Algorithm | Key | Encryption | Decryption
 twofish-cbc   128b  179,6 MiB/s  219,0 MiB/s
 twofish-cbc   256b  183,3 MiB/s  223,8 MiB/s
 twofish-xts   256b  207,0 MiB/s  208,6 MiB/s
 twofish-xts   512b  207,6 MiB/s  208,0 MiB/s

After rmmod twofish_x86_64_3way
twofish_x86_64:
#  Algorithm | Key | Encryption | Decryption
 twofish-cbc   128b  151,0 MiB/s  171,7 MiB/s
 twofish-cbc   256b  147,6 MiB/s  171,7 MiB/s
 twofish-xts   256b  170,8 MiB/s  173,1 MiB/s
 twofish-xts   512b  174,7 MiB/s  176,0 MiB/s

After rmmod twofish_x86_64
twofish_generic:
#  Algorithm | Key | Encryption | Decryption
 twofish-cbc   128b  143,6 MiB/s  163,2 MiB/s
 twofish-cbc   256b  144,0 MiB/s  161,4 MiB/s
 twofish-xts   256b  161,4 MiB/s  162,5 MiB/s
 twofish-xts   512b  163,8 MiB/s  162,5 MiB/s


--- Serpent ---
serpent_avx_x86_64:
#  Algorithm | Key | Encryption | Decryption
 serpent-cbc   128b   80,2 MiB/s  301,7 MiB/s
 serpent-cbc   256b   78,7 MiB/s  301,0 MiB/s
 serpent-xts   256b  286,7 MiB/s  279,4 MiB/s
 serpent-xts   512b  294,7 MiB/s  281,4 MiB/s

After rmmod serpent_avx_x86_64:
serpent_sse2_x86_64:
#  Algorithm | Key | Encryption | Decryption
 serpent-cbc   128b   80,7 MiB/s  298,4 MiB/s
 serpent-cbc   256b   80,8 MiB/s  302,7 MiB/s
 serpent-xts   256b  274,5 MiB/s  265,7 MiB/s
 serpent-xts   512b  271,0 MiB/s  273,7 MiB/s

After rmmod serpent_sse2_x86_64
serpent_generic:
#  Algorithm | Key | Encryption | Decryption
 serpent-cbc   128b   74,9 MiB/s   82,8 MiB/s
 serpent-cbc   256b   73,2 MiB/s   79,8 MiB/s
 serpent-xts   256b   78,4 MiB/s   83,2 MiB/s
 serpent-xts   512b   79,8 MiB/s   83,6 MiB/s


With serpent_avx_x86_64 loaded and serpent_sse2_x86_64 removed
#  Algorithm | Key | Encryption | Decryption
 serpent-cbc   128b   80,2 MiB/s  303,4 MiB/s
 serpent-cbc   256b   81,6 MiB/s  306,4 MiB/s
 serpent-xts   256b  289,0 MiB/s  278,7 MiB/s
 serpent-xts   512b  296,0 MiB/s  282,4 MiB/s

Seems the AVX version doesn't make much of a difference compared to the 
SSE version.




And last but not least the other benchmark mentioned:
cast5_avx_x86_64:
#  Algorithm | Key | Encryption | Decryption
   cast5-cbc   128b  103,3 MiB/s  302,0 MiB/s

After rmmod cast5_avx_x86_64
cast5_generic:
#  Algorithm | Key | Encryption | Decryption
   cast5-cbc   128b   95,1 MiB/s  107,5 MiB/s



I didn't average several runs, except for serpent the numbers differ 
enough that the accuracy is good enough(tm).
The few runs i tried had relativly stable numbers.


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




-- 

Matthias

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

[Milan Broz]

On 01/02/2013 01:50 PM, Matthias Schniedermeyer wrote:

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

Fixed :-)

Milan

[dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Milan Broz]

On 12/29/2012 10:40 PM, Milan Broz wrote:
> 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.

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

Any serious objections to not do that now?

Milan

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Ralf Ramsauer]

On 01/04/13 12:50, Milan Broz wrote:
> On 12/29/2012 10:40 PM, Milan Broz wrote:
>> 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?
>
> 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?

-
Ralf

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Milan Broz]

On 01/04/2013 12:53 PM, Ralf Ramsauer wrote:
> On 01/04/13 12:50, Milan Broz wrote:
>> On 12/29/2012 10:40 PM, Milan Broz wrote:
>>> 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?
>>
>> 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?

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

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 145 bytes --]

On Fri, 2013-01-04 at 12:50 +0100, Milan Broz wrote:
> Any serious objections to not do that now?
nope... great idea imho!

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5113 bytes --]

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Arno Wagner]

On Fri, Jan 04, 2013 at 12:50:04PM +0100, Milan Broz wrote:
> On 12/29/2012 10:40 PM, Milan Broz wrote:
> > 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.

I think this is a very good idea.

Arno
 
> 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
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Arno Wagner]

On Fri, Jan 04, 2013 at 01:18:33PM +0100, Milan Broz wrote:
> On 01/04/2013 12:53 PM, Ralf Ramsauer wrote:
> > On 01/04/13 12:50, Milan Broz wrote:
> >> On 12/29/2012 10:40 PM, Milan Broz wrote:
> >>> 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?
> >>
> >> 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?
> 
> 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.

Lets stay with 512bit. A good rule for key-lengths is to
determine what is very likely secure and then use twice that.
 
> (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 :-)

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

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

Indeed. And AFAIK the problems are mostly with large blocks
and do not apply to LUKS as the blocka here are only 512 Bytes.

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

And people that do not know what they are doing are 
free to shoot themselves in the foot by fiddeling with
the defaults too!

I think this change is very low-risk. And as it is the
popular choice, it will see more analysis by the crypto-
community, which means earlier warning should it have
real (practical) problems.

> 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

Hehe, I think I have looked at this one too.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Zdenek Kaspar]

On 01/04/2013 12:50 PM, Milan Broz wrote:
> On 12/29/2012 10:40 PM, Milan Broz wrote:
>> 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.)

+1 for the RHEL6 standard, thx!

Z.

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Romain Francoise]

Milan Broz <gmazyland@gmail.com> writes:

> Any serious objections to not do that now?

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

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Milan Broz]

On 01/04/2013 07:55 PM, Romain Francoise wrote:
> Milan Broz <gmazyland@gmail.com> writes:
> 
>> 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.

Milan

 

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Heinz Diehl]

On 04.01.2013, Arno Wagner wrote: 

> 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?

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Milan Broz]

On 01/04/2013 09:20 PM, Heinz Diehl wrote:
> On 04.01.2013, Arno Wagner wrote: 
> 
>> 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?

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

Milan

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Arno Wagner]

On Fri, Jan 04, 2013 at 08:14:42PM +0100, Milan Broz wrote:
> On 01/04/2013 07:55 PM, Romain Francoise wrote:
> > Milan Broz <gmazyland@gmail.com> writes:
> > 
> >> 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.

Yes, I think so. I will write one.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Arno Wagner]

On Fri, Jan 04, 2013 at 09:56:27PM +0100, Milan Broz wrote:
> On 01/04/2013 09:20 PM, Heinz Diehl wrote:
> > On 04.01.2013, Arno Wagner wrote: 
> > 
> >> 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?
> 
> I think it is about related key attacks

Yes. 

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

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Milan Broz]

On 01/04/2013 11:05 PM, Arno Wagner wrote:
> On Fri, Jan 04, 2013 at 09:56:27PM +0100, Milan Broz wrote:
>> On 01/04/2013 09:20 PM, Heinz Diehl wrote:
>>> On 04.01.2013, Arno Wagner wrote: 
>>>
>>>> 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?
>>
>> I think it is about related key attacks
> 
> Yes. 
> 
>> 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. 

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

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

> 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 :-)

Milan

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Arno Wagner]

On Fri, Jan 04, 2013 at 11:39:43PM +0100, Milan Broz wrote:
> On 01/04/2013 11:05 PM, Arno Wagner wrote:
[...]
> > 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).
> 
> > 
> > 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.

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.
 
I think the security levels of AES128 and AES256 are not
different enough that we should ecide on that alone or
even as main criterium. 

> > 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 :-)

Yes, indeed :-)

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Milan Broz]

On 01/05/2013 06:20 PM, Arno Wagner wrote:

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

Milan

Re: [dm-crypt] Switch to XTS mode for LUKS in cryptsetup in 1.6.0 (Was Re: [ANNOUNCE] cryptsetup 1.6.0-rc1)

[Arno Wagner]

On Sat, Jan 05, 2013 at 07:25:52PM +0100, Milan Broz wrote:
> On 01/05/2013 06:20 PM, Arno Wagner wrote:
> 
> > 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.)

Always nice to know what happens begind the curtains ;-)

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

I think that is probably the best option at the moment.

Arno 
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

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

[Jonas Meurer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Milan,

Am 30.12.2012 12:47, schrieb Milan Broz:
> On 12/30/2012 11:20 AM, Arno Wagner wrote:
>> 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?

Sorry for the long delay. Unfortunately I don't have as much time as
I'd like for Debian maintenance tasks lately.
I didn't package cryptsetup 1.5 yet as Debian Wheezy is already
frozen. Thus it's difficult/impossible to push a new upstream release
with non-security-relevant changes to Wheezy before release. In other
words: Debian Wheezy will be released with cryptsetup 1.4.3, which is
ok in my eyes. My plan is to package cryptsetup 1.6 within the next
few weeks and upload it to unstable/sid.

I'm happy about anyone who wants to join the Debian cryptsetup
Maintenance team and help with packaging/bug squashing/documentation
tasks.

Kind regards,
 jonas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ6IM1AAoJEFJi5/9JEEn+osoP/1qyw/xzKN6xCC1fd89BDZ/P
9VFPBOKnoXJ1sPp5mlKHX5qAzTjFlQCsRfjEnLl2OeaEfQWsAtuBK4llwDp+GZx8
zeQr/js/mNOWgZ03/Sw7P9Ss8de8J0dK9SvAf+tO052o7RoJuE4NN3K03u5OqQ/5
hgY5GZeLS0+uea7IE/rM6u6ORIHR7Mt57fB2GAeiCrB8JgHthHIRBXK6FP7YsTaU
T02ZyR2WIbpQJYGVkLt02CPedFo7Me14TiO8T7h2zbhid9gRPtd3z2Vftly+lsAA
I4FQqTzFXzbKhpjEpJNJlCzllR+T49X6mQcoTPsm3o84LTki+Gf3RLP5Ga63kShf
gpyNNfdvsXG2WC9kWyVAcryDyrkWIico6ObJog9mnqg8iwJlzzkmKxqlCwTQ8uX6
1IuUzDzUfOpab2xA7rLKt+Z6ep3nhgY45gjo1qGWmHFrTygllvAsiEi7LQS6YUAE
+7Slvl8Mu7/vHdbnjZ8GoZbQUacDnHVvKnUifsk83eLF4jItShADpR9FyTzJ02kl
RdXyeHm6+s1yp+fw7sE9amO42fkHH2oOVG2OqYVYPqQ93ZvO6zHOChRjlz04G1Af
x3F6xxBwnbHgAY94vkrN4D7qYs1gFbPneIVQjXDC7dAOoMv6AVTJhvPGHChig2+d
r5BnFFCMVRXsIInbytcz
=IypD
-----END PGP SIGNATURE-----

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

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

On dim., 2012-12-30 at 12:40 +0100, Milan Broz wrote:
> On 12/30/2012 11:20 AM, Arno Wagner wrote:
> 
> > 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.)

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?

Regards,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Milan Broz]

On 01/06/2013 01:16 PM, Yves-Alexis Perez wrote:
> On dim., 2012-12-30 at 12:40 +0100, Milan Broz wrote:

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

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.

> 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?

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

Anyway, I would welcome people test this and report any problems here.
So if you have such system, please try it :)

Milan

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

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

On dim., 2013-01-06 at 17:24 +0100, Milan Broz wrote:
> > 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.
> 
> 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.
> 
> > 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?
> 
> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Milan Broz]

On 01/07/2013 07:23 AM, Yves-Alexis Perez wrote:
> On dim., 2013-01-06 at 17:24 +0100, Milan Broz wrote:
>>> 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.
>>
>> 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.
>>
>>> 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?
>>
>> 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.

The same as above. Kernel crypto api is just new AF_ALG socket interface,
if is is not known to kernel, or the command fails, it should fail
the same way like kernel is compiled without it.

(TBH if is not clear how to properly detect it otherwise than just
try to use it... but that works).

Milan

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

[Sven Eschenberg]

On Mon, January 7, 2013 07:23, Yves-Alexis Perez wrote:
> On dim., 2013-01-06 at 17:24 +0100, Milan Broz wrote:
>> > 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.
>>
>> 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.
>>
>> > 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?
>>
>> 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.

Regards

-Sven

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

[Milan Broz]

On 01/07/2013 12:21 PM, Sven Eschenberg wrote:
> 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

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

[Sven Eschenberg]

Hi Milan,

I think you misunderstood my post.

I merely pointed out, that the way the current build handles things is
the way to do it and is the usual way of doing things.

What I tried to point out is, that if a special feature has specific
build requirements, then a distributor's/maintainer's job who builds the
package is to take care of all this. 

I tried to object  the idea of packaging all necessary headers (of
external deps) with cryptsetup into one package.

Sorry, if I did not make this clear enough.

Regards

-Sven



On Mon, 2013-01-07 at 19:12 +0100, Milan Broz wrote:
> On 01/07/2013 12:21 PM, Sven Eschenberg wrote:
> > 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
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On lun., 2013-01-07 at 12:21 +0100, Sven Eschenberg wrote:
> 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, but it's cryptsetup job to maintain it until enough people have the
relevant headers installed, which can take some time.
http://kernelnewbies.org/KernelHeaders has some information about that.

Regards,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]