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

Reply via email to