[Pkg-cryptsetup-devel] Re: What is the benefit of SSL/GnuPG encrypting keys instead of XOR?

[Max Vozeler]

On Wed, Mar 22, 2006 at 12:31:25AM +0100, David Härdeman wrote:
> Hi,

Hey David,

> I've just joined the list because I'm interested in adding LUKS 
> cryptoroot support to the Debian installer (partman-crypto that is).
> 
> So far I've been working on other components which are also
> necessary for this. Most importantly, adding luks cryptoroot
> support to initramfs-tools and klibc so that the initramfs can
> recognize and setup a luks encrypted root (see bug #348147).

Thanks for working on this :-) Great to see so much progress!
Let's hope the initramfs-tools maintainers will find time to review
the patch and apply it before too long. Have you also submitted it
upstream? If not that might be a good idea. In any case - please 
don't let the long silence discourage you - this is the way things
sometimes go in Debian unfortunately...

> I've followed the "Status of partman-crypto" thread with great
> interest, but I can't really understand what the benefit is of
> SSL/GnuPG encrypting keys which are stored on for instance
> removable media. 
>
> Presumably it allows for a kind of two-factor authentication
> (knowing passphrase plus having possession of removable media
> with encrypted key being necessary to access harddrive).

Yes, the two-factor authentication is one aspect. But more
importantly IMHO: By using keyfiles at all, we can generate the
actual keys from cryptographically secure PRNGs instead of deriving
them from hashes of user-memorizable passphrases. Since we can't
store those keyfiles in clear, either openssl or gnupg are used to
encrypt them - this could be done with other software too.

> However, exactly the same benefit can be acheived by simply XOR:ing
> the passphrase and the key stored on the media together.

I think in theory this could work, but note that I'm actually far
from an experienced cryptographer. I think in practice such a
solution could be problematic and will depend on how you arrive at
the data to XOR the key with.

If you XOR with a plain passphrase there would be a couple of
problems: The passphrase needs to be as long as or longer than
the key that it protects. An attacker who has access to the
encrypted disk could, knowing that the key is XORed with a user-
memorizable passphrase probably consisting of characters one can
enter on the keyboard, reduce the key space by just XORing the
keyfile with possible passphrases and trying those keys.

If you XOR with a hash of the passphrase, the output of that hash
function would too need to longer or as long as the key itself. In
practice you would either need to use a hash function that gives
sufficiently large output or would be restricted to keys as long as
the output of the hash function used (say 512 bits for SHA-512).
I'm not sure how this works in dm-crypt/LUKS, but at least for
loop-AES the actual keys are derived from SHA-256/384/512 hashing
the "input" key (the one that is stored encrypted in the keyfiles).
Such a scheme would restrict the "input" key to the size of the
hash function output, whereas with a gnupg/openssl keyfile you can
have arbitrarily large "input" keys to be hashed by loop-AES.

> The main advantage being that no extra binaries are needed on the
> initrd/initramfs/etc (GnuPG seems like a quite heavy requirement
> in early userspace).

Hmm.. yes. It seems easy to say that given the current size of
plain initramfs images generated by initramfs-tools, adding gnupg
or openssl wouldn't make that much of a difference - but that would
be fallacious, no? :-) Are initramfs images freed from memory
after boot? I know this was the case with initrds. If they are, I
think the large size could be bearable given that an encrypted root
filesystem is already quite special-purpose.

> Additionally, should the media with the key be lost or copied
> without the knowledge of the user, it is possible for the person
> who has gotten hold of the encrypted keyfile to attempt a
> brute-force attack as GnuPG use also means that it is possible to
> know when the correct keyphrase has been found.
> 
> In contrast, if the keyfile is simply XOR:ed with the passphrase,
> there is no way of brute-force attacking the key unless the
> attacker also has access to something which to test the result
> upon (i.e. the encrypted harddrive).

This is a good point, and indeed a downside of gnupg knowing
whether the passphrase was entered correctly. At the same time this
feature also improves usability a bit. I suppose how important this
is depends on the attack-scenarios we want to protect against.

If we assume that the attacker has access to the encrypted
harddrive at some point, it would be conceivable that he could make
a copy of the encrypted data as well. If he can't do that, the XOR
method (or openssl) would indeed improve security of the solution
compared to symmetric gnupg encryption. On the other hand, gnupg
can also encrypt the keyfile asymmetrically - and as long as the
attacker has no access to the gnupg secret key, this would protect
against this scenario as well. I can't estimate the difficulty of
breaking public key encryption compared to symmetric encryption
though. Does anyone here know more about that?

cheers,
Max