Tim May <tcmay@got.net> writes:
At 2:48 AM -0700 10/12/97, Adam Back wrote:
Once you acknowledge that it is more secure to have short lived communication keys (which in my view it very clearly is), it should be ...
Just what are some of the issues with us getting D-H-type perfect forward secrecy with something like e-mail? I assume this must be possible, of course, as D-H is used in just these ways. (The Comsec 3DES phone I have does this, of course.) (To repeat what has already been said, forward secrecy means some of the important keys are not kept or stored, and so a subpoena at some future time to produce the keys used in a communication is pointless. Cf. Schneier for more.)
First and foremost as a requirement would be the need for a back-and-forth communication, in a real-time or nearly real-time mode. This rules out conventional e-mail with its long a variable latencies for delivery. (Not to mention diverse clients and their inability to respond automatically!)
It is difficult to have true interactive PFS for the reasons you describe. I did spend some time trying to work out a DH variant which could do forward secrecy entirely non-interactively, but I couldn't find functions with the desired properties. If anyone is interested I can repost the discussions of this, and my current note pad style scribblings attempting to find said functions. I am not convinced it is impossible; perhaps some one will figure it out at some stage. (I have been having an intermittent on going discussion with Hal Finney on this topic on and off list for the last year or so). In the mean time what is entirely reasonable to do with email, with pgp5.5 is to use short lived communications keys. That is communications keys which are planned to live for 1 week, say. This would not result in immediate PFS as with interactive DH, but it will be PFS at the end of the week. You could do it more frequently if you wished. As pgp 5.0 uses key servers directly from the mail client (and some other clients do also), this all works out because you just publish your new weekly communications key on the keyserver, and this eliminates the need for interactive communications with your recipient which true DH PFS requires. In fact I think you could do this right now, if you made it clear to others that your key has short expiry in your .signature or whatever. As I mentioned in another post David Wagner currently does just this. In my last post in the thread with subject: Subject: Re: negative security aspects of GAK compliance I think I have proved that you can't sensibly use pgp 5.5 with short lived communications keys without also adding storage keys. People are acknowledging the logic that: 1. short term communications keys are more secure 2. it is a security mismatch to use long term CAK keys with short term communications keys 3. if you use short term CAK keys, you can't recover stored email for long 4. if you use short term communications keys the recipient you can't even read old email folders 5. therefore you need storage keys also 6. as a side effect PGP Inc's GAK compliant implementation of corporate access to stored email is fundamentally flawed, and has to be replaced with a different non GAK compliant method. (I'm working on that last point, it does follow, and I think the logic is sound).
Forward secrecy might be arrangable even with long-latency links...it seems to me. (Through a series of links, compute and store the D-H parameters, then use them with conventional e-mail for the "payload" message?)
That is another way to do DH, and also is entirely reasonable. You could have this automatically for example if you were using one of the IPSEC proposals which has forward secrecy at the IP transport layer. If the systems which your mail went through to be delivered all used IP level forward secrecy, the SMTP traffic would all be forward secret. However this form of forward secrecy has a different security focus; keys are owned by machines rather than people, which means that it is probably less secure. For example you are relying on the security of the recipients SMTP server. Also the last hop of the link, between the recipients POP3 mailbox, and the users dial up machine is unsecured typically at the moment. Some IPSEC security on this link (or SSH tunneling) also would be possible then allowing that last hop to be secured. However it is a bit like GSM mobile phone encryption, the links are secured, but the traffic goes in the clear through the base station. The traffic ends up in clear in the recipients ISPs POP3 mailbox. Of course, you would actually encrypt the payload email also; the setup is more secure than no forward secrecy, because with out tampering with machines. IPSEC with forward secrecy is a _really_ big win for our side, because it automatically defeats government GAK plans; what use is GAK for fishing expeditions if you can't get the ciphertext because all the links are protected with forward secrecy. It preempts GAKkers in an area where they have little control: IETF standardisation processes. The standards process I think refused to accept "for export" key sizes, on the grounds that the standards should not be weakened by political considerations. With an internationally agreed, widely deployed IPSEC standard with forward secrecy, the GAKkers will be screwed because to change it will eventually mean cutting yourself off from the internet, and there will be much software to unpublish, and much inertia to overcome. I presume it is for these types of reasons that John Gilmore and others are enthused with the tracking the IPSEC standardisation process, and in John's case in organsing his free S/WAN project to produce a free linux IPSEC implementation. 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`