One way to handle the problem mentioned below is this: Using your GAK-approved encryption, send a note that contains a PGP encrypted body (or insert your crypto of choice here.) What this does is makes it look like you're sending a proper GAK only note to folks who are checking headers and such. If they actually decrypt it (with the proper court order), they will see that you've got more encryption inside, and drag your butt off to court and try to make you give up your key etc... If they decrypt it (and they have no proper court order) they either go away because they can't call you on it, or they throw you on the bad-guy list, or drag you off to area 51 and beat you with rubber hoses and some such. Point being, You wouldn't look like you were doing anything wrong unless they got as far as decrypting your messages. If you're legally busted, your messages are secure. If they illegally decrypt your messages, your messages are secure, and you may have some recourse for suing the feds. Ryan ---------- Previous Message ---------- To: tcmay cc: smith, cypherpunks From: smith @ SCTC.COM (Rick Smith) @ smtp Date: 10/01/96 04:03:10 PM Subject: Re: How might new GAK be enforced? Tim May asks: : Any other ideas on how the government plans to enforce GAK, to make GAK the : overwhelmingly-preferred solution? The problem seems somewhat analogous to the software copy protection problem and maybe the enfocement will be similar: make "examples" of a few high profile offenders who are exchanging blatantly un-GAKed traffic with foreigners. This assumes they fine tune the law to make such behavior illegal without having to prove you yourself exported the stuff to them. Wonder what the Supremes will say to that. But that's not the end of the story. If there is lots of GAK encrypted traffic flowing about, then encrypted traffic in general is no longer noteworthy. So as long as your traffic looks like GAK, you won't be hassled until they try to read your traffic. So it's possible that products will appear that use pseudo-GAK protocols -- they look just like their GAKed cousins but the GAK fields contain plausiable garbage instead of keys. It could even turn out to be a vendor "quality control" thing -- oops, the GAK was supposed to work but... You couldn't do that with Clipper (except via Matt Blaze's brute forcing of the LEAF checksum) because the crypto wouldn't decrypt a packet with an invalid LEAF checksum. Since it was a sealed hardware module, implementers had no choice but to play by those rules. There's no such enforcable limitation on commercial software implementations. Rick.