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

[David Härdeman]

On Wed, Mar 22, 2006 at 04:54:20PM +0100, Max Vozeler wrote:
>On Wed, Mar 22, 2006 at 12:31:25AM +0100, David Härdeman wrote:
>> 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!

I should be the one to say thank you. I recently tried your latest 
debian-installer iso image with crypto support using qemu, and it 
indeed seems that 80% of the pieces are in place and that the rest 
should be trivial once initramfs has support for cryptroot and there is 
a cryptsetup udeb.

Incidentally, what are the steps you take to create that image? It would 
be helpful to be able to create one myself when I start hacking on 
partman-crypto in earnest...

>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...

No problem, Maximilian has been good at keeping me up-to-date on the 
status of initramfs-tools and what the issues are. As for upstream, it's 
Ubuntu and I think they are well aware of the patch.

>> 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.

Of course, in the end we can let the user decide. The initramfs patches 
I've made allows for a custom made script to be placed in 
/etc/mkinitramfs/cryptgetpw which is expected to do whatever is 
necessary to get the key and then output it to stdout.

>> 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.

Neither am I :)

>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.

Why would the passphrase need to be as long as the key??

>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.

I do not see the difference to brute-force attacking the GnuPG/SSL 
encrypted key here (i.e. brute-force attack with possible passphrases).

>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.

What is the point of an arbitrary key which is anyway hashed and 
truncated to the length of the key used to encrypt the on-disk data??

>> 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.

I do not know if they are free'd, but I certainly know that they can be 
free'd and if they are not, I'd expect it to be on the TODO list of 
initramfs. However, on the TODO list is also to remove glibc dependent 
programs altogether and to move to klibc with utils. A small xor binary 
would be trivial whereas GnuPG/SSL wouldn't.

>> 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.

Once again, I beg to differ :) The usability is there even with an 
XOR'ed key as it is possible to check the device-mapper encrypted 
partition for a valid file-system signature after the key has been 
provided (this is how it's currently done in the patch I've written).

>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. 

By asymmetric, I guess that you mean via a private/public GPG key. How 
would you supply said key during the boot? One the same removable medium 
as the encrypted partition key itself?

>I can't estimate the difficulty of
>breaking public key encryption compared to symmetric encryption
>though. Does anyone here know more about that?

RSA has some analysis and comparison of this available at 
http://www.rsasecurity.com/rsalabs/node.asp?id=2088 (it's somewhat 
dated, but much of it still applies, scroll down to table 2 for a nice 
overview).

>cheers,
>Max

Regards,
David