Hal Finney <hal(_at_)rain(_dot_)org> writes:
One problem with pgp -c in older versions of PGP is that all the files
are encrypted with the same session key (assuming all use the same
passphrase).
True. They have random IVs though, which helps. The conventional ESK
construct you described below is another way of having different keys.
Encrypted partitions such as SFS, PGPdisk, cfs, and so on seem to
manage with symmetric crypto, and indeed nearly have to for
performance reasons. (They also use various other tricks, such as
mixing in block numbers as IVs, using non-conventional modes etc).
Generally it is better to switch session keys frequently, which pgp
-e does for you (every file uses a different session key). Of
course we believe the ciphers we are using are strong, so it is not
a major security leak, but all else being equal it is good to have
the frequent rekeying.
If performance is not an issue, you can use pgp -e with a long term
storage-only key as you describe.
I think it was you who mentioned a couple of posts back that you
expected a storage-only key would be symmetric. It is mostly a
performance issue.
The new PGP conventional ESK (encrypted session key) packet works
something like this. It supports the use of a random session key k1 to
encrypt the data, with k1 then encrypted under a key k2 which is derived
deterministically from the passphrase. However it puts E(k2,k1) at the
front of the file, along with any public ESKs, rather than putting them
into the secret keyring.
Just depends on whether you want to have to recover each file
manually, or recover the lot at once. An ergonomics trade off. You
could do either. But it just seemed to me that if you have to call in
the company recovery key holder every time you find another file that
needs recovering (after you've forgotten the passphrase), that the
recovery key holder might get overworked. Or if you apply it
separately to each encrypted message in your mail folder, similarly
you don't want to call the overworked recovery key holder to look at
another old mail you decided you want to read.
I think your idea requires the use of the same k1 everywhere, which again
suffers from the problem of providing lots of ciphertext encrypted under
the same key.
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)).
You can have public key crypto if you want the performance penalty for
the extra assurance of a public key encryption function for the
encryption of k1. Doesn't affect main design point which is below...
It's not clear how much you gain by being able to change your passphrase
once a month if the files are still encrypted under the same old key.
You're going to increase your chance of forgetting a passphrase but you
don't seem to gain much security.
This isn't the point of it. The point of it is that PGP Inc has
stated the user requirement of recovery of local files in case the
user forgets their passphrase. You don't want to have to "recover"
each file individually, nor search the disk and "re-encrypt" all files
because it is inconvenient, and because many of them may be on a
backup tape or something. (Well you can if you want, but I think it
may seem more reasonable to a user if they could more easily recover
from a forgotten passphrase).
The scenario is that you have forgotten your passphrase to your
storage-only key (be that symmetric or asymmetric). You want to
recover the ability to decrypt those files, but you don't necessarily
want to have to choose the same passphrase again (you've forgotten it,
and if the hash is one-way, you can't re-create it from the key, an
alternative would be I suppose to actually allow recovery of the
passphrase.)
But anyway, I think it is nice to be able to change passwords in
general though because if you figure someone has shoulder surfed your
password during a demo, well you can just go change it. With what you
have suggested you would have to decrypt and re-encrypt all files on
the disk, and on backup media just to change the passphrase.
I presume this was the motivation for the password change feature in
SFS, which uses an indirection something like your conventional ESKs;
previous versions you had to wait for the disk to decrypt and
re-encrypt to change the passphrase. It's even worse for manually
encrypted files they may not be on the disk.
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.
PGP supports a mix of conventional (symmetric) ESK packets and public key
ESK packets (not in the UI yet, though). This will allow messages which
can be decrypted by any of a set of key holders, or anyone who knows
one or more passphrases. This could be used for encryption to a group of
people where some of them don't have public keys for some reason, but you
share a passphrase with them via some out-of-band means.
OK, so it directly supports what I described already.
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?
(ie encrypt the mail archive with the use of the "mix of conventional
(symmetric) ESK packets and public key ESK packets" you describe. Or
simply two crypto recipients, so all keys are asymmetric if you
prefer. One is your key, the other is to allow the recovery key
holder to recover your mail folder if you forget the key.)
So, now you can expire encryption keys easily without having to
re-encrypt anything... I think it works reasonably well, and means
that you never have to let storage recovery information go over the
wire.
This to me is the obvious intuitive way to acheive data recovery,
rather than include recovery information as a crypto recipient and try
to enforce that the sender do this.
The nice statement of intent flags can still be used on the public key
to say that the mail folder is planned to be stored recoverable by the
company.
(I think an advantage to using symmetric crypto to encrypt the
individual messages in the mail folder is that way once the key was
available, you could quickly scroll through and read encrypted posts
looking for one... the mailer I have now (emacs RMAIL w. mailcrypt.el)
it is quite tedious to search for something in an encrypted post: too
slow).
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`