When I try cryptsetup -c twofish-xts-plain -s 512 luksOpen /dev/sdb1 data --key-file /mnt/my.key I get: No key available with this passphrase. If I try with Version 1.0.6 everythings fine. Reproducible: Always Steps to Reproduce: 1. cryptsetup -c twofish-xts-plain -s 512 luksFormat /dev/sdb1 /mnt/my.key (version 1.0.6) 2. update to cryptsetup-1.1.3 3. cryptsetup -c twofish-xts-plain -s 512 luksOpen /dev/sdb1 data --key-file /mnt/my.key Actual Results: No key available with this passphrase. Partition is not decrypted. Expected Results: Decrypt partition.
perhaps cryptsetup 1.0.6 just did it wrong. i'm not sure 512 is a valid bit size for twofish. try your options again but with -s 256.
(In reply to comment #1) > perhaps cryptsetup 1.0.6 just did it wrong. i'm not sure 512 is a valid bit > size for twofish. try your options again but with -s 256. > same error with -s 256...
have you tried the -h option too like the documentation states ? http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#7._Issues_with_Specific_Versions_of_cryptsetup
(In reply to comment #3) > have you tried the -h option too like the documentation states ? > > http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#7._Issues_with_Specific_Versions_of_cryptsetup > I've tryed -h ripemd160 with both -s 256 and -s 512. Still the same error...
well feel free to ask on the mailing list: http://code.google.com/p/cryptsetup/ if cryptsetup-1.1.3 can create & mount its own stuff, that's good enough for me. and my partitions that i created long ago with 1.0.6 still work fine.
I think the problem is that "-s" option is overloaded in 1.1.3. For luksFormat it means encryption key size (so in XTS mode it will use 2x256bit keys). Key size is stored in LUKS header, so you do not need to specify it during luksOpen. So, in luksOpen it is ignored (in 1.0.6) but in 1.1.3 it restricts passphrase size (size in bits, not in bytes!) (it was design mistake to implement it this way). So if you have key file longer than 64 (512/8) bytes, system will trim it to 64 bytes. So simple solution here is to NOT use "-s" in luksOpen command. Does it help for you? FYI this is fixed in cryptsetup 1.2.0 by definition of special paramater and not overloading "-s / --key-size). It will even warn user in luksOpen: cryptsetup: Option --key-size is allowed only for luksFormat and create. To limit read from keyfile use --keyfile-size=(bytes).
(In reply to comment #6) > I think the problem is that "-s" option is overloaded in 1.1.3. > > For luksFormat it means encryption key size (so in XTS mode it will use > 2x256bit keys). Key size is stored in LUKS header, so you do not need to > specify it during luksOpen. > > So, in luksOpen it is ignored (in 1.0.6) but in 1.1.3 it restricts passphrase > size (size in bits, not in bytes!) (it was design mistake to implement it this > way). > So if you have key file longer than 64 (512/8) bytes, system will trim it to 64 > bytes. > > So simple solution here is to NOT use "-s" in luksOpen command. Does it help > for you? > > FYI this is fixed in cryptsetup 1.2.0 by definition of special paramater and > not overloading "-s / --key-size). It will even warn user in luksOpen: > > cryptsetup: Option --key-size is allowed only for luksFormat and create. > To limit read from keyfile use --keyfile-size=(bytes). > yes! this does the trick: just delete the -s / --key-size option in the luksOpen command.
Peter: You closed this yourself. Was it just in your custom settings, or do some of the init scripts need changing for it?
I use the file /etc/conf.d/dmcrypt to decrypt additional partitions (/opt, /tmp etc.) with a key file which is on my root partition. The root partition is decrypted during the boot process with a passphrase. In order to use cryptsetup-1.1.3-r2 with these partitions, I upgraded to cryptsetup-1.1.3-r2, created a new key file and added it with "cryptsetup luksAddKey..." using the new version of cryptsetup. Now everything works again.
