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`

William Geiger <whgiii@invweb.net> writes:

at 02, Adam Back <aba@dcs.ex.ac.uk> said:

...

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.

Have you considered the logistical nightmare that this would cause?? I can see that you are unaware of the precarious state the current PGP Public Key Server Network is in.

The keyservers using pgp2.x as the key lookup engine are struggling because the database code isn't very good. But the experimental MIT keyserver, and Tage Stabell-Kulo's key server code on the key server in Norway fairly whistle through key lookups. PGP Inc also is using the better keysever code -- I think based on the one at MIT implemented by Marc (surname escapes me right now).

Right now it is getting by but this increase in load would bring it all to a screeching halt.

It all depends on how up to date you are on keyserver performance problems; perhaps you are more up to date than myself, perhaps not. The answer I think which must come in any case is a distributed key server system because the current 100% replication method seems unlikely to scale to likely future demands, with or without forward secrecy. If your company holds keys for it's employees on it's openly accessible key server, this distribution will be very similar to DNS, and similarly scalable.

There have been suggestions of moving key distributution to the DNS but I seriously doubt even it would handle the traffic.

I think this is taking it too far. Have you considered how much traffic DNS handles right now? I would have thought it would be many orders of magnitude more than forward secret email is going to cause. Web traffic is the bulk of network communications, just imagine the DNS lookups caused by 50 million netters clicking away. Bear in mind also hear that most users will probably be entirely satisfied with a communications key update time of 1 week. It is probably mostly cypherpunks, or people with high value communications to secure who would opt for more frequent key updates. Bear in mind also that once the new key has been issued, you could also release a deletion request for the previous one on the keyserver in the form of a revocation certificate.

Also what happens to the "web of trust" in such a system of high key turnover?

Nothing. It is unaffected. The WoT is only based on signature keys. You personally certify your communication with your signature key.

Exactly how much added security is provided by all of this??

Lots. Consider: you are the average PGP user, you have one key generated per year if you are lucky (probably more like once per life time). You are in a company, and the company has a heck of a time persuading people not to use dumb passwords, or leave their passwords on yellow sticky notes conveniently stuck to the corner of the screen. Scenario: the cleaner is bribed to switch on a machine with a supplied boot floppy to put in the drive, and writes down the password on the sticky note. So, without forward secrecy the attacker now has all the traffic said PGP user wrote in the life time of his encryption key. What's that 1 years traffic? (He'll have collected the ciphertext by eavesdropping on SMTP traffic travelling over the internet). With say once-a-day forward secrecy, the attacker gets nothing, no previous communications, and no future communications. Granted the attacker can install a replacement version of PGP to try to get future traffic, but the company can run automated audit checks of varying sophistications each morning to check if machines have been switched on, and if files have been altered. If tampering is detected, or perhaps every morning you re-install the machine from scratch remotely, as the MIT project did. (Reckoned to be a human resource efficient method of running networks -- got a problem with your machine -- reload it, the lot no arguments).

While Forward security via DH "may" be more secure is the added expense of implementing such a system justified??

Forward secrecy in a way is not something you need to argue about adding or not as such, because in a sense you've already got it, built in to pgp5.0. To see what I mean you'd need to read Hal Finney's recent post on the OpenPGP list, where he described how you could already achieve forward secrecy using the fact that you've got a separate encryption key and signature key. You just set the encryption key to have a short expiry, and generate a new one when it does expire. You sign the encryption keys with your signature key to transfer the WoT based trust to them. The only extra functionality I am arguing for over what PGP5.0 already has is some built in support for this type of usage, so that pgp will manage the generation of new keys at the key expiry point transparently. That much as such doesn't need any modifications to the current PGP standard. It's an implementation issue. Another vendor could easily already implement this type of functionality. Also I'm arguing for separate communications and storage keys, I think this is almost essential once PGP starts to work with escrow schemes, because there are similar arguments for separating storage and communications keys as there were for creating separate signature and encryption keys from the original single key.

We all could switch to using OTP's for maximum security but I doubt that few if any would justify the cost of such a system.

Actually I hear Fred Piper was semi-seriously arguing for this ... his argument went like this: mass storage is cheap and getting cheaper fast; often the communications needed could be covered for years worth of comms between to organisations by exchanged of a small read only storage device. Simple, and fool proof, etc. But I digress.

PS: current PGP key format does have a field for key expiration. Until 5.0 it was only used in the Viacrypt version.

I know, convenient for implementing this type of feature. I was also arguing for support for once per message forward secrecy. You should like that one because I was arguing that this should be done with out keyservers. Just send the key to the person your communicating in the email you would like a forward secret reply to. I also personally prefer people to send me keys in email, because the pay per second phone lines here at home mean that I tend want to avoid doing too many online key lookups, so I think this would be an individually useful feature. 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`

William Geiger <whgiii@invweb.net> writes:

...

