forward-secrecy for email (Re: Avoiding RIPA)

[Adam Back]

On Wed, Oct 30, 2002 at 08:45:52PM +0000, Peter Fairbrother wrote:
> [...] that's the wrong way to go about it. m-o-o-t uses a
> publicly-readable database of ephemeral public keys that
> (user-transparently) change every time the recipient collects mail.

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.

Unlike with omniva where secret keys live on the server, in this case
if the server is coerced the worst it could do is deny service (by
continuing to give users expired public keys) as the private key is
created and kept by the user.

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.

Another simple, though not-comprehensive way to provide
forward-secrecy is to use mail servers with STARTTLS and
forward-secret ciphersuites.

There are also now efficient identity-based crypto systems [1] which
can be used to build non-interactive forward-secrecy schemes where the
user can have a single compact public key and an arbitrarily large set
of private keys which can be expired for example one-per day.

See also [2] for an example of how to apply [1] to create a
forward-secre public-key encryption scheme.

Adam
--
[1] Dan Boneh and Matt Franklin - "Identity based encryption from the
Weil pairing", crypto 2001,
http://crypto.stanford.edu/~dabo/abstracts/ibe.html

[2] Jonathan Katz - "A Forward-Secure Public-Key Encryption Scheme",
Cryptology ePrint Archive 2002/060 
http://eprint.iacr.org/2002/060/