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