I guess it's quite common to have different restrictions on access to both old no-longer-used hardware and tape backups than for physical access to the server room.
As for per-uptime keys, I don't like the idea that if I edit a secret message, then someone who breaks in and gets root some half a year later might be able to get it. The property I'm after is usually called "forward secrecy": The enemy should not be able to get my data by an attack long into the future. One reason to want that is that it's really hard to tell how hard the future attack will be.
It's better if the key is permanently destroyed when I close my editor process, or at least within a few hours or days.
/ Niels Möller ()
Previous text:
2003-01-28 14:24: Subject: Re: OpenSSL wrapper vs Pike's SSL (Was: Bz2)
When I break in and steal your swap disk (or get it from a container after you have replaced it). As you say, it's futile to try to protect oneself against a real time attack that requires root privs.
But why not steal the system disk where the key is in it's "key.txt" or similar file? Not many server systems requires keys external to the system (ie passphrases and magnetic cards) to get going.
Of course, session keys could be interesting if you want to know what was said in a session, I guess.
Still, if I had that sensitive transmissions I wouldn't leak swap disks. I recall some military installation with a remotely controlled explosive bolt to blow up the sensitive HDD.
To me, the only sane way to handle the non-real time attack is to make sure that pages are encrypted before they are swapped to disk. Using temporay keys that are destroyed regularly, preferably directly at process death.
It seems simpler that have one random key per up period, and it would work just as well - all swap data gets worthless once the system goes down, and no non-root system process can read out the key from the kernal anyway.
/ Mirar