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."