Am 18.05.2010 18:04, schrieb Jan Engelhardt: > > On Tuesday 2010-05-18 15:44, Stefan G. Weichinger wrote: >>> >>> To be sure, use >>> >>> openssl -d ... | hexdump -C >>> >>> to detect newlines in the key. The shell has far too many occasions >>> where \n gets stripped or added. >> >> Thanks for the hint. >> >> Could you please show me an example how it should look like and what to >> look for? > > In case the key is a suboptimal ascii-only key, it looks like this. > > offset bytes broken up visual represent. > 00000000 35 34 28 5e 52 69 4c 22 3c 72 4c 35 35 27 70 32 |54(^RiL"<rL55'p2| > 00000010 39 59 48 21 3b 50 2e 25 52 6e 27 4f 4d 51 42 6b |9YH!;P.%Rn'OMQBk| > 00000020 34 43 38 76 4e 49 51 24 3f 5e 42 63 2f 6c 2d 76 |4C8vNIQ$?^Bc/l-v| > 00000030 34 7d 4d 6a 50 5c 41 3c 3f 70 76 67 22 57 21 6b |4}MjP\A<?pvg"W!k| > 00000040 77 78 5c 24 23 5e 2e 56 7a 56 24 5a 4f 7e 6a |wx\$#^.VzV$ZO~j| > 0000004f > > If there were a newline, one of the bytes would be 0a.
Will check ... >> Do you know any howto where it is done "the right way"? > > The right and easy way is to just use the supplied pmt-ehd(8) tool, > which works both interactively and non-interactively, depending on > whether it's called with enough arguments or not, so there's something > for everybody's flavor. > It does not do LUKS yet as of pam_mount 2.2, though. Guess my > todo list gets longer.. :-) But given the fact that I store the key on the same hard-disk with the shadowed user-pw I could also leave that openssl-part straight away, correct?? seems the same level of (in)security to me ... thank you, Stefan