Using pinentry-curses interactively in Linux boot process fails (SOLVED)

[Malte Gell]

Hi there,

> Besides, holding a GPG encrypted keyfile on unencrypted space to open a
> LUKS/dmcrypt encrypted device, opening/decrypting the keyfile in the boot
> process by entering the correct passphrase, to finally open the
> LUKS/dmcrypt secured device seems broken to me. 

Can you explain, why this setup is broken? The keyfile consists of 4 kBytes of 
random data and is encrypted with my PGP key, which itself is a 1024 bit RSA 
key, thus the security of my encrypted partition basially is as secure as my 
PGP key.

> Why not just use the same
> secure passphrase for the LUKS keyslot directly, instead of using a
>  keyfile?

The idea behind the whole thing is, that the openPGP pin is much easier to 
enter than a long password/phrase and if you use the openPGP card you simply 
need a keyfile to have a token that you use openPGP upon.
 
> Seems a little bit like "security by obscurity" to me..

I'm sorry, but this is pure nonsense. This setup is secure. The keyfile is 
openPGP encrypted and when decrypted, it is piped to the cryptsetup command. 
There is no security hole. An attacker who gains access to the hard drive 
would have to break the openPGP encrypted keyfile.
 
> (Malte: I hacked a lot on the opensuse bootscripts related to LUKS/dmcrypt
> in the last 2 years, if you need to customize your system in such a way
> that is not possible to achieve with the opensuse installer, feel free to
> drop me a note)

Well, I now achieved what I wanted to achieve. The number of people who own an 
openPGP card is very small so I think a small howto would be enough for these 
folks.

Malte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100724/4c1fdc5b/attachment-0001.pgp>