Re: "Forward Privacy" for ISPs and Customers
At 10:13 AM 10/9/96 -0800, Timothy C. May wrote:
Something ISPs could do--and may do if there is sufficient customer pressure--is to adopt a policy of "forward secrecy" (to slightly abuse this technical term). That is, to have an explicit policy--implemented in the software--of _really_ deleting the back messages once a customer downloads them to his site. This means that _backups_ must be done in a careful manner, such that even the backup tapes or disks are affected by a removal.
One technical approach is described in: "A Revocable Backup System", dabo@cs.princeton.edu (Dan Boneh) and rjl@cs.princeton.edu (Richard J. Lipton) in The 6th USENIX Security Symposium Proceedings. Basically the idea is to encrypt the file on the backup (tape) and then lose the encryption key when you want to "forget" the file. ------------------------------------------------------------------------- Bill Frantz | "Cave softly, cave safely, | Periwinkle -- Consulting (408)356-8506 | and cave with duct tape." | 16345 Englewood Ave. frantz@netcom.com | - Marianne Russo | Los Gatos, CA 95032, USA
At 11:42 AM -0700 10/10/96, Bill Frantz wrote:
At 10:13 AM 10/9/96 -0800, Timothy C. May wrote:
Something ISPs could do--and may do if there is sufficient customer pressure--is to adopt a policy of "forward secrecy" (to slightly abuse this technical term). That is, to have an explicit policy--implemented in the software--of _really_ deleting the back messages once a customer downloads them to his site. This means that _backups_ must be done in a careful manner, such that even the backup tapes or disks are affected by a removal.
One technical approach is described in:
"A Revocable Backup System", dabo@cs.princeton.edu (Dan Boneh) and rjl@cs.princeton.edu (Richard J. Lipton) in The 6th USENIX Security Symposium Proceedings.
Basically the idea is to encrypt the file on the backup (tape) and then lose the encryption key when you want to "forget" the file.
Given that keys = data, this just transfers the problem from one set of data to another set of data. (Wanna bet a lot of ISPs would keep backups of the disk with the keys on it?) Granted, there's a compression factor, but the basic issue is not changed. If the ISP is trusted to not make backups of user files, and overwrites the disk, this is about as good as the vendor encrypting the files and then agreeing to "lose" the key. (Though let's hope he neither loses it, nor "looses" it (the common misspelling), by throwing it in his Dumpster trashcan, a la the infamous Mykotronx "losing" (and hence "loosing") of Clipper secrets.) --Tim "The government announcement is disastrous," said Jim Bidzos,.."We warned IBM that the National Security Agency would try to twist their technology." [NYT, 1996-10-02] We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
Tim May <tcmay@got.net> writes:
At 11:42 AM -0700 10/10/96, Bill Frantz wrote:
At 10:13 AM 10/9/96 -0800, Timothy C. May wrote:
[...] One technical approach is described in:
"A Revocable Backup System", dabo@cs.princeton.edu (Dan Boneh) and rjl@cs.princeton.edu (Richard J. Lipton) in The 6th USENIX Security Symposium Proceedings.
Basically the idea is to encrypt the file on the backup (tape) and then lose the encryption key when you want to "forget" the file.
Given that keys = data, this just transfers the problem from one set of data to another set of data. (Wanna bet a lot of ISPs would keep backups of the disk with the keys on it?)
They could always use public key crypto, and use the _user's_ public key for the users data, then the ISP hasn't got the private key to leave lying around, or to divulge in case of a supeona. The backups are for the _users_ benefit so this puts the onus of key management of encrypted backups where it belongs, with that user. Of course, as Ray (?) pointed out, an ISP is going to translate this into unnecessary complications, and won't bother unless someone offers a service differentiated on this point, and this kind of service gets popular. I'm sure that this would be easy to implement with unix, a shell script. If anyone wants one, I'll write it. (Just have a .pgp-backup file containing a PGP public key in any directories you want encrypted backups rather than clear backups, say) Adam [the rsa .sig just got smaller still] -- #!/bin/perl -sisN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsjxII*op" $/=unpack('H*',<>);print pack('C*',split('\D+',`echo 16i\U$k"SK$/SM$n\E$^I|dc`))
participants (3)
-
Adam Back -
frantz＠netcom.com -
Timothy C. May