Hi all. Thanks to Your suggestion I've isolated two kind of problems (but I think they may be related): 1) sudo /etc/init.d/cryptdisks-early start * Starting early crypto disks... Enter passphrase: * sda10: keyfile not found * sda10 (invalid key)... [ OK ] For my knowledge, it means the crypttab was readed correctly by system, but... path is too long? (Rights are correct - I've just checked) - This happens also during system startup. 2) sudo cryptsetup create sda10 /dev/sda10 --key-file=/mnt/"long_path_to_my"/sda10 Command failed: Key processing error: Could not read 32 bytes from key file So, may be system expect a 32bit key, also if I've use a shortest one and this is the reason for which auto-mount fails during startup? Is there a way to explain it that: ok the key is shortest of what do You expect, but... please don't say it anymore? :) Thanks for your help! Cheers... Salud! Pierino, la peste. Info di servizio.. http://utenti.tripod.it/Pierino_lapeste/ E' l'indirizzo della mia home page.. utile a chi ha intenzione di rinfrescarsi la memoria sui modems. Ringrazio tutti i volenterosi che vorranno aiutarmi a migliorarla! --- Mar 30/12/08, Jonas Meurer <jonas@xxxxxxxxxxxxxxx> ha scritto: > Da: Jonas Meurer <jonas@xxxxxxxxxxxxxxx> > Oggetto: Re: Re: trouble managing key.file > A: dm-crypt@xxxxxxxx > Data: Martedì 30 dicembre 2008, 00:40 > On 29/12/2008 Dick Middleton wrote: > >> if you give the keyfile as argument with > --key-file=key.file then it's > >> processed different. would need to to look at the > code to tell you the > >> exact difference. > > > > Is it? Works for me. But then if you use > --key-file=key.file you'll use > > it the same way every time so the difference won't > be noticed. > > you can prove it by giving it a try: > > # echo -n > "somepassphrasewithmorethanthirtytwobytes" | > cryptsetup create ctest /dev/vg_int/ctest --key-file=- > # dmsetup table --showkeys ctest > 0 204800 crypt aes-cbc-plain > a9c8fd46e6ccffc01b0f91e63c278b40a7973dce8cc2cd18e4f49717390e07ff > 0 254:6 0 > # cryptsetup remove ctest > > # echo -n > "somepassphrasewithmorethanthirtytwobytes" | > cryptsetup create ctest /dev/vg_int/ctest > # dmsetup table --showkeys ctest > 0 204800 crypt aes-cbc-plain > a9c8fd46e6ccffc01b0f91e63c278b40a7973dce8cc2cd18e4f49717390e07ff > 0 254:6 0 > # cryptsetup remove ctest > > # echo -n > "somepassphrasewithmorethanthirtytwobytes" > > test.key > # cryptsetup create ctest /dev/vg_int/ctest > --key-file=test.key > # dmsetup table --showkeys ctest > 0 204800 crypt aes-cbc-plain > 736f6d6570617373706872617365776974686d6f72657468616e746869727479 > 0 254:6 0 > # cryptsetup remove ctest > > As already mentioned, I cannot tell you the exact > difference, but the > tests above seem to prove my assumption. A quick look at > the source > tells me that tty, fd or binary stdin input is hashed if > requested while > keysfiles given as argument aren't: > > --- snip lib/setup.c --- > /* > * Password processing behaviour matrix of process_key > * > * from binary file: check if there is sufficently large > key material > * interactive & from fd: hash if requested, otherwise > crop or pad with '0' > */ > > static char *process_key(struct crypt_options *options, > char *pass, int passLen) { > --- snap lib/setup.c --- > > so maybe the idea by the original poster (mum laris) to put > the hashed > passphrase into a keyfile wasn't too wrong after all. > i've not the time > - and with my rather limited programming skills it takes > far too long - > to check the code now. > > greetings, > jonas > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
