1996-12-04 - Suggestion for “the serious encryption customers” to end ITAR battle

Header Data

From: Ernest Hua <hua@chromatic.com>
To: louis.freeh@fbi.gov
Message Hash: c65ace679121a6185bdd7559c3357053354b3d8754f43c5b3d6c2e2517172dfc
Message ID: <199612042337.PAA11363@ohio.chromatic.com>
Reply To: N/A
UTC Datetime: 1996-12-04 23:38:10 UTC
Raw Date: Wed, 4 Dec 1996 15:38:10 -0800 (PST)

Raw message

From: Ernest Hua <hua@chromatic.com>
Date: Wed, 4 Dec 1996 15:38:10 -0800 (PST)
To: louis.freeh@fbi.gov
Subject: Suggestion for "the serious encryption customers" to end ITAR battle
Message-ID: <199612042337.PAA11363@ohio.chromatic.com>
MIME-Version: 1.0
Content-Type: text/plain


I think we can all agree that the level of confidence in software-only
approaches to security is clearly lower than combination software plus
hardware approaches.

It is clear that what is available over the Internet is software.  (It
is much harder to distribute "hardware" as you can only really
distribute design information.  The closest analogy could be a FPGA
program, a Verilog description or some other ASIC net list.)

How about the following as an approach to resolving the dispute over
encryption exports:

1.  Allow arbitrary exports of software-only encryption.

    This means that PGP is exportable as is DES crypt libraries.

2.  Restrict exports of hardware-only or hardware/software encryption.

    This means that smart cards, HP's crypto policy cards, crypto
    processors with tamper-resistant casing, etc ... are restricted.

Why does this make sense?

1.  Reality check on export control of software:

    Software is just too transportable to be restricted, no matter
    WHAT the software does.  Any restriction on WHERE software may be
    or may go is just not feasible, and it's not going to get any
    easier in the foreseeable future.

2.  Take John Deutch at his word:

    Deutch has claimed that "serious users of cryptography" would not
    trust software downloaded over the Internet.  We clearly do not
    agree with him on this aspect, but if he truly believes it (and is
    not just making PR spin statements for the NSA), then he must
    believe that allowing software exports will not significantly
    increase the user base (and therefore, harm CIA's or NSA's
    intelligence capabilities), but it will shut up the software
    companies' complaints.

3.  Give the NSA what it wants:

    Software tends to standardize.  Encryption is only a small part of
    the chain of security measures.  Other weaknesses are surely part
    of the NSA's target for intercepts (no self-respecting
    codebreaking agency should stick to exploiting only one class of
    failures; if it is, we should question the value we are getting
    out of the billions of dollars we blindly give to the NSA).  If
    the NSA stops whining about what is too hard to break, then
    protocol weakness and other non-encryption problems could easily
    creep into standards, and the NSA would surely have an analytical
    advantage over anyone else.

    Since the NSA is happily bragging that it does not even need to
    crack the code to break in, it should be able to live with
    hardware-only export restriction.  The fact that the NSA is no
    longer drawing any lines anywhere for software will leave the bad
    guys guessing as to what it can really decode.

    In addition, hardware manufacturers will probably have a tougher
    overturning export restrictions on hardware-enhanced solutions
    after that because software companies will probably not care.  It
    is clear that the NSA only trusts hardware implementations, as it
    required Clipper to be manufactured in tamper-resistant cases.

All constructive replies welcome.

Ern





Thread