I think this is taking it too far. Have you considered how much traffic DNS handles right now? I would have thought it would be many orders of magnitude more than forward secret email is going to cause. Web traffic is the bulk of network communications, just imagine the DNS lookups caused by 50 million netters clicking away.

Yes but everyone's Ip's aren't changing every week. It's not just a matter of the multitude of requests that would be required in this systems as everyone will need to update all their keys on a weekly basis but also the DNS records will be having this turnover. the DNS system has enough problems as it is let alone what would happen with the implementation of forward secrecy would cause (my best guess that within a week or two the whole thing would crash and burn).

Your argument neglects that it was you who was arguing for DNS distribution of keys. I was never too keen on this idea. Your descriptions of the near breaking point reaffirms my dislike, though I'm not sure I agree with your crash and burn predictions. Mind, DNS maintenance is not something I have a great deal of familiarity with. My comparison was intended to be "implementing forward secrecy by storing comms keys on keysevers using ad-hoc distribution of distributed keyservers would cause orders of magnitude less traffic in total than current DNS requests". I think that sounds entirely reasonable. By ad-hoc distribution of key-servers I mean key servers which don't have replication but rather store keys for some designated set of users within a set of domains. The DNS would be a good place to store the resolving mechanism for deciding where the keyservers live. Similar perhaps to the way you use a DNS MX record to find a mail exchanger for the domain name you're trying to send to. Use DNS keyserver extension record to find keyserver IP address. With that architecture, the whole thing sounds pretty scalable, and adds negligble extra overhead to the DNS system. Storing the keys themselves directly into DNS is something people get interested in for IPSEC, and for that application it seems more reasonable.

...

Bear in mind also that once the new key has been issued, you could also release a deletion request for the previous one on the keyserver in the form of a revocation certificate.

You would have to otherwise you would run out of storage very quickly.

Indeed!

The best I can think of handleing the key distribution problem is to attach a copy of your key to every correspondence and then have the client automatically check and see if it has changed and update the keyring as needed.

My thoughts also. In fact for particularly short lived keys I have a scheme worked out where key servers are not used at all. I haven't really described this scheme yet, as people seem to be raising enough objections over the logical uses of current PGP functionality.

If find both the automatic processing & sending the key with every messages quite bothersome (these are PKS implementation issues that should be covered in a different thread).

Well I thought it was a neat idea. Perhaps that is because you have the world view that every email recipient has a direct IP or at least a dialup with flat rate connection charge, and also another reason I thought it was neat was because I was considering it as a mechanism to enable per message forward secrecy in a manner which I still haven't explained in any detail.

[protecting against users who store keys on sticky notes]

Well IMHO this scenario does not forward your cause much. If the physical security is that bad (unrestricted access to equipment, weak passphrases, Post-it-Notes, ...ect) then the information an attacker is looking for is more than likely going to be available to him without messing with the PGP keys.

Yeah, well perhaps it wasn't that great an example. However you can see that extra security is being imparted even into this less than ideal scenario. These security problems are representative of the problems some real life businesses face. Most company employees do not extract as much fun from the arcane fine points of best security practice as we do. They probably view security as an inconvenient imposition, forcing them to learn things they don't want to know about.

If the reverse is true and the physical security is strong the the case for short-term separate keys is gone as the risk of exposure to a long term key is greatly reduced.

Ooh no. It's not gone at all. I think you are being a tad closed- minded here. If you have excellent security practice, you are still vulnerable to a number of attacks which my proposal gives extra protection from: 1. being blackmailed, or having the password for your encryption key with 1 year expiry period rubber-hosed from you 2. having a keyboard sniffer installed by the Feds burgling your house whilst you are out. 3. having a virus installed by an attacker remotely or directly infecting your machine With all 3 of these cases your security is blown wide open, despite your 100 bit entropy pass-phrase and crypto-anarchist 'tude: "you'll get my key when you pry it my cold dead fingers", and apparent reasonable security precautions you will have blown your security. If your key had a 1 year expiry that might mean the Feds get up to 1 year's worth of the plaintext from the encrypted traffic they had been meticulously collecting from their collaboration with invweb.net. Now consider what happens to the above attacks when you have forward secrecy: 1. blackmail/rubberhose .. it's kind of hard to not notice black mail or having passwords rubber hosed from you. So as you have used my recommendations of the most paranoid forward secrecy setting (1 new key per message, sent in message) the attacker gets zip. He gets nothing. With a key update time of 1 day, your attacker gets up to one days plaintext, or with 1 week update up to 1 weeks comms. 2. keyboard sniffer .. presuming that you don't notice it, the attacker gets traffic going forward in time, but doesn't get old traffic 3. virus .. presuming that you don't notice it, the attacker gets traffic going forward in time, but doesn't get old traffic I think that is a security advantage, wouldn't you agree? There are quite a lot of precedents for using forward secrecy... for example SSH, SSL, and some of the IPSEC protocols. They aren't using forward secrecy for phun, they're using it to increase security also. Granted it's easier to do interactive forward secrecy with IP connections than email, but forward secrecy is just another term which describes something we are all already very familiar with: key expiry. Consider why does PGP provide you with a mechanism to expire keys. The reason is because it's acknowledged that it's a good idea to change the keys now and then -- because this provides you with forward secrecy -- the longer you use the same key the more the risk that it is compromised accumulates, and the more value it will have to the attacker because of the larger number of messages it is protecting. So all I am really saying is that shorter key expiry times give you more security... not that radical a statement I don't think.

