therealromster / cryptsetup Goto Github PK

Serveral cipher modes have problems with "extremly" large cipher data being
available.

Add key separation schema to LUKS to generate different keys for every 0.5
TB stripe.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537385

The "hash spec" reported in the luksDump output should be changeable
for an existing volume. After all, it should apply only to existing
slots and should thus be a per-slot value, with a default for new
slots. It would be nice if I could change hashes by creating a new
key/slot with the new hash and removing the old slot to get rid of
the old hash.

http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/3296

(bug reported by Martin F. Krafft <[email protected]>)

This is about a Lenny install with the stock kernel and modules
and the stock cryptsetup 1.0.6

I am doing an exercise of encrypting an existing debian partition               

in a raw qemu image before doing that in production environment.                


I first identified the start of the partition (98703360) by doing               

  sfdisk -l -uS lenny.img                                                                           

Then, I configured a loopback defice and mounted the partition                  


  losetup /dev/loop0 lenny.img                                                                      
  mkdir lenny                                                                                       
  mount lenny.img lenny -t ext3 -o loop=/dev/loop0,offset=98703360                                  

After backing up, I attempted to create an encrypted partition, but             

cryptsetup failed with an obscure message:                                      


  mkdir lenny-backup                                                                                
  time cp -ax lenny/* lenny-backup/                                                                 
  umount lenny                                                                                      
  cryptsetup luksFormat --offset=98703360 /dev/loop0                                                
  >Command failed: Failed to write to key storage                                                   

AFAIU, all necessary modules were loaded.                                       


  lsmod|egrep dm_crypt\|aes                                                                         
  aes_i586                7744  0                                                                   
  aes_generic            29256  1 aes_i586                                                          
  dm_crypt               11172  0                                                                   
  dm_mod                 46184  1 dm_crypt                                                          
  crypto_blkcipher       15236  3 cbc,dm_crypt,ecb                                                  

Any idea on how create an encrypted partition in a loop-mounted disk image?     

What steps will reproduce the problem?
1. Create luks volume on a former ext2/3 volume with cryptsetup <=1.0.6
(e.g. Ubuntu Jaunty Alternate CD)
2. Upgrade to the newest blkid utility (e.g. upgrading to Ubuntu Karmic)
3. Try to get UUID of the volume with blkid

What is the expected output? What do you see instead?
UUID is expected, but blkid doesn't output anything.

As old cryptsetup versions didn't wipe the start of the device, blkid on
some volumes finds a luks identifier and an ext* identifier, it therefore
outputs nothing.
The cause of this bug is fixed in cryptsetup >= 1.0.7, but it should also
provide a documented way for fixing the symptoms on old volumes.

More information regarding the bug, can be found here:
http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/2563/focus=2568
and here: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/362315

Patch from Ivan Stankovic

Patch from Ivan Stankovic

From Stefan Assmann <[email protected]>:

Subject: Enhance luksOpen to make use of key_size parameter

In case you want to read your key from a block device (or large file) the
normal behavior is to read the whole thing. However if your key is stored at
the beginning of that file this patch allows you to specify the -s parameter
with luksOpen and just read n bits from that file.
Example:
cryptsetup luksOpen /dev/sda1 sda1 -d /dev/sdb -s 256
Reads only the first 256 bits from /dev/sdb

Not supplying -s option for luksOpen results, as before, in an exhaustive read.

Signed-off-by: Stefan Assmann <[email protected]>

The 'distcheck' automake target ensures that split compiles work properly,
among other things. Attached is a patch which fixes the distcheck target
for current svn HEAD.

Hello,

I recently moved from using cryptmount to cryptsetup due to the simplicity
of cryptsetup. problem I had while doing so is that I call cryptsetup from
a perl script and used cryptmount's --passwd-fd switch to pass passwords
from perl. cryptsetup made things more difficult and I am now forced to use
perl's Expect module.
it would be very comfortable to have some easy way of passing the old and
new passwords in luksAddKey.

Thanks,
 Lior

The configure script will detect gcrypt even when it is installed in a non-
standard location, and will then set LIBGCRYPT_CFLAGS and LIBGCRYPT_LIBS 
appropriately in Makefile. These variables are however not passed to gcc, 
and during compilation an error
    "af.c:28:20: error: gcrypt.h: No such file or directory"
occurs.

Installing cryptsetup-1.1.0-rc3 on a custom GNU/Linux installation.

What steps will reproduce the problem?
1. Create an encrypted file system with different passphrases for each
member of a small team, say around 6 people
2. Have one member leave after 6 months
3. Remember a bit later to revoke the key of the person who left
4. How do you figure out which key was his?
 - Have each member open and close the device with is passphrase and record
the slot number (which you should've done the first time)
 - What if taking the particular volume off-line is non-trivial?

Having a comment field for each key slot would eliminate this particular
bit of management headache--then you could record who owns the key in which
slot (and it would at least be obvious at the time the keys were added that
was important).

In debian bug #494584
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494584), C. Dominik Bodi
<[email protected]> pointed out, that cryptsetup gives misleading error
messages for incompatible cipher and keysize options.

In his particular case, he tried to use the xts-plain cipher method with
the default keysize for luksFormat (which is 128b). Unfortunately,
xts-plain doesn't allow keysize 128b.


the command:
cryptsetup --verbose --cipher aes-xts-plain --verify-passphrase luksFormat
/dev/hda2

fails with the following error message:
Command failed: Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-xts-plain cipher spec and verify that
/dev/hda2 contains at least 133 sectors


This error message is rather misleading as the problem neither is missing
kernel support for the cipher, nor a too small device.

So it would be great to make the error message point out that fact.

Additionally, C. Dominik proposed that cryptsetup could choose a default
key size accordingly to the used cipher, what I consider a good idea as well.

greetings,
 Jonas Meurer

The attached patch allows for passing the actual passphrase via the
"passphrase" field of struct crypt_options when setting up a mapping.

All hail goes to Waldemar Brodkorb, who wrote the original patch. I only
improved coding style a bit.

Greetings, Phil

hey,

cryptsetup 1.1.0 asks for verification of the passphrase used to unlock an
existing keyslot at luksAddKey. this happens only if a new keyfile is given
as second argument:

# cryptsetup luksAddKey /dev/vg/ctest keyfile
Enter any passphrase: 
Verify passphrase: 
Key slot 0 unlocked.
root@resivo:~# cryptsetup luksAddKey /dev/int/ctest
Enter any passphrase: 
Key slot 0 unlocked.
Enter new passphrase for key slot: 
Verify passphrase: 

this is a regression as cryptsetup 1.0.6 didn't have this problem at all.

the bug was originaly submitted by Harald Dunkel to the debian bts:
http://bugs.debian.org/570418

greetings,
 jonas

Hey again,

aparently luksKillSlot doesn't sanitize the keyslot numbers.

with keyslot numbers > 7 I get a "Key $nr not active. Can't wipe."
in my eyes only the numbers 0-7 should be accepted, as luks doesn't support
more keyslots at the moment anyway.

even worse, with a keyslot number > 144 i get a segmentation fault:

# cryptsetup luksKillSlot /dev/vg_int/ctest4 144
key slot 0 verified.
Command failed: Key 144 not active. Can't wipe.

# cryptsetup luksKillSlot /dev/vg_int/ctest4 145
Segmentation fault

(cryptsetup version is 1.0.7~rc1)

greetings,
 jonas

What steps will reproduce the problem?
1. Have selinux libraries installed because of a mistake and want to get
rid of them
2. Don't want cryptsetup linking against selinux libraries

What version of the product are you using? On what operating system?
1.0.6-r1 and trunk

Patch attached that makes it possible to give ./configure --disable-selinux
in which case the libraries are not linked against. Otherwise the
./configure uses auto detection as before.

Hi.

When thinking about how a secure suspend-to-ram (S3) should look like, I
came to the conclusion that at least it needs to remove the encryption keys
of mounted devices to minimize possible security impact. But when I tried
to accomplish this using cryptsetup with an encrypted partition with LUKS,
I failed because there is no option to tell it to only (re)load the device
mapper table data into an inactive table slot (as dmsetup load/reload).

Because forcefully unmounting a file system in use is not nice and doesn't
even work on root, I thought it would be easier to do something with dm.
The steps for suspend-to-ram I was trying to use look like:
# Somehow to remove the encryption key (I hope that loading another table
first zeroes out or sets to random the occupied memory region):
dmsetup remove -f foo
# or with: dmsetup suspend foo; dmsetup reload foo --table '0 1 error';
dmsetup resume foo
# or do you have any better idea?

<suspend-to-ram>

# Prompt for the luks password and restore previous device:
dmsetup suspend foo
cryptsetup luksOpen /dev/sdaX foo
dmsetup resume foo
# A (re)load variant should probably called with a parameter --load or as a
command luksLoad...


A patch for this doesn't seem hard, but unfortunately I can't create it at
this moment, so I will describe what I think:

In libdevmapper.c there is a function:
static int dm_create_device(int reload, struct crypt_options *options,
const char *key) {
  ...
  if (!(dmt = dm_task_create(reload ? DM_DEVICE_RELOAD : DM_DEVICE_CREATE)))
  ...
}

And you are calling it from setup.c:
static int __crypt_luks_open(int arg, struct setup_backend *backend, struct
crypt_options *options) {
  ...
  r = backend->create(0, options, mk->key);
  ...
}

For me it looks like setting the first parameter in this call to "1" would
do the trick. So it could be done ugly (checks if create succeeded and
tries with reload flag if not) or as mentioned before a new parameter
(--load/--reload) could be added to allow setting of this parameter.

Probably there are also other usage scenarios of such a feature, so please
implement it soon...

Thanks,
   gw

Hi,
when i try to compile with --enable-static i receive this error:

/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../../lib/libdevmapper.a(libdm-common.
o):
In function `_add_dev_node':
(.text+0x169d): warning: the use of `mktemp' is dangerous, better use
`mkstemp' or `mkdtemp'
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../../lib/libdevmapper.a(libdm-common.
o):
In function `dm_set_selinux_context':
(.text+0x13f9): undefined reference to `is_selinux_enabled'
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../../lib/libdevmapper.a(libdm-common.
o):
In function `dm_set_selinux_context':
(.text+0x1411): undefined reference to `matchpathcon'
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../../lib/libdevmapper.a(libdm-common.
o):
In function `dm_set_selinux_context':
(.text+0x1461): undefined reference to `lsetfilecon'
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../../lib/libdevmapper.a(libdm-common.
o):
In function `dm_set_selinux_context':
(.text+0x1473): undefined reference to `freecon'
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../../lib/libdevmapper.a(libdm-common.
o):
In function `dm_set_selinux_context':
(.text+0x158a): undefined reference to `freecon'
collect2: ld returned 1 exit status
make[2]: *** [cryptsetup] Error 1

For reproduce this issue:

1) checkout
2) ./autogen.sh --enable-static

Tested on:
- debian-testing (squeeze) 2.6.31.5 x86_64
- debian-stable (lenny) 2.6.31 x86

In attachment autogen/make output (squeeze)

Good work
Gabriele

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518266

The cryptsetup(8) man page mentions the default hash, cipher, and keysize 
values for different cases, but I am looking for a way to determine what 
values are available. Looking at the source it seems to determine this from 
/proc/crypto (so I guess depends on what kernel modules are loaded?).

Could cryptsetup have an option to print available options? Maybe if you 
invoked a flag with "list" like

  cryptsetup --cipher list

it could list available options?

Also I think only certain combinations are supported, it would be nice if 
somehow it could list those too.

Thanks,

-- 
Matt Taggart
[email protected]

hey milan,

i just got the following report against cryptsetup by the debian lvm2
maintainer:

> I'm not sure, where this informations comes from, but LVM upstream
> decided to use the UUID of CRYPT-TEMP-* to detect the temporary luks
> devices. Also in the examples, they use CRYPT-PLAIN-* and CRYPT-LUKS1-*,
> which is not set this way by the current version of cryptsetup.

this bug has been reported as #548988: http://bugs.debian.org/548988

i guess that you know more, as you're involved in - or at least have good
knowledge of upstream device-mapper development :-)

greetings,
 jonas

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533643

Hi,

I just lost 1.5TB data because I accidentally installed grub over the
LUKS superblock and there seems to be no way to restore it.

I'm missing 2 things:

1) an on disk backup of the superblock
   That would not only help with accidental overwrites but also if a
   block gets damages on the disk.

   It might also be a good idea to move the superblock 4k or 64k from
   the start of the device so a mbr/bootloader does not overwrite the
   superblock.

2) cryptsetup luksBackup and luksRestore command
   There should be a command to dump the superblock of a luks volume
   into a file for backup purposes and one to restore it from a file.
   cryptsetup could even automatically store a backup on every change
   like lvm does.

MfG
    Goswin

Purpose of code changes on this branch:
Clean up unused variables - removed "unsigned int i;" on Line 598 and "int
key_slot = options->key_slot;" on line 601.

When reviewing my code changes, please focus on:
Making sure these variables weren't used elsewhere.

After the review, I'll merge this branch into:
/trunk

[deleted issue]

Newer udev versions do not have a udevsettle binary anymore.
Instead "udevadm settle" has to be called.

Attached patch extends libcryptsetup to allow utilities linking against
libcryptsetup to handle the master key directly.

hey again,

Stuart Pook reported in debian bugreport #538221
(http://bugs.debian.org/538221) that he discovers 'device or resource busy'
errors with cryptsetup 1.0.7~rc1 and 1.0.7 final. downgrading to cryptsetup
1.0.6 solves the issue for him:

---snip---
Package: cryptsetup
Version: 2:1.0.7~rc1-2
Severity: important

Crytsetup 2:1.0.7~rc1-2 often fails to open my devices. Sometimes it works
but I'm not exactly sure under
what conditions. Downgrading to 2:1.0.6+20090405.svn49-1 from testing works.

: root; cryptsetup luksOpen /dev/mapper/vg0-services_var services_var
--key-file /tmp/xx
key slot 1 unlocked.
Command failed: device-mapper: create ioctl failed: Device or resource busy
: root; apt-get -t testing install cryptsetup/testing
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version 2:1.0.6+20090405.svn49-1 (Debian:testing) for cryptsetup
The following packages will be DOWNGRADED:
  cryptsetup
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 3 not upgraded.
Need to get 0B/331kB of archives.
After this operation, 4096B disk space will be freed.
Do you want to continue [Y/n]?
dpkg: warning: downgrading cryptsetup from 2:1.0.7~rc1-2 to
2:1.0.6+20090405.svn49-1.
(Reading database ... 250248 files and directories currently installed.)
Preparing to replace cryptsetup 2:1.0.7~rc1-2 (using
.../cryptsetup_2%3a1.0.6+20090405.svn49-1_i386.deb) ...
Unpacking replacement cryptsetup ...
Processing triggers for man-db ...
Setting up cryptsetup (2:1.0.6+20090405.svn49-1) ...
Installing new version of config file /etc/init.d/cryptdisks-early ...
Installing new version of config file /etc/init.d/cryptdisks ...
Installing new version of config file /etc/bash_completion.d/cryptsetup ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.30-1-686
localepurge: Disk space freed in /usr/share/locale: 12K
: root; cryptsetup luksOpen /dev/mapper/vg0-services_var services_var
--key-file /tmp/xx
key slot 1 unlocked.
Command successful.
---snap---

greetings,
 jonas

Cryptsetup should not use hardcoded SHA1 code but susme system library/

Attached patch switch the code to using libgcrypt and removes hardcoded SHA1.

The options for with luksFormat are not very flexible.  I cannot change the
cipher hash (the stuff after the colon) or the key size.

# cryptsetup -v -c twofish-cbc-essiv:sha384 luksFormat /dev/sda8
[...]
Command failed: Failed to setup dm-crypt key mapping.
Check kernel for support for the twofish-cbc-essiv:sha384 cipher spec and
verify that /dev/sda8 contains at least 133 sectors

cryptsetup-1.0.6 on Gentoo, Linux 2.6.28.1

It works with s/sha384/sha256/.  Also, if I try to set --key-size to
anything but 256, I get the same error.

I also noticed that --hash is meaningless, and hard-coded to "sha1".  Isn't
this kind of a big thing?

I'm trying to cross-compile cryptsetup-1.0.7. Configure argument list is:
--prefix=/usr --build=i686-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --disable-nls. I get the following error
message after having issued "make":

Making all in src
make[2]: Entering directory `/mnt/clfs/sources/cryptsetup-build/src'
x86_64-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I../../cryptsetup-1.0.7/src -I.. -I../../cryptsetup-1.0.7
-I../../cryptsetup-1.0.7/lib -DDATADIR=\""/usr/share"\"
-DLOCALEDIR=\""/usr/share/locale"\" -DLIBDIR=\""/usr/lib"\"
-DPREFIX=\""/usr"\" -DSYSCONFDIR=\""/usr/etc"\" -DVERSION=\""1.0.7"\"
-D_GNU_SOURCE   -Wall -g -O2 -MT cryptsetup-cryptsetup.o -MD -MP -MF
.deps/cryptsetup-cryptsetup.Tpo -c -o cryptsetup-cryptsetup.o `test -f
'cryptsetup.c' || echo '../../cryptsetup-1.0.7/src/'`cryptsetup.c
mv -f .deps/cryptsetup-cryptsetup.Tpo .deps/cryptsetup-cryptsetup.Po
/bin/bash ../libtool --tag=CC   --mode=link x86_64-unknown-linux-gnu-gcc
-Wall -g -O2    -o cryptsetup cryptsetup-cryptsetup.o -lpopt
../lib/libcryptsetup.la
libtool: link: x86_64-unknown-linux-gnu-gcc -Wall -g -O2 -o
.libs/cryptsetup cryptsetup-cryptsetup.o  /usr/lib/libpopt.so
../lib/.libs/libcryptsetup.so
/usr/lib/libpopt.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[2]: *** [cryptsetup] Error 1
make[2]: Leaving directory `/mnt/clfs/sources/cryptsetup-build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/clfs/sources/cryptsetup-build'
make: *** [all] Error 2

I think the problem is due to the fact that it tries to use libpopt.so from
the host system (/usr/lib/libpopt.so) instead of the one from the target
system (/mnt/clfs/usr/lib/libpopt.so). If from the build directory I issue
the last command with the right path for libpopt.so, the error disappears
(but I don't know if it will fail elsewhere).

hello,

people tend to disagree with cryptsetups output behaviour. the sucess
message print to stderr is regarded as bad behaviour. stderr is meant for
warnings and error messages, but 'command successfull' is neither a warning
not an error message.

nevertheless it is not an option to simply remove the message at all, as
that would break backwards compability for scripts that do rely on current
output behaviour of cryptsetup.

thus i suggest to add a commandline option --no-stderr-success which causes
cryptsetup to suppress the success message to stderr.

i attached a patch which adds the commandline option along with some minor
formating fixes.

greetings,
 jonas

What steps will reproduce the problem?
1. Try running luksFormat with a non-FIPS enabled algorithm like whirlpool
or tiger192

What is the expected output? What do you see instead?
Expected: luksFormat works fine as whirlpool is defined into gcrypt and the
FIPS mode isn't enabled
What I see: luksFormat fails as it can't find the cipher because the md
algorithms have been loaded (due to the calls done in PBKDF2_HMAC_ready to
gcry_md_map_name and gcry_md_get_algo_dlen) without initializing libgcrypt
which in turn loads the md algorithm list assuming it is in FIPS mode not
loading the ones not supported in that mode.

What version of the product are you using? On what operating system?
cryptsetup-1.1.0-rc4 on a gentoo hardened up to date with kernel 2.6.28

Please provide any additional information below.
The failure is easy to fix changing the code into "int
PBKDF2_HMAC_ready(const char *hash)" so it initializes gcrypt before hand,
i.e. calling init_crypto(). A patch solving the problem is attached.

hey,

i did some benchmarking regarding the speed of luksOpen, as i have
the impression that it sometimes takes really long.

for the benchmark i created eight different key files
(dd if=/dev/urandom of=key_<size> bs=<size> count=1)
with different sizes: 128b 512b 1k 16k 64k 128k 512k 1m

afterwards i added all these keys to key slots of a luks device. i used
a 4mb lvm logical volume as device:
cryptsetup luksFormat /dev/vg00/ctest1 testkey_128b
cryptsetup luksAddKey --key-file=testkey_128b /dev/vg00/ctest1 testkey_515b
...

after running luksOpen for the device with every key several times:

time -F "<size>: %E" cryptsetup luksOpen --key-file=testkey_<size>
/dev/vg00/ctest1 ctest1

i got the following result:

(#1 is first run, #2 is second run)

with ordered slot<->keysize relation:

Slot #0: (128b):        #1: 0:01.76     #2: 0:02.03
Slot #1: (512b):        #1: 0:03.97     #2: 0:04.06
Slot #2: (1k):          #1: 0:06.02     #2: 0:05.46
Slot #3: (16k):         #1: 0:08.03     #2: 0:08.11
Slot #4: (64k):         #1: 0:10.12     #2: 0:09.87
Slot #5: (128k):        #1: 0:11.46     #2: 0:11.71
Slot #6: (512k):        #1: 0:15.18     #2: 0:14.96
Slot #7: (1m):          #1: 0:20.93     #2: 0:19.98

and with unordered keysize<->slot relation:

Slot #0: (128k):        #1: 0:02.11     #2: 0:01.96
Slot #1: (512k):        #1: 0:05.14     #2: 0:05.15
Slot #2: (1k):          #1: 0:06.03     #2: 0:05.68
Slot #3: (1m):          #1: 0:12.86     #2: 0:13.09
Slot #4: (128b):        #1: 0:10.06     #2: 0:10.07
Slot #5: (64k):         #1: 0:11.72     #2: 0:11.38
Slot #6: (16k):         #1: 0:14.09     #2: 0:14.10
Slot #7: (512b):        #1: 0:15.75     #2: 0:16.14

my conclusion is that both increasing size of keysize and increasing
slotnumber cause luksOpen to take longer:

with unordered keysize<->slotrelations the time increases with
increasing slotnumber, with the exception of slot #3 where the
biggest key (1mb) is used.

i used cryptsetup version 1.0.7~rc1 for the benchmarks.

greetings,
 jonas

What steps will reproduce the problem?
1. Build current SVN
2. dd if=/dev/null of=/tmp/file bs=1048576 seek=1024
3. losetup /dev/loop0 /tmp/file
4. ./src/cryptsetup luksFormat /dev/loop0
5. ./src/cryptsetup luksOpen /dev/loop0 pv

What is the expected output? What do you see instead?

Expected: luksOpen should prompt for a passphrase and then create
/dev/mapper/pv.

What I see:

# ./src/cryptsetup luksOpen /dev/loop0 pv2
device-mapper: status ioctl failed: Permission denied
#

(All of the above runs as root.  Note also that /tmp/file is a sparse file,
but the sparse-ness doesn't affect this test; I get the same results even
if I fill in all the nonexistant blocks in the file with zeros.  Note
*also* that I have an existing encrypted partition mapping already set up
(with my root FS on it), but that is set up using cryptsetup 1.0.7, which
works fine.  Note that the device-mapper "status" ioctl is not broken,
since "dmsetup status pv" shows info on my other encrypted volume.  I can
also successfully set up a (useless) mapping with a fake key by copying the
right values into a file named map, and doing "dmsetup create pv2 map",
which succeeds.)

What version of the product are you using? On what operating system?

As above, current SVN.  This is Linux From Scratch, version 6.5.  (Well,
mostly.  There are a few custom changes to get 64-bit working; this is a
64-bit binary and libdevmapper library as well.)  Kernel 2.6.32.3, glibc
2.10.1.  gcrypt 1.4.4, LVM2-2.02.56 (and whatever version of libdevmapper
it includes), and popt 1.15.  Last, I have libcap-2.17 (compiled against
libattr-2.4.43-1) as well, which is apparently used by gcrypt.

I should note that before SVN r139, the "status ioctl failed: Permission
denied" error was printed, but then cryptsetup continued.  At r139, and
later, it exits.

(However, versions before r139 aren't usable either: when doing a
luksFormat, I type in and verify a passphrase, and then get "device-mapper:
create ioctl failed: Permission denied", and "Failed to setup dm-crypt key
mapping for device /dev/loop0." errors.  Given that I don't get these in
later cryptsetup versions, though, I suspect they've already been fixed.)

I should also note that before SVN r111, the "status ioctl failed:
Permission denied" message is not printed at all.  It *looks* like
initialization of gcrypt is breaking device-mapper.

The most recent thing I've tried is removing the call to init_crypto that
was added in r111, from current SVN.  This passes the device-mapper status
ioctl, but fails to match any passphrase (even if I use the same binary to
do both luksFormat and luksOpen).  I guess init_crypto is required to
unlock any of the key slots -- but if it's breaking device-mapper, that's
not good...  :-)

Attaching the strace output of current SVN.  The only other odd thing (that
I see anyway) is that mmap() is also failing, which causes some piece of
code to read a single byte at a time from both /proc/mounts and
/usr/share/locale/locale.alias.  But the broken ioctl() is between those
two large chunks of read() calls: DM_TABLE_STATUS is returning -1 with
errno set to EACCES.

Thanks!

Hi,
another problem with static binary.
Check the attached file

Happy new year
Gabriele

From [email protected]:

Hello,
attached is a patch against cryptsetup trunk, that adds the following:

* crypt_luks_get_volume_info () and related functions, that allow reading
volume metadata more cleanly than attempting to parse the output of
crypt_luksDump ().
* Three functions that allow direct manipulation of the master key,
necessary for automated master key backup.  (This patch does not expose
them in the command-line utility; I plan to use the functions in a separate
library that will only output the master key in a wrapped form.)
* Minor Makefile changes to fix build when builddir != srcdir.

Thank you,
   Mirek

hey again,

at doing benchmarks for luksOpen I discovered a bug that must have been
introduced between cryptsetup 1.0.7~rc1 and 1.0.7 final:

when I try to luksOpen with keyfile from keyslot 6 or 7 (last two keyslots)
i get a 'Command failed.'

luksKillSlot still works, but when I try to luksAddKey:

Enter new passphrase for key slot: 
Verify passphrase: 
Command failed: Failed to setup dm-crypt key mapping for device
/dev/vg_int/ctest4.
Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for
more info).

i'm not sure what change did introduce the bug, and I don't have time to
look into the code right now. i can take a further look in two weeks if
required.

greetings,
 jonas

In debian bug #492926
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492926), Elmar Hoffmann
<[email protected]> requests that cryptsetup should give a better error message
in case that one tries to open an already mapped luks device, instead of
using the same error message as for non-existing devices.

The following message/patch is from Sebastian Andrzej Siewior:

The buffer has to be aligned due to the O_DIRECT in open(). Currently a
small blocksize buffer is allocated and everything is read in multiple
reads and copied back to the original buffer. In my case AFEKSize gets
computed to 64000 which results in 125 reads with 512 bytes each.
This patch changes this behavior to a single operation where the majority
is read()/write() plus an optional fixup in case the request is not modulo
block size.

With this patch I can see that the performance has improved on my ARM box
Before the patch:
|# time cryptsetup luksOpen /dev/sda2 crypt -d key
|key slot 0 unlocked.
|Command successful.
|
|real    0m3.089s
|user    0m0.550s
|sys     0m0.120s
|# time cryptsetup luksOpen /dev/sda2 crypt -d key
|key slot 0 unlocked.
|Command successful.
|
|real    0m3.059s
|user    0m0.550s
|sys     0m0.110s

With the patch:

|# time src/cryptsetup luksOpen /dev/sda2 crypt -d key
|key slot 0 unlocked.
|Command successful.
|
|real    0m2.061s
|user    0m0.560s
|sys     0m0.290s
|# time src/cryptsetup luksOpen /dev/sda2 crypt -d key
|key slot 0 unlocked.
|Command successful.
|
|real    0m1.977s
|user    0m0.580s
|sys     0m0.200s

I also see this improvement on my x86_64 box

Signed-off-by: Sebastian Andrzej Siewior <[email protected]>

hey again,

error messages from crypt_deactivate() in lib/setup.c are print twice for
some reason.

luksClose a device that's not active

# cryptsetup luksClose ctest
Device ctest is not active.Command failed: Device ctest_pass is not active.

luksClose a device that's busy:

# cryptsetup luksClose ctest
Device ctest is busy.Command failed: Device ctemp1 is busy.

greetings,
 jonas

Patch from Ivan Stankovic

how to reproduce:

1. install brand new SATA hdd about 750Gb, let it be /dev/sdX

2. # cfdisk /dev/sdX - create one large primary partition taking all disk

3. # cfdisk - press ``m'' yo maximize, see
http://www.netadmintools.com/html/8cfdisk.man.html what it means

4. load modules
# modprobe dm-crypt
# modprobe aes-x86_64

5. # cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sdX1
Enter passphrase: mypassword
Verify passphrase: mypassword
# mkdir /mnt/test1
# cryptsetup luksOpen /dev/sdX1 test1
Enter any LUKS passphrase: mypassword

# mkfs.ext3 /dev/mapper/test1

# mount /dev/mapper/test1 /mnt/test1
# dd if=/dev/zero of=/mnt/test1/test1.dat bs=1M count=100

# sync; sync; sync; reboot

6. login, try to reopen:
# cryptsetup luksOpen /dev/sdX1 test1
Enter passphrase: mypassword
Command failed: No key available with this passphrase.

oops !

# cryptsetup luksDump /dev/sdX1
Command failed: /dev/sdb1 is not a LUKS partition

oops !

# dd if=/dev/sdX1 of=/tmp/xxx bs=10240 count=10
# strings /tmp/xxx | less
LUKS
xts-plain
sha1
1d26097a-33e9-41bb-83d5-df5b452148cd
PgP)
qmi=
\a}bS
Omf}
...... etc
===

# uname -a
Linux test1 2.6.30-ARCH #1 SMP PREEMPT Sat Jul 4 02:24:43 CEST 2009 x86_64 
AMD Sempron(tm) Processor 3200+ AuthenticAMD GNU/Linux

# cryptsetup --version
cryptsetup 1.0.6

===

Also I can provide as much dumps of /dev/sdX and /dev/sdX1 as needed.

Is it possible to start thinking about plausible deniability support for
LUKS? SOmething similar TrueCrypt already has?

hello,

with cryptsetup 1.1.0-rc1 i sometimes get device-mapper errors at unlocking
a luks device. i didn't get these errors with cryptsetup 1.0.7:

with a wrong password an error was steadily reproducible some minutes ago:

# cryptsetup luksOpen /dev/vg0/test ctest
Enter passphrase for /dev/vg0/test: 
device-mapper: remove ioctl failed: Device or resource busy
No key available with this passphrase.

unfortunately at the time of writing the bug i'm no longer able to
reproduce that error. i didn't change anything, didn't reboot.

with a correct passphrase i once (during boot process) got another error,
but i am unable to reproduce it any longer. i don't know the order of
messages any longer, and dmesg only contains the 'unable to remove open
device' error. so the exact order of warnings/errors/messages might be
different:

# cryptsetup luksOpen /dev/vg0/test ctest
Enter passphrase for /dev/vg0/test:
Key slot 0 unlocked.
device-mapper: remove ioctl failed: Device or resource busy
device-mapper: ioctl: unable to remove open device temporary-cryptsetup-2564

i'll try to reproduce errors by rebooting later that day.

greetings,
 jonas

With all slots full, if you call luksAddKey again, keyslot_from_option
returns -EINVAL, but __crypt_luks_add_key doesn't check for this and
assumes the return is a valid keyIndex.

Adding the following after the keyslot_from_option call seemed to solve the
problem:

if(keyIndex == -EINVAL) {
        r = -EINVAL; goto out;
}

The only other place keyslot_from_option is called is in
__crypt_luks_format, but there should never be an all slots full error from
there.

Also, looking at the code it seems that if the key-slot option is used,
there is no check anywhere if somebody enters a negative number for this. 
Adding a check in keyslot_from_option for negative numbers after the check
for numbers greater than equal to LUKS_NUMKEYS seems like the easy fix for
this.

From Marc:

> 4) this case is also suboptimal:
> 
> If I pass the old key from stdin and expect to type the new one from the
> command line, nothing is asked from the command line and cryptsetup adds
> a new key that it was not able to retreive from anywhere (is it NULL?)
> 
> > polgara:~$ echo -n
'sFrxpxOJ1LxbYJy35xrkIuUqn3piE3fy0xvz2zzc2nDmaBYtaT3lmRpYajdhqJVvIwUEc5PMmwWvXYW
4bd1j8TxVxrZxQ9tAOMrTnY7zFnolunNDaoN2rvxBTZWr0TWJQfsz77cPnYs3bO1yySUfsH2EljSX0T9
N3brBPMP3i6vQHhWm1ZgjPuEwzZ2tjChS1R0V5KxmYkXOGClIMOwqMLUYTPdxKgrYgxtdHKMHYF43kNn
k5cpQmfey1tS30LkQDgW9ZuPgoBdmE8islcEaXaJkjWPSSWhUKHyL9uT47SQdSzPjQHSSvE20EY4cNjq
TuCPhc0zjGLogs1K8vnLFVSFGz2C9QYUsOYJ5ieggEzjJXoPtFYEZ6wfpCq3Ofg7I1LBCxqywU3WKqdb
Prr5x9idZXGijx5YYcSZ9xPJHeG5sNu2meIYm3XUVdRGYiRn60saX2XT3nXmq5NJzet9ZB5xFKObYWmB
gAhej62mOToNWhG8aDy4hy7Y507dsv78o'
| sudo cryptsetup luksAddKey --key-slot 1 --key-file -  /dev/sda6
> > key slot 2 unlocked.
> > Command successful.
> > polgara:~$ sudo cryptsetup luksDump /dev/sda6
> > LUKS header information for /dev/sda6
> > 
> > Version:        1
> > Cipher name:    aes
> > Cipher mode:    cbc-essiv:sha256
> > Hash spec:      sha1
> > Payload offset: 1032
> > MK bits:        128
> > MK digest:      e6 f6 15 48 44 22 71 dd 3e 63 35 0a 0a f1 2d ce c5 74 72 f0
> > MK salt:        61 8b 7a e6 c6 73 cd da 85 8e 17 31 88 c6 4b 75
> >                 80 00 03 5d 04 de 85 6f a4 2b 6d c6 ee 61 c6 dc
> > MK iterations:  10
> > UUID:           fe031e91-b31d-4a3e-8a1f-b12be18edd61
> > 
> > Key Slot 0: ENABLED
> >         Iterations:             440937
> >         Salt:                   33 c8 b0 6e 93 61 1d f1 53 79 cb bd 0c
3f ee 91
> >                                 4b 42 56 95 1a bb 5b 1f 85 d2 ad 1e 9d
9f d4 fa
> >         Key material offset:    8
> >         AF stripes:             4000
> > Key Slot 1: ENABLED
> >         Iterations:             445325
> >         Salt:                   74 4d e4 13 17 0a 15 ea e1 ed 7f 12 19
0c b0 b0
> >                                 59 ef 82 6d 8e b9 93 b6 89 a0 cf 97 dc
b3 b7 f4
> >         Key material offset:    136
> >         AF stripes:             4000
> > Key Slot 2: ENABLED
> >         Iterations:             438762
> >         Salt:                   d9 cc e1 ea 94 b1 3d ef 3e 5a b6 97 04
5c 5a a6
> >                                 ab a5 bb c0 a3 3f a0 21 6b aa 76 b1 0b
a7 49 89
> >         Key material offset:    264
> >         AF stripes:             4000
> 
> the supplied key on the stdin was an unlock key, but no key is supplied
> as the replacement key.
> 
> Strangely enough, the same happens without --key-file:
> > polgara:~$ echo -n
'sFrxpxOJ1LxbYJy35xrkIuUqn3piE3fy0xvz2zzc2nDmaBYtaT3lmRpYajdhqJVvIwUEc5PMmwWvXYW
4bd1j8TxVxrZxQ9tAOMrTnY7zFnolunNDaoN2rvxBTZWr0TWJQfsz77cPnYs3bO1yySUfsH2EljSX0T9
N3brBPMP3i6vQHhWm1ZgjPuEwzZ2tjChS1R0V5KxmYkXOGClIMOwqMLUYTPdxKgrYgxtdHKMHYF43kNn
k5cpQmfey1tS30LkQDgW9ZuPgoBdmE8islcEaXaJkjWPSSWhUKHyL9uT47SQdSzPjQHSSvE20EY4cNjq
TuCPhc0zjGLogs1K8vnLFVSFGz2C9QYUsOYJ5ieggEzjJXoPtFYEZ6wfpCq3Ofg7I1LBCxqywU3WKqdb
Prr5x9idZXGijx5YYcSZ9xPJHeG5sNu2meIYm3XUVdRGYiRn60saX2XT3nXmq5NJzet9ZB5xFKObYWmB
gAhej62mOToNWhG8aDy4hy7Y507dsv78o'
| sudo cryptsetup luksAddKey --key-slot 1   /dev/sda6
> > key slot 2 unlocked.
> > Command successful.
> 
> I found that what we need to do is feed:
> echo "oldkey\nnewkey" | cryptsetup luksAddKey --key-slot 1   /dev/sda6
> 
> You do document the change in the man page but it's confusing to me:
>        If --key-file=- is used for reading the key from  stdin,  no  trailing
>        newline  is  stripped  from the input. Without that option, cryptsetup
>        strips trailing newlines from stdin input.
> 
> I do have to feed a newline as a delimitor between old and new, so I'm
> not sure if it's meant to work for addkey?
> For now, I'm just using addkey with stdin and without --key-file=- since
> --key-file=- does not seem to be waht I want. If you could explain this
> in more details in the man page, it may help.

What steps will reproduce the problem?
1. dd if=/dev/zero of=somefile.img bs=1M count=10
2. /sbin/losetup /dev/loop1 somefile.img
3. /bin/echo "x" | /sbin/cryptsetup --batch-mode luksFormat /dev/loop1
4. /bin/echo "x" | /sbin/cryptsetup --batch-mode luksOpen /dev/loop1 somefile

What is the expected output? What do you see instead?
output is sent in the following manner:
key slot 0 unlocked.  <<<<<< STDOUT
Command successful.   <<<<<< STDERR
where 'echo $?' returns 0.
I call cryptsetup from a perl script and expected the output be sent
completely to STDOUT and not to STDERR.


What version of the product are you using? On what operating system?
cryptsetup-luks 1.0.5
running on linux 2.6.18-6-686

Please provide any additional information below.

The hash name is not normalized when storing it in the header. As a result,
though the old and the new version support sha1, running the 1.1.0 version
with -h SHA1 results in a non backwards compatible device.

A simple solution will be normalizing the hash name to lower case before
writing it.

What steps will reproduce the problem?
1. Have /dev/scsi/ present via udev
2. Cryoptsetup a /dev/sd<somthing>
3. Check ststus on the mapping, see )probably) /dev/scsi/<somethign else>
   returned

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
  Latest beta. 

Please provide any additional information below.
  Mapping should be as in linux Kernel /Documentation/devices.txt

cryptsetup 1.1.0

luksHeaderBackup will fail if non FIPS hash algorithm is used, because
missing init_crypto call (again).

i got cryptsetup from svn but when i tried to compile it i got th following
error:

...
configure: creating ./config.status
config.status: error: cannot find input file: Makefile.

i attached the config.log

m.