At 12:54 PM 9/4/95 -0400, Pat Farrell commented on the NIST's latest proposals for their September meeting on export controls and software with built-in government access to keys (GAK). I'll generally use the terms GAK or master keying rather than escrow, since escrow is a legal term that implies both the willingness of both parties to use it, and also that the escrowed material be delivered only when certain criteria are satisfied, which is out of the scope of almost any proposals I've seen labelling themselves "key escrow", particularly the Clipper system. Material with > and indentation are from the NIST paper; material with just > and 0-1 spaces is Pat's. 64 bits of keyspace is of course hopelessly inadequate for financial transactions - crackerboxes have been designed that allow very rapid breaking of single-DES or short-key RC4, and a useful platform needs to accommodate high-value transactions such as customers access to stockbrokers as well as more limited-value transactions such as credit cards where a $1000 cracking cost makes crime not pay well. The Administration argues that the limitation makes up for the possibility that users may find ways to evade GAK; but users can already do that now.
"Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm?" CME has been suggesting DES | TRAN | DES | TRAN | DES for years. Can they really _avoid_ (i.e. prevent) this? (CME is Carl Ellison at TIS; tran is a simple transposition system.)
Sure - if the software always tacks in master keys any time it does a symmetric-key encryption, and won't/can't decrypt without it, then DES+GAK | DES+GAK | DES+GAK is just as vulnerable to someone with the master key as single DES+GAK - it just takes three separate phases of key forfeiture to decode. (yes, I left out the tran phase; anybody going to that much work is using something other than the built-in encryption, at which point they might as well use non-government-approved encryption themselves.) Does it triple the key space? For people without the master key, yes, though maybe they get some known plaintext. For people with the master key, it depends on your definitions, and maybe _they_ put in some known plaintext that they don't give outsiders, but it probably doesn't lose them much.
"Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested?"
This is easy in hardware. Is it even possible in software?
Probably. Consider the sort of master-key system where part of the session key isn't transmitted - maybe you do something like hash the user portion of the session key with the hash of the program and feed it to the KeyMaster's public key to get the session key. By the time you put all of that into Pretty Good PatchAround, you might as well just use PGP.
"Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period?" At least this has a chance of being real. We need to have a suggestion for expiration times for the escrowed keys. This was a huge problem with the initial Clipper.
Information can't be destroyed, only forgotten, so time-limitation is tough. What you can do is limit the scope of messages that can be decrypted by one trip to the keymaster - the Feds are looking for some mechanism so that any limits like this won't require multiple trips for one bunch of wiretapping.
Is there a reasonable middle ground between long term keys such as PGP uses, and the ephemeral keys of a D-H exchange?
What's reasonable? Some potential models for a PGPng would be - Use separate keys for signatures/keysigning and messages, so you could change your message key frequently while leaving your signature (or at least key-signature) key stable. (This tends to need an extra layer in the web of trust, since you now have two tiers for yourself, but no biggie.) - Diffie-Hellman kind of mechanism to encrypt the keys, with published g, p, g**x mod p, x changing frequently, RSA or DSS or whatever to sign the keyparts - this works better with a more interactive key negotiation so you can use a new x every time (e.g. request directly from the user, though that's difficult for email, or a keyserver that maintains a set of keys to be doled out.)
"Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent?"
The technical and political questions are quite different. Technically, you could have the software require a hierarchical-style certificate for the key-master keys with a US Government CA wired in. It's not totally foolproof - patching the CA is easy unless you've got some sort of checksum on the software. But it's a start, and it's simple enough that either the US could authorize separate versions for France or certify the French government's key-master agency. Also, there's a need for escrow/keymaster agents to be negotiable per-message - since escrow inherently requires the trust of all parties, and probably contractual agreements as well, and government-enforced keymastering may require satisfying multiple governments, parties will persumably have different lists of acceptable keymasters.
We all know that Tim's Flakey Key Escrow Service is most likely not "an acceptable US escrow agent." But since CKE is a good thing, what are the characteristics of an acceptable service to us?
As far as the political criteria go, I believe the traditional formulation is along the lines of "I am not now, nor have I ever been, a member of...." :-) Establishing criteria is difficult, and depends on whether the whole system will be defined by laws passed by Congress or only by organizational policy; there are also issues of control between the Commerce Department, NIST, NSA, and the State Department. For Commercial Key Escrow, or commercial key-backup services, the criteria are "whoever can be trusted to provide the services the customers want". In this case, of course, the service most customers want is to be left alone, or, failing that, to have the government's Master Key system provide minimal risk to the security of the actual transactions - 64 bit keys are not enough security for any high-valued financial transactions, though they may suffice for credit cards. One required characteristic would appear to be either sufficiently deep pockets to collect judgements for violations of trust or a sufficiently high reputation that violations of trust are not expected. Most of the commercial market for key escrow or backup services fits into three categories - backups for the owner/sender of a file (which they can provide themselves, using techniques like PGP's Encrypt-to-Self option, or file backups with secret-sharing), acknowledgements of transmission (signed hashes would do), and dispute-resolution issues (verifying the contents of a message which may require information from both parties or ephermeral session key information.) Most can be provided by the kind of services currently provided by companies like bonding agencies, emergency backup and offsite storage companies, etc. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---