lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5093C43F.9050508@redhat.com>
Date:	Fri, 02 Nov 2012 14:01:51 +0100
From:	Milan Broz <mbroz@...hat.com>
To:	linux-kernel@...r.kernel.org
CC:	jaxboe@...ionio.com, kzak@...hat.com
Subject: Re: [RFC PATCH 0/4] Remove cryptoloop support (cryptsetup replacement)

On 11/01/2012 09:11 PM, Milan Broz wrote:

> Dm-crypt/cryptsetup provides replacement for long time already.

Just one addition, here are notes how to replace cryptoloop
with cryptsetup.

Because there are several incompatible lostup implementations,
it cannot be automated. But you can easily find proper options
using few switches below.

Note, that some configurations are insecure and often
the insecure variant is mostly the default.

One such example is a passphrase used directly as key (not hashed)
(option -N which is sometimes default) an key is padded.
So with 8 char password and 256bit key 192bits of key is zeroed.

Another problem is with using predictable IV (initial vector, which
is basically just sector number in losetup) and CBC mode.
For CBC mode this is not secure, because it open system to
watermarking attacks.
(Cryptsetup uses ESSIV by default or XTS mode.)

Cryptsetup will not stop you to use such configurations though,
it is designed to allow everything possible if user wants.


LOSETUP -> CRYPTSETUP replacement
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(N.B. for new images you should you use cryptsetup defaults and get rid
of most compat options.)

Short example for compatible mapping:

  "losetup -e twofish -N /dev/loop0 /image.img"

can be used by cryptsetup

  "cryptsetup create image_plain /image.img -c twofish-cbc-plain -H plain"

(Plaintext device will be /dev/mapper/image_plain instead of /dev/loop0.)


Details
~~~~~~~
In Debian and some other distros is hashing default, hash is "ripemd160",
default key size is mostly 256bits. In some distros hashing is not used.

For cryptsetup (plain mode, no LUKS) you will need these options:

 [-c|--cipher]   - cipher specification
 [-s|--key-size] - key size in bits
 [-h|--hash]     - password hashing function ("plain" is no hashing)
 [-o|--offset]   - offset (in 512 sectors!)
 [-p|--skip]     - IV offset (in 512 sectors!) (usually the same as -o)

Here are some common combinations and cryptsetup replacements:

  losetup parameters     |  cryptsetup paramaters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  -e twofish [-N]        | -c twofish-cbc-plain -H plain [-s 256]
  -e twofish             | -c twofish-cbc-plain -H ripemd160 [-s 256]

Ditto for most other ciphers:

  -e aes [-N]            | -c aes-cbc-plain -H plain [-s 256]
  -e aes                 | -c aes-cbc-plain -H ripemd160 [-s 256]
...

Key size (Debian option -k, not upstream)

  -k 128                 | -s 128

Specifying offset, note losetup takes bytes, cryptsetup sectors.
Offset must be multiple of sectors (even in losetup).
SKip (-p) means offset for IV, you need specify both here.

  -o 2560                | -o 5 -p 5       # 2560/512 = 5

Even some esoteric configurations possible
(This example was default for some very old SuSe distro.)

Loop using twofish with only 160 bit key (zero padded to 192 bits) with no IV.

   cryptsetup -c twofish-cbc-null -s 192 -h ripemd160:20

Cryptsetup doesn't provide direct replacement for --pass-fd option
(pass file descriptor to read key) but you can use directly keyfile
option and keyfile size (see cryptsetup man page).

Also note, that cryptsetup allows mapping of loop-aes (multi-key) devices
(see loopaesOpen command in man page).
But this was never part of mainline kernel, so it is not important
for mainline cryptoloop replacement.

Thanks,
Milan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