H/W v S/W encryption Constitutional challenge --The Next Generation

[Attila T. Hun]

on or about 970828:2005 
    Bill Stewart <stewarts at ix.netcom.com> 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 stewarts at ix.netcom.com
+# 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.)