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

Attila T. Hun attila at hun.org
Tue Aug 26 09:06:35 PDT 1997


    "Experience keeps a dear school, but fools will learn in no other."     
        --Benjamin Franklin

    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.

    If it can be established, by extension of Patel's ruling that 
    software is _always_ protected under the First Amendment (despite 
    our government's well established track record of trying to kill 
    free speech, or at least ignore it), the mere fact that it runs on a
    hardware engine --any engine, should be irrelevant.  Carrying the
    argument to its absurd extreme, should we ban gasoline since it 
    powers automobiles?  --or even ban the publication of information on
    refueling an automobile?  when confronted by fools {Clinton, et al],
    one must emphasize the absurdity, even inanity, of their
    foolishness.  The whole argument must be expressed in terms which
    Judge Marilyn Patel found endearing.

    write the encryption software in Java which is [generally] a
    platform independent and portable human readable language. Perl, for
    instance the 3 line RSA algorithm for DC, is not exactly readable.

    Why not construct an SBC with extended memory, small hard disk, an 
    O/S which supports Java, and I/O means  --then, apply for an export
    permit for the hardware, the Java encryption/decryption software, 
    and the combined unit?

    If the burrowcrats at Commerce respond in typical fashion, file in
    SF Federal Court; if they procrastinate and obfuscate to avoid the
    inevitable, file in SF to pry it out of their grubby hands and get
    on with it.

    The criminals in Congress always pass the right way in public, then 
    hose us over with manager's marks and all that falderol in
    reconciliation, justifying their position that they have given the
    Congress a choice [between good and evil? --no, between worse and

    Therefore, let's present the Court with the two [or three] part
    challenge --and make sure the hardware, the combined hardware and 
    software, and the software alone, are distinct claims so that even 
    if the justices choose to classify the hardware/software "package"
    as a munition, the standalone software will fall under Patel's
    ruling (more like guidance).  The Feds will look pretty stupid
    ruling a general purpose Java enabled SBC black box a munition....

    let's go get the bastards using their own techniques. TAKE THE WAR 
    HOME TO THEM, on their own turf!

    until Bernstein, all of our actions have been essentially defensive
    (Junger non-withstanding).  Issues must be reduced to the lowest
    common denominator --let's teach that class of misfits, the ship of 
 "attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0 

on or about 970826:1008 
    John Young <jya at pipeline.com> expostulated:

+Declan wrote:
+>I think that's about right. One of the important questions was how broadly
+>Patel would rule, whether her ruling would apply just to Bernstein &
+>associates or whether she would enjoin the government from enforcing
+>ITAR/EAR at all.
+>Unfortunately, she chose the former. But look on the bright side: her
+>narrow decision may be less likely to be reversed, no?

+Does this not shift now to Peter Junger's suit: same issues, broader
+challenge, same opposing arguments? Did Patel rule narrowly in
+Bernstein to set the stage for the broader case in the works?

+BTW, is there a suit being readied to follow Peter's? Karn II? PRZ 6.0?

+What say, Peter, Lee, Cindy, Phil, Phil, Anthony et al?

Version: 2.6.3i
Charset: latin1
Comment: No safety this side of the grave. Never was; never will be


More information about the cypherpunks-legacy mailing list