How might new GAK be enforced?
Now that the shoe is dropping on "Clipper III" (or "Clipper IV"), the "voluntary, for export, key escrow system," how might it be enforced? Some possibilities: 1. Make GAK the "easiest and safest" use even within the United States. Do this by aggressively pursuing, harassing, and prosecuting anyone who lets non-U.S. persons, even within the United States, have access to export-controlled software. (I had not fully appreciated the ramifications of the ITARs for software distributed _within_ the U.S. until the Bernstein matter unfolded. Export-controlled software is not supposed to be sold to various classes of foreign persons, including visitors, students on certain types of visas, and others. Mostly such rules have been ignored, with large software stores like CompUSA, Fry's, Egghead, etc., simply selling export-controlled software to anyone with the money. Their are _stickers_ on some software items warning against export, but these are ignored in sales. A few high-profile prosecutions of large resellers could spread FUD wide and far, triggering a "GAK-only" policy on sales of crypto products. The outcome of the Bernstein hearing could thus be critical.) 2. Attempt to make illegal the _interoperability_ with non-GAK software. Or, attempt to make illegal interoperability with a product which would have been illegal to export. Thus, if Alice, in the U.S., uses a crypto product to communicate with Bob, in a foreign country, and it "would have been illegal" for Bob to legally receive the product, then Alice is presumed to be breaking some law (maybe "conspircacy"...I'm not a lawyer) by sending messages Bob can read. This is just vague speculation. But I think the government must be thinking how they can finesse this point, how they can stop the current "crypto anarchy" (in a different sense than I use it), where "rogue users" in foreign countries are unreachable by U.S. law. The easiest way, of course, is to go after U.S. persons or companies who intercommunicate with these rogue users. (Else what's to stop Giant Corporation from using Non-GAKked software within the U.S., which is perfectly legal (under the "voluntary" system), but then "happening" to have their foreign branches and customers obtain "bootleg" versions at their end? All it takes is a single copy to get out, and be duplicated a zillion times. Voila, interoperability, with the only "crime" being the first export...which is essentially impossible to stop, for so many reasons we mention so often. Conclusion: Government must make this very mode illegal, perhaps by making it a conspiracy to thwart the export laws....) Any other ideas on how the government plans to enforce GAK, to make GAK the overwhelmingly-preferred solution? --Tim May We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1,257,787-1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
On Tue, 1 Oct 1996, Timothy C. May wrote:
Any other ideas on how the government plans to enforce GAK, to make GAK the overwhelmingly-preferred solution?
I am not certain that the USG has to make interoperable software illegal. It simply can withhold export licenses for products that allow such interoperability. That might go a long way to incentivizing industry to cooperate. But I would not at all be surprised if they took stronger measures. --Lucky
On Tue, 1 Oct 1996, Timothy C. May wrote:
Any other ideas on how the government plans to enforce GAK, to make GAK the overwhelmingly-preferred solution?
I am not certain that the USG has to make interoperable software illegal. It simply can withhold export licenses for products that allow such interoperability. That might go a long way to incentivizing industry to cooperate. But I would not at all be surprised if they took stronger measures.
If the evil Clinton administration has not made GAK illegal, it is simply because it does not think it has the votes in congress right now to get such legislation passed. It is probably hoping that some outrage ( perhaps engineered ) will change this. Thus, we have a race between those who want to get strong unescrowed crypto so entrenched that it can not be changed and the Clinton administration which is waiting for a change in legislative climate. The Clinton administration hopes to use ITAR's market pressure to slow things down long enough for victory. But how is ITAR to be enforced, in the absence of a new law? As has been pointed out on this list, the inevitability of software privacy and sub-licensing provides a loophole that would allow US companies to evade the ITAR as a _LEGAL_ inhibition. The big companies have smart lawyers, so why is not this loophole being used to evade the ITAR? The obvious answer is that extra-legal pressure can be brought to bear on a big company. Things like threats of IRS audits and other harassment, probably act as the big breaks. Probably such pressure in combination with foreign governments has prevented big foreign companies to withhold strong crypo as well. So, if big companies are subject to governmental pressure, why would we want their crypto? Most big companies do not release their source-code with their crypto products. The big companies could have been presured, ITAR or no, to put crypto holes in their products. Big companies simply are not trustable for purposes of crypto. Bear in mind that a sabotaged crypto product can be made to inter-operate with a strong crypto product, by simply having the sabotaged crypto product always choose its keys from a covertly restricted keyspace! Thus an product made to a open strong-crypto standard does not address the trust problem. Cypherpunks should not be asking big companies to write crypto products, but rather should be asking for crypto-with-a-hole. This would allow us to check the software for cracks and PGP or something like it could become the world crypto standard. Perhaps if the hole were made general enough, it could also be used to evade the ITAR. A software product could support generalized filtering with other uses besides crypto. After all, they have not embargoed C compilers and compilers can be used to implement crypto. (I do not know, I am not a lawyer.) Any how, conclusion is that cypherpunks should not be asking big companies to implement crypto, but rather look for easy ways users can implement crypto "on top of" commercial software products. Therefore we should boycott and disparage any commercial products that voluntarily implement GAK. -- Paul Elliott Telephone: 1-713-781-4543 Paul.Elliott@hrnowl.lonestar.org Address: 3987 South Gessner #224 Houston Texas 77063
On Tue, 1 Oct 1996, Timothy C. May wrote:
(Else what's to stop Giant Corporation from using Non-GAKked software within the U.S., which is perfectly legal (under the "voluntary" system), but then "happening" to have their foreign branches and customers obtain "bootleg" versions at their end? All it takes is a single copy to get out, and be duplicated a zillion times. Voila, interoperability, with the only "crime" being the first export...which is essentially impossible to stop, for so many reasons we mention so often. Conclusion: Government must make this very mode illegal, perhaps by making it a conspiracy to thwart the export laws....)
This is surely one of the next steps
Any other ideas on how the government plans to enforce GAK, to make GAK the overwhelmingly-preferred solution?
Well, clearly the goal is to "de-legitimize" non-GAK crypto for business use. In the Nytimes article (--sorry about the lack of URL) an official mentions that banks and other large institutions will use "legitimate" types of crypto while students and clever terrorists will continue to use other types of crypto. Notice that the issue of digital signatures and authentication has never been adressed by government crypto policy. A next step for the government's cause is to begin recognizing digital signatures with the force of law provided the signatures are made with "legitimate" (GAKked) crypto. Signatures created with non-GAKked crypto will not be recognized by the law. Contracts and agreements signed with non-GAKked crypto will not be enforceable by the courts. That is one sure way to "de-legitimize" "rogue" cryptography. And undoubtedly IBM and other corporations who participate in the "key-recovery" program will spend tons of money promoting there scheme. And I suspect our tax dollars will also suppport the publicity campaign as well as the creation of this system. me _______________________________________________________________ Omegaman <mailto:omega@bigeasy.com> PGP Key fingerprint = 6D 31 C3 00 77 8C D1 C2 59 0A 01 E3 AF 81 94 63 Send e-mail with "get key" in the "Subject:" field to get a copy of my public key _______________________________________________________________
(Else what's to stop Giant Corporation from using Non-GAKked software within the U.S., which is perfectly legal (under the "voluntary" system), but then "happening" to have their foreign branches and customers obtain "bootleg" versions at their end? All it takes is a single copy to get out, and be duplicated a zillion times. Voila, interoperability, with the only "crime" being the first export...which is essentially impossible to stop, for so many reasons we mention so often. Conclusion: Government must make this very mode illegal, perhaps by making it a conspiracy to thwart the export laws....)
I've always wondered why large companies just don't write some type of standards document for crypto to interoperate, and then have each foreign branch write (or contract out) their own version. I don't see how this violates export laws in any way. Surely this has to be easier than some of the contortions large companies are going through now to safeguard communications between branchs in different countries. Richard Coleman coleman@math.gatech.edu
Richard Coleman writes: : I've always wondered why large companies just don't write some type of : standards document for crypto to interoperate, and then have each : foreign branch write (or contract out) their own version. I don't see how : this violates export laws in any way. The definition of ``software'' in the ITAR includes ``algortihms'' and ``logic flow'', so I suspect that the ODTC wouuld claim that the standards are software that cannot be ``exported'' without a licnese. -- Peter D. Junger--Case Western Reserve University Law School--Cleveland, OH Internet: junger@pdj2-ra.f-remote.cwru.edu junger@samsara.law.cwru.edu URL: http://samsara.law.cwru.edu
Peter D. Junger writes:
Richard Coleman writes:
: I've always wondered why large companies just don't write some type of : standards document for crypto to interoperate, and then have each : foreign branch write (or contract out) their own version. I don't see how : this violates export laws in any way.
The definition of ``software'' in the ITAR includes ``algortihms'' and ``logic flow'', so I suspect that the ODTC wouuld claim that the standards are software that cannot be ``exported'' without a licnese.
I suspect that if US company A sent its Swiss subsidiary B a sent of standards and said "write this", your interpretation would be correct. It's how I read ITAR also. However, company A can publish standards. Published standards aren't covered under ITAR. Non-US company C can read standards and implement code to those standards. I was going to back this up by citing the appropriate part of the regs, but they're so vague as to be almost useless. However in real life this seems to pass- i.e. Netscape's publishing of the SSL spec and Eric Young's use of that spec to make an independent interoperable implementation. -- Eric Murray ericm@lne.com ericm@motorcycle.com http://www.lne.com/ericm PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03 92 E8 AC E6 7E 27 29 AF
participants (7)
-
Eric Murray -
Lucky Green -
Omegaman -
Paul Elliott -
Peter D. Junger -
Richard Coleman -
Timothy C. May