...

That much as such doesn't need any modifications to the current PGP standard. It's an implementation issue. Another vendor could easily already implement this type of functionality.

I have some serious reservations of the security implications of frequent changes to the keys. It has the potential for the user to disregard all changes to the keys (think how quick the warning pop-ups in Netsacpe get ignored and/or disabled by the user). The other possibility it to make the key changes transparent to the user which I do not like at all for obvious reasons (I do not see complete isolation of the user from the cryptosystem as a Goodthing(TM) ).

Heh. Well there is where we part company then, because I do think hiding some parts of the crypto innards where this is appropriate is a good thing. I think the generation of new transient keys is one such case. You are already using this mechanism every day anyway: your SSL enabled web browser will be setting up key exchanges using short lived communications keys with secure web servers. You do see notices when you haven't agreed to trust this organisation before, but you will observer that netscape asks you if you would like to trust this organisation this session only, or for all further sessions. What I am proposing is the same "for all further sessions", applied to PGP. I reckon it is more secure because you have the PGP WoT to help guide you in your decisions, where as I currently find a lot of web sites using uncertified server keys, and I'm not sure how much security the very limited numbers of hierarchical server certifcate issuers provide in practice. I prefer the PGP WoT where I can get face to face transfer of keys with people. The trust is much more immediate.

...

Also I'm arguing for separate communications and storage keys, I think this is almost essential once PGP starts to work with escrow schemes, because there are similar arguments for separating storage and communications keys as there were for creating separate signature and encryption keys from the original single key.

Well I have been thinking more on this. I still am not sold that separate keys are needed but even if they are I am inclined to believe that PGP is not the place for them. I am leaning towards the opinion that file encryption should be handled by the files system along with other disk security features. This seems more appropriate than having your e-mail client doing individual file encryption.

I agree with you there. That is way the most appropriate place to put storage encryption. However (and this is my point also in another form), if you were to do this, you would want to use a different key than the one you use for protecting communications keys, because the storage key may have different expiry requirements, and different escrow requirements. But... we have a circular dependency in our argument here, because when I was arguing that you didn't need to encrypt the contents of your mail folders 10 messages back or so, you jumped in and said that you kept email communications encrypted in your mail folder. I accepted your point, and countered that if you wanted to encrypt messages in your mail folder, that you should use a storage key to do so. (Otherwise you couldn't sensibly make use of the expiry feature on your communications key, as when your comms key expired, so would your access to your mailbox!) I agree with your above suggestion that it is actually easier, safer etc, to use disk level encryption systems. However I do think we have to face that these are not that widely deployed yet, and that people like yourself a few days back are correct in arguing that there may be a case for building the functionality of encryption of stored traffic in folders. As PGP Inc is fielding integrated Mail clients which have mail folders managed by the mail client, this gives us the case for separate storage and communications keys. This also gives a convenient place to put escrow -- you escrow the storage key. This implementation would completely avoid all arguments about PGP 5.5 being GAKware.

...

I also personally prefer people to send me keys in email, because the pay per second phone lines here at home mean that I tend want to avoid doing too many online key lookups, so I think this would be an individually useful feature.

I do my keylookups automatically durning the msg filtering process which is done in parallel to the message Dl's.

A clever optimisation to be sure.

The outbound message lookups are a little more time consuming but is compensated by fewer keys to look for both because fewer messages on the outbound side and the use of key caches on the client machine for the most used keys for sig verification and encryption.

I don't have a key cache, and my keyring is only 216k. But I'm curious about your automated process .. are you also checking all signatures that you can by downloading the keys and checking out the WoT for all received mailing list traffic etc? This would cleary result in a much bigger key ring.

Also logging of e-mail addresses that do not use PGP cuts down on the number of lookups needed

Good optimisation. It sounds really as if your OS/2 setup is more advanced than a lot of other stuff around. My setup is GNU emacs with Pat LoPresti's mailcrypt.el PGP and remailer support lisp extension for emacs RMAIL and emacs GNUS (newsreader). I love it to bits. It is totally excellent. It doesn't have a couple of your optimisations, but other than that it's pretty good. When you send messages, if you don't have the key it will fetch it for you by trying keyservers, then finger user@domain. It can snarf keys out of mail messages, paste keys into them, sign, encrypt, check signatures, use remailers (type I and mixmaster). 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`