On Mon, Sep 29, 2014 at 8:56 AM, Natanael <[email protected]> wrote: > Den 28 sep 2014 17:21 skrev "Phillip Hallam-Baker" <[email protected]>: >> >> The part I have not worked out yet is how to manage escrow of >> decryption keys. Which is an essential requirement that is in conflict >> with other requirements. It is easy enough to make a scheme escrowed >> or escrow free. What is hard is to allow the user to easily choose >> between them. > > Don't escrow private key material. Allow for specification of which entities > that have the authority to declare a new key as the successor of your > previous one, and conditions such as n-of-m chosen entities is required and > that the declaration must be put in that Big Log.
If you want regular people to use end to end encrypted email, the risk that they lose access to their data and their pics is vastly more serious than the risk of government intercept. What I did think of though was a scheme where the private keys are stored in a 'deniable' format. So lets say that we generate a key pair, ke, kd, an identifier I and recovery code R. We store pairs [I, E( kd, R)] in a hash database. to recover the data, the client presents I and gets back E(kd, R). We can form I at random or we can derive it from the recovery code I = H(R). Point is that we can't know whether or not kd is escrowed. It may be but it might not. _______________________________________________ Endymail mailing list [email protected] https://www.ietf.org/mailman/listinfo/endymail
