In message <200106050211.WAA18077@Twig.Rodents.Montreal.QC.CA>, der Mouse write
s:

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

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