Subject: Re: encrypted swap?
To: None <email@example.com, firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 06/05/2001 01:06:45
In message <200106050211.WAA18077@Twig.Rodents.Montreal.QC.CA>, der Mouse write
>There's no issue of too much data _we care about_ encrypted with one
>key, perhaps. But - to pick on the PGP private key example - a lot
>more than just the private key is encrypted with a given swap key. At
>the very least, the rest of the affected page is; in the scheme of the
>paper, anything else encrypting-swapped to the same (big) chunk of swap
>is. Even with per-process (or per-VM-object) keys, anything else
>swapped from that VM object is.
>And as I trust we all know that the more data you encrypt with a key,
>the easier cryptanalysis is. And in a seized-machine attack, the
>attacker can deduce exactly what the layout of the attacked process's
>memory space is, providing a good deal of known plaintext and a bunch
>more low-entropy plaintext.
Sure -- but do you have *enough* data for any interesting attack?
Linear cryptanalysis on DES requires ~2^47 bytes of known plaintext -- that's
not available here. Differential cryptanalysis is even less feasible.
There are no better attacks for this situation than brute force. But
if that's your worry (and *if* you think that your machine may be
seized by someone who's *really* out to get you, as opposed to a random
thief), you should use at least 3DES or (better yet) AES.
Mind you, I don't object to using multiple keys -- *if* it doesn't
complicate the code very much. One key per swap partition is simple,
given the amount of other state associated with each partition.
Changing keys is not nearly as simple, since you have to worry about
existing pages that are protected with the old key. Are you going to
keep it around? Read, decrypt, encrypt, and rewrite the page? Use a
key per process and copy it on fork(), while handling vfork() properly?
Sure, it can be done, but it's a lot messier, and to me not worth the
Now, suppose the TLAs have some lovely algorithm that can beat 3DES,
but only if they have a gigabyte or two of probable plaintext.
Further suppose that They really want *you*. Do they (a) reveal this
cryptographic feat (and thereby throw into doubt the security of the
worldwide electronic funds transfer network), or (b) pull a black bag
job and plant a keyboard sniffer or some mind-bogglingly clever kernel
hack or a fiendish back door in some part of emacs that even Stallman hasn't
looked at in a decade -- or just subvert the NetBSD development process
somehow. (Don't laugh -- did you see the report about an Apache.org
distribution machine being hacked, as a result of a previous
penetration of Sourceforge? How much code do you run that you got from
Apache and/or Sourceforge? Yes, the attackers were caught, and the
Apache distribution audited -- this time....)
--Steve Bellovin, http://www.research.att.com/~smb