forward-secrecy for email (Re: Avoiding RIPA)

[Peter Fairbrother]

(apologies if duplicated)
Adam Back wrote:

> 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.

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?

> 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.

Yes.

> 
> 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.
Alternatively, a demand for all keys could be made. Any later messages could
then be intercepted and decrypted, if the sender didn't realise the keys had
been compromised.

The m-o-o-t scheme changes keys when mail is received, rather than at a
particular time, and could be set so no new messages can be sent if someone
has not collected his messages for a set interval.

This exposes the times someone collects his mail, but at least you know that
keys are being deleted...

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

Not comprehensive, yes. Do you know of any good ones?

> 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

OWWWW, MY BRAIN HURTS!

I'm worried about the existence of a what's effectively a trusted CA, even
if distributed, in this (and all IBE) schemes.

> [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.

-- Peter Fairbrother