I didn't want to mix my comments with the recent discussion paper I sent along, so here they are separately. Please refer back to my last msg to see the points I'm bitching about. It's a depressingly restrictive list of things to require for software escrow encryption. I can only conclude that they're not serious. Clipper itself fails to meet many of them, including (I think) #1, #2, #5, and #6. Rumor has it that Clipper does not meet #9 either -- at Crypto '95 somebody in the Key Escrow session said many government Clipper keys are not escrowed, and somebody in the back spoke up and said he owned such a chip. By the way, Moti Yung (noted crypto guy at IBM Yorktown Heights) presented more breaks in Clipper's protocols like those Matt Blaze found, and pointed out some aspects of Matt's break that he thinks make it more important than previously thought. Other things that bother me about the list: #1: If it's escrowed, there should be no need to limit the key length unless somebody's planning to cheat. #3: This rules out the possibility of escrowing individual session keys to limit the access of LE to sessions they are entitled by law to intercept. #5: Care to tell us how to create software that can't be patched? This is one that's been played in the marketplace and has lost. The battle between copy protectors and crackers has been decided in favor of the crackers: legitimate users largely refuse to buy packages that are too messy to deal with (e.g. they leave hidden files all over the disk, which may interfere with backups or other programs) or that use special purpose hardware (e.g. dongles that eat up a printer port). This one's a loser, I think. #6: This is clearly a research issue. Several speakers (even pro-GAK) at Crypto '95 said the policy decisions are being made before the research has been done. The protocols and system specifications are key here, and it's not obvious how this criterion can be met. It's not obviously impossible, but it certainly hasn't been solved in Clipper. #7: One of the Crypto '95 attacks on the Clipper protocol makes use of this misfeature of Clipper. It allows a broadening of the net of captured keys so that many more unauthorized messages may be read. #8: See #3 above -- let's wait on the policy decision until we have a policy debate. A mandated compromise is an oxymoron. I (for one) would prefer to see much more limited keys (like session keys) if Congress decides that the right to privacy is not infringed by these technologies. There's nothing in here that specifically excludes dividing your keys among multiple escrow agents; I assume this is still an open issue still, or that it goes without saying (one way or the other). #3 and #6 make it impossible to prevent LE from reading messages from before or after their legally authorized window. This is clearly broken. Again, this appears to be trying to put all the power in the hands of LE to the detriment of the people. It's advertized as a compromise, but I see nothing gained over Clipper I. The only differences appear to be that the escrow agent(s) may be private instead of government, and the algorithms may be something other than SKIPJACK as long as they are at least 16 bits weaker as well as being known algorithms. It also doesn't address the main problem with Clipper I: that it wouldn't work, since (like Clipper I) it will catch only crooks who are smart enough to encrypt but stupid enough to encrypt with a system they (should) know LE can read -- probably a null set. If, on the other hand, this is made mandatory for encrypted transmissions, it will create a new and unnecessary class of criminals, probably including myself (though I won't promise to break any laws at this point). This really burns me up. What do they think they're doing here? Am I missing a big piece of it? Jim Gillogly Hevensday, 14 Halimath S.R. 1995, 22:02