I also was pondering this question as to which purpose the current "encryption key" could be used for; should it become the "communications key", or should it be the "storage key". Clearly it could be used for either; and is in fact currently used for both, which is where the security problem arises. What you have described (very clearly as always) is the case for making the current "encryption key" the "communications key". You are forced to make this choice because there is only one key available, and without a communications key .. well you can't communicate :-) However this leaves the question: what do you use for a "storage key"? To see why this argument is important, you can see that you have painted yourself into a corner where you will be forced to admit that you need to have separate storage and communications keys. Probably this doesn't bother you as you didn't react adversely to my earlier description of how it was a good idea to separate key functionality. Let me quote: Hal Finney <hal@rain.org> writes:

This should facilitate more frequent changeover of encryption keys as Adam Back describes, which can be good security practice. It is a significant improvement provided by the new key structures of PGP 5.

It is indeed. It is also very good for another reason: it allows corporate escrow of encryption keys without simultaneously allowing the company to forge signatures. However you have created a problem for your self in the following argument which suggests that you must have two encryption keys; one for storage and one for communication. It also suggests that my method for achieving corporate recovery of email is better acheived without the GAK compliancy field (second recipient) which was my earlier point.

Adam wrote:

...

This argues that if people are to insist on using the enforced second recipient model for corporate snooping at all, they should for security reasons be at least using short lived communications keys for the GAK compliancy packet also.

That sounds reasonable, at least if the first recipient is also using short lived keys. Presumably these kinds of policies would be established by the corporate security office. But certainly if one class of keys uses short lived keys then it would be logical for the other class to do so as well.

By doing it this way you do claw back some of the security lost by having a second crypto recipient, as you say. However you now can't recover communications past the expiry date of the short lived corporate key. As the whole point of corporate message recovery is to guarantee message recovery of stored messages (or at least this is the user requirement Jon Callas gave in his post explaining the need for CAK), you have just thrown away much of that ability. This is an extreme pity because you are now faced with a dilemma. Your dilemma is, do you: a) use short lived encryption keys (for both user and corporate master key), and have good security but limited recovery of stored encrypted email after that short period. Also the poor user won't be able to even access, never mind recover his stored encrypted email! b) or do you use a long term encryption key for the corporate master key, and hence good recovery of stored encrypted email, but poorer security (and as an additional disincentive end up building a GAK compliant system.) This dilemma highlights really very well my point as to why you really do need separate storage and encryption keys. Introduce them, and both problems vanish. You can then: - Have short term communications keys for the employee - Have long term storage keys for the user escrowed with the company - Have long term key recovery storage key for the company It's beautiful, everything falls into place, and it's more secure. Also as a convenient side-effect the way that you build a corporate stored message recovery scheme under this system is non-GAK compliant, which saves you from being screamed at by cypherpunks, and from being dissed in the NYT and other places. Presumably given Jonathan Seybolds clear statement of PGP's aims: Jonathan Seybold <jseybold@pgp.com> wrote:

With regard to GAK, the objective should be to accommodate legitimate corporate needs without setting in place the foundation for GAK.

this side-effect of removing the GAK compliancy should therefore be very pleasing to PGP also. The way that you implement corporate recovery of stored encrypted messages once you accept the clear need for separate communications and storage keys is easily derivable from new the key purposes. It is basically as easy to circumvent as the previous GAK compliant method. Several PGP employees commenting on this didn't seem to think enforceability was that big a deal. (I agree with them: if all it takes is to super encrypt with PGP itself, it's not worth losing sleep over.) Here's how to do corporate recovery of stored encrypted messages, now with the new separated storage and communications key functionality: 1. Corp. employee receives encrypted email, the email is encrypted to the employee's short life time communications key. - employee decrypts email with pgp5.6 client - pgp5.6 client encrypts the plaintext to users long term storage key, and to the companies recovery key as a second "storage-recipient", and places in received mail folder 2. Corp. employee sends encrypted email - The pgp5.6 mail client encrypts plaintext of email to users long term storage key and to the companies long term storage recovery key and stores in the sent email folder - The pgp5.6 mail client encrypts the plaintext of the email to the recipients short lived communications key and passes on to the MTA 3. Normal user access of encrypted stored email - user's email client decrypts stored email with users storage key 3. User forgets password, or dies, or leaves in a huff, company needs access to stored email - company uses company recovery key to decrypt users stored email An alternate set up would be to escrow the users long term storage key with the company. Basically equivalent. But I think it is probably easier to use multiple recipient as it saves the headaches of having to securely transmit 10000 users storage keys securely. Much easier to install the software with the department/company recovery key bound into it, and to remote update the company recovery key by fetching the new from the company key server when it expires. There are lots of other issues of course, with regard to architecture of recovery setup. However there is a basic equivalence between key escrow and session key recovery methods, and you can acheive all kinds of departmental escrow jus the same as you could with the previous system.

Actually it's likely that the corporation will change its shared access keys more frequently than user keys, at least if they are using an access model where there are relatively few shared keys. It will be easier to change a few keys which are controlled by corporate officers than to get every one of 10000 employees to generate a new key every week.

I can't see any reason why you would not be able to entirely automate and hide the process of generating new communications keys every week, every day, or _every communication_. The process can be handled automatically by the software. With El Gamal you have a very computationally cheap way to generate keys other than the first key; discard the private components, and treat the public modulus as a pre-computed prime as you currently do for the fast key generation option on EG key generation. I feel somewhat better about this post than previous ones; I haven't been rude to PGP, and I feel some progress has been made in clarifying things. Perhaps it's just interacting with Hal, who always was one of the most level headed people on cypherpunks; it's much harder to pick faults in what he says, and he doesn't make ill thought out political statements. I think there are still some issues to resolve if we start to talk about "per communication" communication key updates, but for per week, or per month or whatever, I think the above is good. 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@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`