Re: Crypto APIs Considered Harmful

[shamrock@netcom.com (Lucky Green)]

At 11:06 6/3/96, Timothy C. May wrote:

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

I agree. But it really doesn't matter. The goal of the governments is not
to stop people that are willing to operate a crypto program on blocks of
text. That goal would be impossible to achieve. The goal of the governments
is to ensure that once Joe Sixpack clicks "Encrypt Mail" in Netscape or MS
Mail, the resulting cyphertext can still be read, though not by Joe
himself. It is *because* PGP operated on blocks of text and did not provide
a decent API that Joe (and even Tim May) are still not encrypting the bulk
of their email.

PGP isn't being used, because it lacks the API. S/MIME doesn't lack the API
and is therefore being supported by all the major players.

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

Crypto should not be tied to specific browsers and mailers. Nor should it
be tied to a specific program such as PGP. That's why hooks and APIs are
crucial to gaining market acceptance.

[...]
>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?

Of course not. Nor do they want to. A little leakage around the edges is
fine, as long as the masses don't adopt strong crypto. And that is a given,
thanks to PGP's lack of modularity.

I am not just slamming PGP. It is not the only CP "friendly" software that
was implemented in an outdated, application-centric way. This was fine some
four years ago, when people were still using DA/Font Mover to install fonts
on their Mac, but it isn't today.

Today's realities of software development and customer expectations require
that secondary functionality (in this example, sending and receiving mail
is the primary functionality) such as encryption, message encoding, etc.
are completely transparent and fully integrate in the software that
provides the primary functionality. How many of you are still using
UUencode (the stand-alone program) when emailing someone a binary file? How
many of you are using the "Attach File" button in your mailer? How many
more people are sending binary files via email now that you can click
"Attach File" than did back when you had to use UUencode? I rest my case.


Disclaimer: My opinions are my own, not those of my employer.

-- Lucky Green <mailto:shamrock@netcom.com>
   PGP encrypted mail preferred.