forward-secrecy for email (Re: Avoiding RIPA)

[Peter Fairbrother]

Adam Back wrote:

[snip]
> (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,

Not in m-o-o-t, it's not stored on the box. The signing key is generated
from a user passphrase on logon, and there are some attacks against this,
but we try to defeat most of them, eg trojans and keyloggers, both hardware
and software.

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

Yes, and the senders to be assured that he does it!
> 
>>> [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/

Thanks, that's interesting.

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

There may be no real reason for this, but I'm happier just having one
signing key and one ephemeral key around at any one time. If there is a DoS
on the server to prevent the renewal of keys, you just delete the key. You
can't decrypt messages, but that's better than compromise. If you can't get
a key due to a DoS, then beware and don't send messages - you can't anyway!
> 
>>> [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.

m-o-o-t defeats both these attacks  :) , though BIOS trojans are still
possible if the user is inattentive.

-- Peter Fairbrother