[gentoo-user] Re: Kernel upgrade and now LUKS failure

["Stefan G. Weichinger" <lists@xunil.at>]

Am 18.05.2010 19:57, schrieb Jan Engelhardt:

>> 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 ...
> 
> Yes. The point of keyfiles is to be able to change the password on
> a volume.
> 
> Without a keyfile, a crypto program would take the password, hash it
> somehow, and you get your AES key. Changing the password means having
> a different AES key, meaning decrypting the disk will yield a
> different result. In other words, changing the password would require
> at least reading the old data, reencrypting it and writing it again.
> Takes time.
> 
> With a keyfile, you retain the same AES key all the time, and encrypt
> the AES key itself - reencrypting the AES key is quick, as it's
> only some xyz bits, not terabytes.

Ok, I see. So my current setup with one disk only and SSL-generated
keyfile does not add security but flexibility (being able to switch
passwords more quickly).

Do you see a way of getting this working with my current packages:

pam_mount-2.1
sys-fs/cryptsetup-1.1.1_rc2

and LUKS ... ?

As mentioned the old keyfile works with pam_mount-1.33, when I check the
changelog at

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-auth/pam_mount/ChangeLog?view=markup

this is a package from 10 Jan 2010, so maybe it wouldn't be too risky to
just mask >pam_mount-1.33

-

On the other hand I would like to get that done right, sure.

Any howto without pmt-ehd that would keep me safe from newlines etc
(btw. there were NO newlines in that hexdump-output)?

Thanks for your time, Stefan