Adam Back writes:
You could combine with the conventional ESK, then there would be 3
symmetric keys, and you would actually be encrypting the bulk of the
data in each file with a random key k1, that key would be encrypted
with k2 and ESK(k2,k1) would be stored at the begining of the file,
and k2 could be itself stored encrypted in the secret key ring,
encrypted with symmetric key k3 derived from the passphrase with a
hash function (storing: E(k3,k2)).
This three-level encryption sounds complicated, and there are some
problems. You are introducing new kinds of dependencies between files
which haven't existed before. Now, if you delete (or lose) your secret
keyring file, you won't be able to decrypt files that you encrypted
with a passphrase! (Modulo recovery issues - consider a personal
user who doesn't use any kind of recovery key.) Or what happens if
you want to use a different passphrase for different files? Now you
have to start putting multiple encrypted keys into the secret keyring.
We'd have to keep track of how many different passphrases you had used
for conventional file encryption, and see if your new passphrase matches
any you have used before.
It's a big change and it introduces new risks of data loss. I think
this is an idea which needs more thought before it could be seriously
considered.
Now to go back one post, the point of all the above discussion was
that you had a potential problem when a user expired and securely
wiped an old encryption key, say every 6 months, and didn't want to
lose mail archives. Does the above sound like a reasonable way to
solve this problem?
We have agreed that the current file formats basically will support
this, modulo the transparent-passphrase-change issue. The remaining
issues are mostly matters of user interface and software configuration.
With some mail UAs this system could work, while others won't support
it very well. If you are serious about permanently deleting the key
you have to be 100% sure that your system is foolproof and no data got
stashed away somewhere encrypted with that key. It is not a technical
issue but a matter of usability and practicality.
I would like to see our spec be flexible enough to accomodate the
various ways that people are going to want to use the system, and it
sounds to me like it is adequate regarding this point. Once we have
achieved this then, as they say, it is up to the market to decide.
Given the controversy surrounding these issues it seems best to keep
the spec flexible and able to support different ideas and approaches.
I realize that you are unhappy with features in PGP's latest products,
but you will have to take this up with management. I continue to believe
that this is not the proper forum for political discussions.
Hal Finney