[dm-crypt] 1.6.2 - waiting for zero, luksFormat hung

shmick at riseup.net shmick at riseup.net
Fri Nov 22 08:40:28 CET 2013



Milan Broz:
> On 11/21/2013 03:55 PM, shmick at riseup.net wrote:
>> ive also then tried with my distro default cryptsetup 1.4.1 but the same
>> errors again in xts mode with AES or TWOFISH
>>
>> any ideas ???
> 
> Did you modified udev device-mapper rules? If not, perhaps you should report
> it to your distro bugzilla if it doesn't work with default package.

no, i didn't modify udev
i've done some more testing and im very certain this an ascii character
issue with cryptsetup 1.4.3

i did test the following:

1.
will all the previous problems i was using 63 random ascii characters
i triple checked all of these according to the wikipedia 95 character
standards - they are all ok according to ascii tables

so i then tried with a basic password - it worked fine using identical
luksFormat setings when creating and opening cryptsetup 1.4.3 from a live cd

however, i could not later open this same volume within linux mint 13
amd-64 using cryptsetup 1.4.1 - same waiting for zero error

i don't know if different versions of mdadm affect this - i created RAID
using latest mdadm 3.3 - the live cd has an earlier version, but it
still opens and assembles the raid anyhow

2.
re-installed cryptsetup 1.6.2 in linux mint 13
./configure --with-libgcrypt-prefix=/usr/local LDFLAGS=-L/usr/local/lib

reboot

create volume
cryptsetup --debug --hash sha512 --cipher twofish-xts-plain64
--use-random --key-size 256 --iter-time 2000 luksFormat /dev/md0

try basic password with letters & numbers only

failed again, hung at 'waiting for zero'

same problem errors with failing to run benchmark

i don't understand how to get around this

desired outcomes:
i want to use a long, secure passphrase, formatting with
[twofish][aes]-xts-plain64 - to me it doesnt matter which cryptsetup
version i use as long as it works

but so far i can't use 63 ascii charaters in any of the versions ive tried

?

> 
> (The "waiting to zero" is in fact libdevmapper internal problem, cryptsetup is
> just an user here.)
> Usually it is caused byt removal of mandatory device-mapper udev rules.

what does this mean ?
how would i fix this for myself and what would i change regarding a udev
conf option ?

> 
> Cipher or dmcrypt configuration is perhaps not related to this.
> 
> Milan
> 


More information about the dm-crypt mailing list