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.