1997-08-29 - Re: H/W v S/W encryption Constitutional challenge –The Next Generation

Header Data

From: Bill Stewart <stewarts@ix.netcom.com>
To: cypherpunks@toad.com
Message Hash: a07c8e780b2fb755a454df446907091200c34bb8c41f44778881d42ca1328384
Message ID: <3.0.2.32.19970828200538.02f513ec@popd.ix.netcom.com>
Reply To: <1.5.4.32.19970826140833.00860dd0@pop.pipeline.com>
UTC Datetime: 1997-08-29 06:51:45 UTC
Raw Date: Fri, 29 Aug 1997 14:51:45 +0800

Raw message

From: Bill Stewart <stewarts@ix.netcom.com>
Date: Fri, 29 Aug 1997 14:51:45 +0800
To: cypherpunks@toad.com
Subject: Re: H/W v S/W encryption Constitutional challenge --The Next Generation
In-Reply-To: <1.5.4.32.19970826140833.00860dd0@pop.pipeline.com>
Message-ID: <3.0.2.32.19970828200538.02f513ec@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



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 :-)
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@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.)






Thread