One of the themes of modern computing I strongly support is that of "orthogonality," or clean functionality. A browser should not also try to be a money management program. A word processor should not also try to be an accounting program. Failure to observe this rule of thumb has led to spreadsheets which can run MPEG movies in spreadsheet cells (I'm not kidding), and to Web browsers which take 20 MB of free memory to run reliably because they also contain mediocre news readers, mediocre mailers, and lots of bloatware cruft. The move toward modular decomposition is supported in functional and object-oriented languages (like Java and C++) and in modern operating systems. Much of the strenght of Unix has obviously come from the philosophy that a function or utility should do some small set of things well and cleanly, with chaining of these clean tools to accomplish more complicated tasks. A crypto program like PGP is intended to encrypt messages between a sender and a recipient, or to provide authentication through signatures, or to encrypt files on a storage medium. These are the classic, well-documented, oft-discussed functions of crypto. Look in textbooks under "crypto" and there won't be much talk of how to supply MIS with emergency backdoors, or ways to monitor employees. If properly modularized and orthogonalized (so to speak), such crypto programs can then be used as building blocks for other tasks, like remailers, data havens, and so on. But there is a growing tendency, as seen in the bloatware examples of browsers and spreadsheets mentioned above, to throw in all kinds of "wish list" and "wouldn't it be nice" stuff. PGP is headed for bloatware. ("It's not just a crypto program, it's also a tax preparation and disaster planning program!") I'm quite certain that the Security and MIS directors at various companies asked PGP, Inc. to include message recovery features. Not so much to handle the very rare (almost nonexistent) cases where a piece of mail sent at some time in the past has to be recovered because Alice was hit by a truck, or similiar unlikely events (*), but because Security and MIS folks would like the option of "monitoring" e-mail traffic. (* I have heard no plausible scenarios under which transient communications, which are presumably stored in the form composed (plaintext) on the sender's machine or in the for received and read (also in plaintext) on the receiver's machine, need to be recovered from the *transit* state. We know why the FBI wants access to communications keys--because access to the transit state is what they get when they wiretap or sniff a communications line--but there is no plausbile explanation of why a company would not simply ask Alice for the plaintext, or ask Bob if for some reason Alice is unavailable. The idea someone floated, that he needs to go in and decrypt his employee's mail in emergencies is far-fetched.) But are such bloatware crypto programs even good for disaster recovery? I say they are not. I say e-mail will be a tiny, tiny portion of the recovery strategy if Alice gets hit by a truck, for example. Far more important will be recovery of her hard disk and related files. (No, I am _not_ proposing anything be added to PGP to deal with this disaster planning. Nor am I proposing that PGP enforce plaintext storage, or anything else for that matter. These are all matters _orthogonal_ to the basic function of a crypto program, and a crypto program cannot enforce crypto hygiene any more than a spreadsheet can enforce good tax planning hygiene.) I am also not terribly interested in convoluted, byzantine schemes for building "CDR" and such into crypto programs, as some are proposing. Again, this is trying to make a crypto program into a disaster preparation product, and trying to (partly) solve backup and disaster problems best solved in other ways. Not something PGP should worry about (either the program or the company). "What if Alice forgets her key?" (Loses her private key, forgets her passphrase, whatever.) A very real concern. A concern I have myself. I won't say how I deal with it, for security reasons, but it ain't something I expect PGP, Inc. to solve _for_ me. Nor is my solution, whatever it is, a step toward GAKking of keys, or any kind of building of an infrastructure for surveillance. In fact, this was my point a while back about how a diversity of approaches to disaster planning, to key insurance measures, makes the imposition of mandatory key escrow or Government Message Recovery (GMR) very difficult. The very chaos helps. "Let a thousand flowers bloom." And it turns out that the "what if Alice forgets her key?" scenario is very poorly dealt with by PGP 5.5 (unless the corporation actually _does_ keeps a copy of the private key generated for or by Alice...something supporters of CMR says is not the case. Whether it _can_ or _will_ be the case is another issue.) So, disaster planning, for dealing with crashed disks, dead employees, malicious employees (who, for example, encrypt their disks and then leave the company), and general failures to backup work product, etc., these examples of disaster planning issues are NOT dealt with in any important way by PGP 5.5. Nor should any communications security program try to be this kind program. Keep it simple, stupid. This kind of bloatware is a fig leaf for security, and very probably introduces major new security flaws. (I've discussed at length the issues of just who will be reading the CMR messages. It's very unlikely such CMR messages will simply be archived away for that rare day when someone's old messages need to be "recovered" for the reasons usually given...in fact, as I have been arguing, I can't imagine companies even bothering to get some transient piece of e-mail sent 2 years earlier by Alice to Bob. They don't archive phone calls, and these are every bit as likely to be "critical" in some sense as old e-mail messages are.) As this relates to PGP, it just ain't their problem to try to answer the demands of control freaks in corporate MIS departments that backdoors be built into crypto products. (Call it snoopware, call it surveillance software, call it CMR. But what it really is a backdoor built into a crypto system. And one thing we know from several decades of crypto work is that backdoors are holes in security. Given that these backdoors apparently have little use in any real disaster situations, they represent a serious dilution of security for little or nothing gained.) PGP, Inc. should stick to its core business, and not try to build in snoopware backdoors for control freak MIS managers. If it is claimed that corporate America is demanding these backdoors, our industry and community then faces a major educational battle. If this battle is lost, as it may already be, then the same reasons for corporations to insist on "emergency access" (which of course won't be very "emergency" oriented, as actually used in corporations) will be seen by many to apply to government as well. "What have you got to hide?" Keep it simple, stupid. That makes for efficiency, functionality, and easier product development. And it doesn't build the case for government to later demand message recovery. --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."