Using pinentry-curses interactively in Linux boot process fails (SOLVED)
malte.gell at gmx.de
Sat Jul 24 21:53:08 CEST 2010
> 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
> Why not just use the same
> secure passphrase for the LUKS keyslot directly, instead of using a
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 316 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users