Hal Finney <hal(_at_)rain(_dot_)org> writes:
Adam Back asks:
What happens in this scenario with pgp5.0, or pgp5.5:
[Replacement of encryption key and deletion of old private part.]
If you do this, you won't be able to read your old mail folder,
because you no longer have the key it was encrypted to.
Does this imply that you must keep the private key for perpetuity?
(Or at least as long as you want to read old mail archives).
These are good questions. The issue of dealing with retired encryption
keys raises many operational complications. Not only email, but any other
files which may have been encrypted with the key being replaced are at
risk of being lost.
I think this argues for the advantages of using symmetric keys for
storage encryption (pgp -c). I used to do this a lot myself. You
don't have the same need to update storage keys. Those files I used
pgp -e to encrypt to myself, I am now stuck with digging them all out
and re-encrypting them or losing them, if I did what I really should:
revoke and burn the key I generated back in 1993.
It could be that it will be appropriate to save the old private key
in some secure location. Because it would not have to be accessed very
often if at all, the secure storage could be made relatively inaccessible.
Not as good as deleting the key -- if you can recover it then the
attacker can coerce you into recovering it. Or some companies may
develop sloppy practices, and just leave the expired keys on the disk.
It's complex also, you've got to tell them how to handle this key,
explain why they need it; whereas removing the key is simple. The
expiry feature on the key that you described means that pgp5.0 already
knows what to do when it expires, so you have backwards compatibility.
Or perhaps software could sweep your disk to find data encrypted with the
old key, and re-encrypt it with the new one. Whatever solution is chosen
will have to be based on input from customers, so that we have a safe
and manageable way of dealing with retired keys.
The sweep the disk method sounds difficult to do reliably -- what if
there are some files on backup tape, or on floppy, or inside a zip
archive -- these may be missed.
One suggestion to get around this problem is to use an indirection:
Store the symmetric key used to encrypt stored files: key k1 in
encrypted form -- store the key k1 on the disk encrypted with key k2.
Key k2 is derived from the passphrase, k2 = hash(passphrase). This
allows you to change the passphrase without re-encrypting the files.
E(k2,k1) could go with the secret keyring. (This is what SFS does I
think).
For ergonomics reasons you might have an option of using the same
passphrase for protecting key k1 as you use to protect your current
private encryption key sk_i.
If all communications messages encrypted to pk_i (your current public
encryption key) were first decrypted (using private key sk_i) and then
re-encrypted with symmetric algorithm E and key k1 before being
storaged in mail folders, you could at any time safely delete an
encryption key.
With this setup, you could reasonably generate new public encryption
keys once a month even. This I think would be a significant security
improvement (over people like me still keeping private halves of 4
year old RSA keys).
My CDR proposal is this extension to the above:
Also encrypt recovery information so that your storage key k1 can be
recovered by second parties if you forget the passphrase. So also
within the private key ring you would store: RSA(pk_r, k1), where pk_r
is the public recovery key, for your company, or close friend, lawyer,
etc.
You could do secret splitting as an enhancement from that simple
functionality, in a similar way to what was discussed for the next
version of CMR style recovery.
The advantage of CDR style recovery it seems to me is that no long
term keys need to be kept which are protecting communications traffic.
Also the communication can be encrytped to a minimum number of
crypto-recipients. Communications traffic is much more vulnerable
than stored data, so these more short-lived keys, and avoidance of
more than necessary crypto-recipients who would be able to decrypt
seems appropriate, and more secure.
At the same time no-one is forced to use short lived encryption keys
if this doesn't suit them: they can use whatever they currently use as
default expiries. The recovery mechanism could still be centered
around storage keys as shown above.
Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`