[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
> 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:
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
re-installed cryptsetup 1.6.2 in linux mint 13
./configure --with-libgcrypt-prefix=/usr/local LDFLAGS=-L/usr/local/lib
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
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.
More information about the dm-crypt