From: Rick Smith <smith@SCTC.COM>
Date: Wed, 2 Oct 1996 10:31:21 +0800
To: tcmay@got.net (Timothy C. May)
Subject: Re: How might new GAK be enforced?
Message-ID: <199610012103.QAA26604@shade.sctc.com>
MIME-Version: 1.0
Content-Type: text/plain


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.