forward-secrecy for email (Re: Avoiding RIPA)

[Adam Back]

On Thu, Oct 31, 2002 at 09:30:23PM +0000, Peter Fairbrother wrote:
> > I believe this is similar to the way omniva.com (formerly disappearing
> > inc) system works -- key management polcies are executed on a server
> > on the users behalf.
> 
> I don't know, their website isn't helpful. They claim "After expiration,
> these messages are unreadable (as well as all copies - wherever they
> reside)", but it's based on OE and Windoze... Do I detect a whiff of
> serpent?

I think there was once a better writeup somewhere.  Not sure where,
but from memory, what happens is the clients call home to the server
to have assistance in decrypting messages even after they've arrived
in the recipients mail box, I think.  Then when the sender's policy
dictates the corresponding key on the server is wiped.

Of course the recipient can by-pass this, but for people who generally
want the features it enables it provides some utility modulo the fact
that they have to trust the server.

> > Another way to get less immediate forward-secrecy is to publish a PGP
> > public key with one signature sub-key and a whole series of encryption
> > sub-keys which expire over time.  PGP will not use an expired
> > encryption sub-key.
> 
> I hadn't realised you could do that. However all earlier keys could
> be used by mistake, and the corresponding key might not be deleted
> for some time.

While pgp6.x has the annoying habit of encrypting to multiple keys
that match the userid string you give (frequently encrypting to
unintended people with similar names, as it doesn't warn you you've
given an ambiguous userid as pgp2.x does), it only encrypts with one
encryption sub-key per key.  I believe it will select lexically the
first unexpired encryption key, but can't test it on Ian's key because
it looks like all of the keys expired!

You can see the key arrangement though:

http://www.cs.ucl.ac.uk/staff/I.Brown/key.asc

pgp -kvv "Ian Brown"

Type bits      keyID      Date       User ID
DSS  1024      0xA127BBD5 2002/02/22 expires 2004/02/22
 DH  2048      0xA127BBD5 2002/02/22 *** KEY EXPIRED ***
 DH  2048      0xA127BBD5 2002/03/22 *** KEY EXPIRED ***
 DH  2048      0xA127BBD5 2002/05/16 *** KEY EXPIRED ***
 DH  2048      0xA127BBD5 2002/06/17 *** KEY EXPIRED ***
                                      Ian Brown <I.Brown@cs.ucl.ac.uk>

which shows the single DSS key and the multiple Elgamal sub-keys.
You'll notice the signature key expires still sometime out, so Ian
could yet add some more sub-keys to the key (to combat the
forward-secrecy against compromised machine you mentioned -- rather
than include all sub-keys at the begining).  (In practice right now it
would make limited difference because someone able to compromise your
machine could get your private signing key and issue fake new keys,
and the password used to encrypt the signature key is the same as that
used to encrypt the sub-key private keys.  An implementation could be
implemented to change this default).

It is the receivers responsibility to delete expired sub-key private
keys.

> > [1] Dan Boneh and Matt Franklin - "Identity based encryption from the
> > Weil pairing", crypto 2001,
> > http://crypto.stanford.edu/~dabo/abstracts/ibe.html
> 
> I'm worried about the existence of a what's effectively a trusted CA, even
> if distributed, in this (and all IBE) schemes.

I have some description of the non-interactive forward secrecy (NIFS)
problem and related literature here:

	http://www.cypherspace.org/adam/nifs/

basically when you use an IBE scheme for NIFS purposes the identity CA
role is assumed by the user himself.  There is an additional identity
creation step.

1. generate identity CA public key

2. generate N identities (one for each time period) and use the
identity CA private keys to compute the identities corresponding
private keys

3. delete the identity CA private key

4. publish the identity CA public key and a compact representation of
the N identities (eg. email address + date in some format).

then the current date is an input to encryption and decryption; after
a period has passed the corresponding identity private key is deleted.

> > [2] Jonathan Katz - "A Forward-Secure Public-Key Encryption Scheme",
> > Cryptology ePrint Archive 2002/060
> > http://eprint.iacr.org/2002/060/
> 
> The disadvantage here is that if a compromise happens and is not noticed
> then all subsequent communications are compromised. The initial unnoticed
> compromise can happen in many ways, eg covert examination of a box, an
> untrustworty but trusted person using a key, etc.

Right.  It's not clear how much difference there is between
forward-secrecy which recovers from compromise (due to fresh keys) and
forward-secrecy which doesn't in practice as the compromise event
could almost as easily have included keyboard sniffers, and/or
modifications to the software which would be used to recover
forward-secrecy.

Adam
--
http://www.cypherspace.org/adam/