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

[Max Vozeler]

Hey David,

On Wed, Mar 22, 2006 at 09:23:51PM +0100, David Härdeman wrote:
> On Wed, Mar 22, 2006 at 04:54:20PM +0100, Max Vozeler wrote:
> >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.

I'm always happy to hear positive feedback :-) 

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

Building the image is actually quite simple. I hope this covers 
all required steps - and of course this is targeted at building a
loop-AES installer image for now:

  $ svn co svn://svn.debian.org/d-i/trunk d-i
  $ cd d-i/installer/
  $ dpkg-checkbuilddeps  # install what's missing
  $ cd build
  $ cat > pkglists/local <<EOF
partman-crypto
cdebconf-newt-entropy
loop-aes-${kernel:Version} [2.6]
mount-aes-udeb
gnupg-udeb
EOF

This should be all that's required to get the installer ready to
build. In case I missed something you can check build/READM,E, and
please let me know so that I can put a working recipe on the wiki.

Since partman-crypto is not uploaded yet you will also need to
build it and copy the .udeb into d-i/installer/build/localudebs/
The same goes for gnupg-udeb:

  $ cd d-i/packages/partman-crypto
  $ debuild -I.svn -us -uc

  $ apt-get source gnupg
  $ cd gnupg-*
  $ patch -p1 < patch_from_bug_321948
  $ debuild -us -uc

Once you've copied the resulting udebs into localudebs/, you can
build a small "netboot" iso like the snapshots I put online:

  $ cd d-i/installer/build/
  $ fakeroot make build_netboot
  $ ls -l dest/netboot/mini.iso

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

Sounds good! I'm looking forward to seeing the patch in
initramfs-tools.

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

What happens if you XOR with a shorter passphrase? Unless you
repeat the passphrase up to the length of the key, parts of the key
will be be left un-XORed. And if you repeat the passphrase - apart
from allowing an attacker to make guesses about the redundancy -
what happens if the passphrase is very short, say 1 character?
Where do you draw the line?  ... along these lines.

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

Hmmm... right. 

I was gonna say that XOR is much less expensive than CAST5/AES/..
but to brute-force the XORed key one would need to do $cipher
operations on the encrypted data anyway, so there is not much
difference.

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

This is a non-issue if the "input" keys are strongly random. If you
can make meaningfull guesses at the content of the "input" keys,
attacking those may be easier than attacking the actual encryption
keys. In that case fixing an upper boundary of their length would
make guesses easier. 

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

If glibc gets dropped, we could still resort to linking the
gnupg/openssl binaries statically.

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

Ah, OK. This is different for loop-AES, it has no such checks
outside gnupg. All the users gets to see is the failed attempt of
mount to determine the filesystem type.

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

Yes, I meant public key encryption. 

In practice many people would probably store the gnupg secret key
on a removable device and keep the keyfile stored on the harddisk.
I've not seen that used for encrypted root, but I suppose if we go
to the trouble of accessing a removable medium at that stage of
boot, accessing another doesn't increase the work by much. 

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

Thanks for the pointer! I actually saw the article before but only
skimmed through it at the time. I will try to find time later to
read it in more depth. Unfortunately at the moment I'm swamped with
work of all kinds and need to get some sleep for a change :-/

cheers,
Max