[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: H/W v S/W encryption Constitutional challenge --The Next Generation
on or about 970828:2005
Bill Stewart <[email protected]> expostulated:
+At 03:50 PM 8/26/97 +0000, Attila T. Hun wrote:
+> IM[NSH]O, we need a test case that _differentiates_ between
+> hardware encryption engines and _software_for_encryption (not to be
+> confused with firmware). Patel rendered an important decision, but
+> she refrained from establishing national jurisdiction; our only hope
+> in this instance is further citations as to relevance.
+I disagree. We'd lose, and setting bad precedent is worse than none or
+weak precedents. The important conclusion Judge Patel drew was that
+source code is clearly speech (yay! and blatantly obvious, as well :-)
-----BEGIN PGP SIGNED MESSAGE-----
Bill:
I think you missed my point --or I failed to express it coherently.
yes, the government does have a strong case with hardware
--particulary dedicated hardware, and that was my point!
what I think is an effective stratagem is to use a test vehicle
which clearly demonstrates the difference --eg the generic
black box which can do anything else as well.
As soon as you get into focused boxes --eg the ASIC you mention,
then the government has an argument. I'm looking at a routine
"boot sector virus" (DOS) -not even the "pretty program loader"
(Windows) box. the object is to proof the absurdity of the
whole issue --the computer just reads the natural language, freedom
of speech, program.
likewise, you can not have any of the functions in firmware for the
test case, despite the fact the process would be faster --that
would be another test case to extend the principal.
I did suggest the source code must absolutely be written in
a language which is understandable --good clean ANSI C, for
instance.
your suggestion of an interpretive language is a good idea if it
creates an easily understood body of code. perl? powerful, but
even more cryptic than C --sometimes I think perl is too powerful
<g>.
I will not fault your suggestion for more code test cases --however,
the real trick is to get Bernstein moving through the ninth circuit
and onto the Supreme Court --it only takes one and if the SC
reaffirms Judge Patel's statement on source code freedom of speech
and prior restraint, we're home free on that issue.
What I am concerned will happen is that the feds may be forced to
give up prosecuting professors who teach encryption (free speech and
prior restraint), and may be unable to prevent Phil Z from
publishing the code in book form, etc. but will then try to claim
that all encryption needs to be attached to hardware --this is where
the generic argument comes in --they would in effect be required to
ban computers --all computers.
actually, with the push for universal JAVA, write the algorithm in
JAVA...
the only other alternative is massive civil disobedience, something
I suspect many of us are quite familiar with; approaching 60, I
think I'll pass on any repeats of dogs and water cannons.
attila
"Experience keeps a dear school, but fools will learn in no other."
--Benjamin Franklin
______________________________________________________________________
"attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: No safety this side of the grave. Never was; never will be
iQCVAwUBNAcUvL04kQrCC2kFAQFCnQP/Vwna9eRJjSAlBCBPlF9MUrLsFNu4owqy
ruVwPk9qLczUF/qK+KV51I3qfSkz6OyKdrHSeF14wKT/2oclEmuZX85w8IG5oxEB
9L7gTZR1396KhFe3T3xS22c7ZNrnHMNEMcMtLVnFjEu2yBJQIegaEchks6p12X3m
q9m3YcCYX6I=
=w6Js
-----END PGP SIGNATURE-----
+The next obvious directions to go, after we win the appeal, are to
+solidify the judgement with more source code
+(and deal with the fact that they'll keep changing the regulations),
+especially if we can do a source code in an interpreted language like
+perl, and then maybe go after binary code as speech.
+We'll also need to do something about the Karn case,
+since the difference between source code on paper and
+source code on a floppy is obviously not a legitimate one.
+If you do hardware, they'll say "Hardware isn't speech, it's stuff, and
+exporting stuff is commerce, and we can regulate commerce and exports",
+and they'll be right constitutionally if not morally.
+Exporting the detailed plans for encryption hardware might be fun,
+especially if the hardware is very generic (say, a speech card for a
+Nintendoid with some crypto firmware for the Nintendoid's CPU, or a
+cellphone-modem with crypto pumpware.)
+About the only Real Hardware I can see having a chance is
+some sort of ASIC-based device like a pocket organizer or cashcard that
+does encryption as an incidental part of some other function, such as
+an authentication protocol. But if it's a cash card, the rules have
+been flexible enough to handle permits for banking-only devices, and
+you don't get an interesting Constitutional case about being wrongly
+denied an export permit when they give you a permit, or at least give
+out permits for functionally similar products.
+I suppose there'd be some hack value in exporting a smart-cellphone
+with downloadable firmware/javaware (e.g. for multiple language
+support) with all the right export permits, and then releasing the
+crypto code from replay or kremvax or www.hongkong.cn , and using it
+as precedent for your application for exporting the crypto-equipped
+version.
+# Thanks; Bill
+# Bill Stewart, +1-415-442-2215 [email protected]
+# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp # (If
+this is a mailing list or news, please Cc: me on replies. Thanks.)