Now that we're considering (within the IETF OpenPGP standardisation framework) the prospect of having a separate communications key, and storage key, there are some aspects of communications keys which are currently less than ideal because of their current misuse to also function as storage keys. This argues for a new functionality to be given to communication only keys. This is all tied up with the idea of Perfect Forward Secrecy (PFS), which is basically the statement of the fact that communications keys are more sensitive than storage keys, because your attacker by definition has a copy of the encrypted communication. (You're sending over an open network where copying all traffic is a low cost exercise for a savvy system cracker, or spook, or industrial espionage). In contrast an attacker often will have to break into your premises to obtain the data protected by your storage keys. Another aditional vulnerability of communication keys is that the US government is very interested in obtaining copies of them via their "key escrow"/"key recovery"/GAK initiative. The strongest anti-GAK statement you can make is to use forward secrecy. I've raised this point before, but the meme doesn't seem to have penetrated yet. Hal Finney <hal@rain.org> wrote:
Adam mentioned the idea of forward secrecy in email communications. I'm not sure how that would work technically, but it sounds like an interesting possibility.
It ties in quite well with what is in my view proper handling of communication keys. If we can break the tie with one key being used for both storage and communication, we can start to reflect in the protocol better security practice in the handling of communication keys. Forward secrecy is one way of looking at it. It doesn't have to be real interactive forward secrecy as you might get in an SSH session, or an SSL session, or some of the IPSEC standards, though these are other examples which could server as examples showing that forward secrecy is a good idea, for anyone who would like to argue against it. The basic principle is that you want to have communication keys which don't live for a long time. So one form of weak forward secrecy you could have would be to mark your El Gamal or RSA communications for much more frequent update, by giving it a short expiry date. Say once per week. Some people currently do this manually anyway. For example see Dave Wagner's web page (www.cs.berkeley.edu/~daw/) where he describes what he does with keys. (He has a long term signature only key which he uses to sign short lived "communication only" keys which he discards after expiry). What I am arguing for essentially is building this kind of improved communication key handling into the OpenPGP spec for keys marked as "communication only". In addition I think it would be nice to enable a new kind of communications key which is based on discrete log so that people who choose to use PGP protocols for more interactive email transfer protocols than SMTP can generate keys very quickly. I was originally thinking that this would have to be DH, but perhaps you can simulate DH PFS with El Gamal by securely wiping the private parameters of expired communications keys, and keeping the public modulus and g value. (This has similarities with the quick method in PGP5.x of generating El Gamal keys with precomputed shipped primes that you already have). The advantage being that you may be trying to generate keys frequently, so you may not want to wait for a full new 4096 bit El Gamal or 2048 bit RSA key generation, when you are not anticipating the sudden delay in sending messages. I was originally thinking it would be done by having a new DH key type (in addition to RSA, El Gamal, DSA). (Incidentally Hal, you may recognise in this the reason for some of my annoyance that PGP Inc is mislabelling El Gamal as "DH" -- with my earlier ideas on this proposal there would have been a _real_ DH. It also gets around objections to do with not being able to decide what DH keys are (as they are negotiated not randomly generated directly) which Hal raised as a reason why PFS (at least with DH) would disallow functionality where key capabilities are included in the public communications key encrypted packet, the last time this was discussed. Clearly you could work around this restriction if you had to -- just include the information in an extra packet encrypted with the contained key and some symmetric algoirthm for example, though this may limit algorithm choice at least for that packet). You can use PFS in an asynchronous "where possible" mode for non-interactive email transport situations. That is you would perhaps send new communications keys parameters with each message that defines in it's key sub-packet preferrences that it is capable of using communications only keys, and will be able to handle "recipients comms key as part of message". This might make sense where comms keys are being updated too quickly to burden a key server with, or where comms keys are not public (an aditional use for Hal's described no-export flag for signatures, but here applied to communications keys), but are specific to that communicating pair. (For paranoid people who are changing comms keys on each receipt, you would need to do this). As soon as one party has replied to a mail from the other, you can switch to forward secrecy. This would lead to emails such as "hi, can you reply to this message please". These are kind of similar to the "hi can you send me your public key" you get back from people when you haven't included your public key in your mail to them, and they don't have access to a keyserver. You can also then use this new "communications only" key setup to cope with fully interactive email delivery for systems using email transports other than standard SMTP. You should probably overlap sending communications keys if you aren't relying on keyservers due to frequency of key update, or for convenience for people without access to keyservers, so that the person sending you email is less likely to have no current communications key for you if you are using keys sent in the message. So towards the end of the month (if you had a policy of using communications only keys with monthly updates) replacing keys monthly start sending the next months communications key also, marked as not for use until it's starting date. (The use of very transient communications keys I think would imply a need for two communications keys: you'll need a long term communications key which is used for initial non-PFS mail in order to set up PFS.) With the separation of storage and communications keys all the architecture has much better security decisions: - We are able to treat communications with variable amounts of sensitivity, by giving different key expiry time periods to comms only keys. - We are also able to secure and escrow our long term data storage in mail box folders, or PGP encrypted files without having to live with a GAKware compliant implementation of snoopware. We can storage escrow keys appropriately without all the name calling and bad PR caused by enraged crypto anarchists, and crypto consultants. You _know_ it makes sense :-) 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`