From: tcmay@got.net (Timothy C. May)
Date: Tue, 4 Jun 1996 08:52:13 +0800
To: cypherpunks@toad.com
Subject: Crypto APIs Considered Harmful
Message-ID: <add86d220702100431c8@[205.199.118.202]>
MIME-Version: 1.0
Content-Type: text/plain



There are obviously lots of snags and restrictions being imposed on crypto
APIs. "Hooks for crypto" lead to trouble of various sorts.

Well, we've talked about this before, but I'll say it again:

* For now and for the foreseeable future, maybe the focus should be on
better and more efficiently integrating crypto (e.g., straight PGP) with
the _contents_ of programs (e.g, the innermost pure text blocks, such as
what you are now reading). The integration can be done separately and
orthogonally from the basic crypto package, just as PGP did.

* This is largely, in my opinion, what made PGP so popular. Whether one had
a PC. a Mac, an Amiga, various flavors of Unix, etc., one could send and
receive messages with PGP to other users, regardless of their platforms or
their choice of mailers, editors, word processors, newsreaders, or
browsers. This was because PGP was a "payload-centric" (to coin a phrase)
program.

* PGP did not need to know any details of the message headers, MIME sorts
of stuff (though a MIME field for PGP exists, as I understand it). Thus,
there were no "hooks" in PGP for specific mailers, editors, etc., except
things people added later.

* Better integration is needed between crypto and mailers, editors, Web
browsers, but then this runs smack into the "crypto API" issue. (It also
narrows the richness of applications, in the sense that if a lot of work
goes into "Netscape 4.x with S/MIME," as a likely example, then there are
fewer combinations of crypto + tools.)

Thus, it seems to me that we gain more overall leverage, and more
flexibility, and less hassle from the ITAR folks, if more of the focus is
kept on the "crypto API" it is essentially impossible to control: the
message payload.

So long as ASCII (or Unicode, increasingly) message blocks can be handled
by a variety of editors, mailers, news programs, browsers, etc., it will be
impossible to stop users from using crypto on these blocks.

But if crypto is tied to specific browsers, mailers, etc., this gives the
NSA and ITAR office a way to impose limits.

I think there are a _lot_ of advantages to maintaining orthogonality, to
_not_ more tightly integrating crypto with mailers and browsers.

Sure, it would be very nice if hooks existed. But the fact is that this
gives the NSA an avenue for restricting export of programs (e.g.,
Netscape), and such restrictions may cause companies like Netscape to
compromise by giving _everyone_ a "weaker-but-more-tightly-integrated"
crypto package.

I would rather have a "strong-as-I-wish-but-loosely-integrated" package!

(Greater convenience can be handled on a platform-by-platform basis,
possibly easier than trying to get industry-wide compliance with a crypto
API spec. Thus, on the Mac it is possible to have macros or scripts which
take a received message (from whatever source and with whichever mailer,
browser, etc.), process the message block, and return the result to another
window or as a file. MacPGP mostly works this way, and other enhancements
exist as well. At no point was the basic spec for PGP affected, and no
"crypto API" was needed....since the fact that we can _see_ and _read_
messages is in fact the crypto API!)

* Disadvantages of Not Having Crypto APIs in Popular Packages

1. Many users, especially those just getting on the Net, want "all-in-one"
turnkey programs. Not having crypto APIs built into Netscape Navigator, for
example, will reduce the number of users of crypto. (On the other hand, if
most new users are using Navigator 4.x "now with extra strong 47-bit
crypto," they at least get into the habit of using crypto and can
"graduate" up to crypto packages external to Navigator, so maybe it won't
be a disaster for Netscape to offer NSA-approved crypto APIs, so long of
course as external packages can access the message blocks freely.)

2. Not having APIs may affect digital commerce, as robust systems involving
many transfer points should have robust links to message internals, and not
rely on something so potentially prone to error and glitches as a bunch of
macros and scripts. (Can be done, but having a bunch of Macs and PCs
communicating with a bunch of clipboard macros...ugh!)

* Advantages of Not Having Crypto APIs in Popular Packages

1. Separates the development of strong crypto from the development of
browsers, mailers, etc. (I'm not saying Netscape, for example, is
developing the algorithms, but by including integrated crypto they are
automatically in the loop on developments...and maybe it would be better if
they weren't.)

2. Eliminates a reason for controlling the distribution and export of
browsers, mailers, newsreaders, etc. Imagine the glum reaction of the NSA
when they realize that they can't control these programs, because the
"crypto hooks" are only the hooks to basic message payloads...and they
control these.

3. Orthogonality and independent development means the _best_ crypto (PGP,
S/MIME, whatever...) can be combined with whichever mailers and browsers
people want to use. Netscape users will not be limited to S/MIME, for
example, with its strange notions of where the signatures belongs, or its
default key size.

4. In some sense, the "basic data structure" of nearly all personal
communications _is_ the basic ASCII (or Unicode, rich MIME, etc.) message.
At least for the things most _personal_ users are now sending. (I
acknowledge that business users have needs for richer data structures. As
noted in Disadvantage #2, running a commerce system (think of SWIFT) with
macros and scripts reaching into message blocks...shudder! But business
users can work out separate plans.)

5. Finally, placing more of a focus on the messages and not on crypto APIs
for currently popular programs like Microsoft Explorer and Netscape
Navigator makes better use of scarce programming resources. And it is, in
my opinion, a more "grassroots" and "cypherpunkish" thing to do than to try
to work with large corporations to integrate tools into their programs.

(The NSA would clearly rather have crypto tools tightly integrated into
popular programs, despite what some have said. It gives them control and
it's easier for them to jawbone Netscape and Microsoft than a million
users.)

Obvious points. But in light of all the recent moves to limit deployment of
crypto by limiting the "crypto API" approaches, it's useful to remember
that for most applications, the message payload is perfectly suited for
carrying digital signatures, encrypted blocks, etc.

They can't stop the messages, can they?

--Tim May

Boycott "Big Brother Inside" software!
We got computers, we're tapping phone lines, we know that that ain't allowed.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Licensed Ontologist         | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."