Milan Broz: > On 11/22/2013 08:40 AM, shmick@xxxxxxxxxx wrote: >> >> >> Milan Broz: >>> On 11/21/2013 03:55 PM, shmick@xxxxxxxxxx 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 > > > No. Why ascii characters problem? > > "Waiting for zero" is situation where device mapper wait for semaphore > (used to synchronize block device creation) to reach zero, it is handled in udev rules > by generic device-mapper rules. > > It has absolutely nothing to do with passwords or ciphers in cryptsetup. I am afraid > you are mixing several problems together here. > (You should get "No key available with this passphrase" error and not hang if it is > passphrase problem.) why does luksFormat succeed using a simple short password and fail with a more complex, longer one ? this occurs in parted magic boot cd from 28-02-2013 > > BTW if you just need to open old container, do not compile own version and use > distro provided one (1.4 version is fully compatible here). i attempted to open with the distro provided 1.4.1 but it failed to open > > Anyway, adding cc to Peter who maybe know some problem in dm udev rules causing > this... > > And if you cannot run even benchmark, you are still loading wrong libcryptsetup library, > (cryptsetup: relocation error: cryptsetup: symbol crypt_benchmark_kdf - this > function was added later, in cryptsetup 1.6). what else needs to be modified for configure options for this to work ? > > Milan > > >> >> 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 >>> > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
