Crypto-Gram

June 15, 1999

by Bruce Schneier
President
Counterpane Systems

schneier@schneier.com
http://www.counterpane.com

A free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security.

Copyright (c) 1999 by Bruce Schneier

In this issue:

E-Mail Viruses, Worms, and Trojan Horses

Looking back from the future, 1999 will have been a pivotal year for malicious software: viruses, worms, and Trojan horses (collectively known as “malware”). It’s not more malware; we’ve already seen thousands. It’s not Internet malware; we’ve seen that before, too. But this is the first year we’ve seen malware that uses e-mail to propagate over the Internet and tunnel through firewalls. And it’s a really big deal.

Viruses and worms survive by reproducing on new computers. Before the Internet, computers communicated mostly through floppy disks. Hence, most viruses propagated on floppy disks, and sometimes on computer bulletin board systems (BBSs).

There are some obvious effects of floppies as a vector. First, malware propagates slowly. One computer shares a disk with another which shares a disk with five more, and over the course of weeks or months a virus turns into an epidemic. Or maybe someone puts a virus-infected program on a bulletin board, and thousands get infected in a week or two.

Second, it’s easy to block disk-borne malware. Most anti-virus programs can automatically scan all floppy disks. Malware is blocked at the gate. BBSs can still be a problem, but many computer users are trained never to download software from a BBS. Even so, anti-virus software can automatically scan new files for malware.

And third, anti-viral software can easily deal with the problem. It’s easy to write software to block malware you know about. You simply have the anti-virus scanner search for bit strings that signify the virus (called a “signature”) and then execute the automatic program to delete the virus and restore normalcy. This deletion routine is unique per virus, but it is not hard to develop. Anti-viral software has tens of thousands of signatures, each tuned to a particular virus. Companies release them within a day of learning of a new virus. And as long as viruses propagate slowly, this is good enough. My software automatically updates itself once a month. Until 1999, that was enough.

What’s new in 1999 is e-mail propagation of malware. These programs—the Melissa virus and its variants, the Worm.ExploreZip worm and its inevitable variants, etc.—arrive via e-mail and use e-mail features in modern software to replicate themselves across the network. They mail themselves to people known to the infected host, enticing the recipients to open or run them. They don’t propagate over weeks and months; they propagate in seconds. Anti-viral software cannot possibly keep up.

And e-mail is everywhere. It runs over Internet connections that block everything else. It tunnels through all firewalls. Everyone uses it.

It’s easy to point fingers at Microsoft. Melissa uses features in Microsoft Word (and variants use Excel) to automatically e-mail itself to others, and Melissa and Worm.ExploreZip make use of the automatic mail features of Microsoft Outlook. Microsoft is certainly to blame for creating the powerful macro capabilities of Word and Excel, blurring the distinction between executable files (which can be dangerous) and data files (which, before now, were safe). They will be to blame when Outlook 2000, which supports HTML, makes it possible for users to be attacked by HTML-based malware simply by opening an e-mail. Microsoft set the security state-of-the-art back 25 years with DOS, and they have continued that legacy to this day. They certainly have a lot to answer for, but the meta-problem is more subtle.

One problem is the permissive nature of the Internet and the computers attached to it. As long as a program has the ability to do anything on the computer it is running on, malware will be incredibly dangerous. Just as firewalls protect different computers on the same network, we’re going to need something similar to protect different processes running on the same computer.

This cannot be stopped at the firewall. This type of malware tunnels through a firewall using e-mail, and then pops up on the inside and does damage. So far the examples have been mild, but they represent a proof of concept. And the effectiveness of firewalls will diminish as we open up more services (e-mail, Web, etc.), as we add increasingly complex applications on the internal net, and as crackers catch on. This “tunnel-inside-and-play” technique will only get worse.

And anti-virus software can’t help much. If a virus can infect 1.2 million computers (one estimate of Melissa infections) in the hours before a fix is released, that’s a lot of damage. What if the code took pains to hide itself, so that a virus won’t be discovered for a couple of days? What if a worm just targeted an individual; it would delete itself off any computer whose userID didn’t match a certain reference? How long would it take before that one is discovered? What if it e-mailed a copy of the user’s login script (most contain passwords) to an anonymous e-mail box before self-erasing? What if it automatically encrypted outgoing copies of itself with PGP or S/MIME? Or signed itself; signing keys are often left lying around the system. Even a few minutes of thinking about this yields some pretty scary possibilities.

It’s impossible to push the problem off onto users with “do you trust this message/macro/application” messages. Sure, it’s unwise to run executables from strangers, but both Melissa and Worm.ExploreZip arrive pretending to be friends and associates of the recipient. Worm.ExploreZip even replied to real subject lines. Users can’t make good security decisions under ideal conditions; they don’t stand a chance against a virus capable of social engineering.

What we’re seeing here is the convergence of several problems: the permissiveness of networks, interconnections between applications on modern operating systems, e-mail as a vector to tunnel through network defenses and as a means to spread extremely rapidly, and the traditional naivete of users. Simple patches won’t fix this. There are some interesting technologies on the horizon that try to mimic the body’s own immune system to automatically deal with unknown malware, but I am not very optimistic about them. Sure they’ll catch some things, but it will always be possible to design malware specifically to defeat the immune systems. A large distributed system that communicates at the speed of light is going to have to accept the reality of viral infections at the speed of light. Unless security is designed into the system from the bottom up, we’re constantly going to be fighting a holding action.

Melissa:
http://www.zdnet.com/zdnn/stories/news/…
http://www.zdnet.com/zdnn/stories/news/…

Worm.ExploreZip
http://www.zdnet.com/zdnn/stories/news/…
http://www.wired.com/news/politics/0,1283,20160,00.html
http://www.symantec.com/press/1999/n990614d.html

Counterpane Systems—Featured Research

“Protecting Secret Keys with Personal Entropy”

C. Ellison, C. Hall, R. Milbert, and B. Schneier, FUTURE GENERATION COMPUTER SYSTEMS, to appear.

Conventional encryption technology often requires users to protect a secret key by selecting a password or passphrase. While a good passphrase will only be known to the user, it also has the flaw that it must be remembered exactly in order to recover the secret key. As time passes, the ability to remember the passphrase fades and the user may eventually lose access to the secret key. We propose a scheme whereby a user can protect a secret key using the “personal entropy” in his own life, by encrypting the passphrase using the answers to several personal questions. We designed the scheme so the user can forget answers to a subset of the questions and still recover the secret key, while an attacker must learn the answer to a large subset of the questions in order to recover the secret key.

http://www.schneier.com/paper-personal-entropy.html

News

Hushmail is like Hotmail, but encrypted. They implement SSL from the browser to the server, and Blowfish to encrypt messages. Free secure e-mail for the masses. Their source code is available via free download. Furthermore, they developed their product off-shore, so they don’t face any export restrictions. I haven’t seen any evaluations of the code, but it’s certainly a good idea.

News story: http://www.wired.com/news/print/0,1294,19804,00.html
Hushmail homepage: http://www.hushmail.com
Technical summary: https://www.hushmail.com/tech_description.htm
Source code: http://www.cypherpunks.ai/~hush/ [link dead; see http://www.hush.ai/

And ZipLip is a competing secure web e-mail service:
http://www.techweb.com/wire/story/TWB19990526S0002

I’ll write more about both of these products next month.

The French data agency CNIL is investigating Microsoft and Intel, to determine if their anti-privacy antics violates any European data protection laws. http://www.europa.eu.int/comm/dg15/en/media/…
http://www.europa.eu.int/comm/dg15/en/media/…

A report on how 128-bit crypto was liberated in France.
http://jya.com/jospin-coup.htm

The United States has been accused using key-escrow to steal secrets.
http://www.techweb.com/wire/story/TWB19990518S0004 http://www.nytimes.com/techweb/…

How to discuss Blowfish with your children.
http://www.hcs.harvard.edu/~demon/issues/…

There are rumors that the CIA is using computers to attack the foreign bank accounts of Yugoslav leader Milosevic.
http://www.techweb.com/wire/story/reuters/…

“We’ve lately had reason to wonder if our nation’s cryptography policy is being made by fools. It is a mixed blessing to learn that the people in charge are merely liars.” A good editorial.
http://www.zdnet.com/pcweek/stories/columns/…

OpenSSL, an open-source toolkit for SSL and TLS, version 0.9.3 has been released.
http://www.openssl.org/

Here’s a site that provides random primitive and irreducible polynomials, useful for stream-cipher construction.
http://fchabaud.free.fr/English/default.php3?…

U.S. banks are opening a lab to test computer security products.
http://www.news.com/News/Item/0,4,36923,00.html

The Electronic Telegraph has an interesting feature on the security of safes: how they’re made, how they can be attacked. I never realized that safes were rated according to how much insurance you can get on cash contents.
http://www.telegraph.co.uk:80/et?…

Good news department: The U.K. has reversed its position on key escrow. Blair’s government has dropped a proposal that would have required it.
http://www.infoworld.com/cgi-bin/displayStory.pl?…

Someone wrote an Enigma-machine simulator that runs on an iButton. So you can have an Enigma-machine secret decoder ring.
http://www.javaworld.com/jw-08-1998/jw-08-indepth.html

The National Security Study Group (some government agency or another) launched a web site (http://www.nssg.gov) to encourage and gather public comment on national security in the 21st century. Be nice and don’t hack them for a week or so.
http://www.fcw.com/pubs/fcw/1999/0531/…

Send secret messages in DNA.
http://news.bbc.co.uk/hi/english/sci/tech/…
http://news.excite.com/news/r/990610/02/…
http://www.cnn.com/NATURE/9906/10/top.secret.dna.ap/ [dead link as of 1999-08-25]

CGHQ, the British NSA-equivalent, is moving. Their new site will house 4500 people, and should be completed by 2002. http://www.guardianunlimited.co.uk/Archive/Article/…

Germany goes on record as being in favor of strong cryptography. It seems they don’t trust the U.S. not to spy on them. http://www.wired.com/news/politics/0,1283,20023,00.html

Counterpane Systems News

The Black Hat Briefings ’99 is a Computer Security Conference scheduled for July 7 and 8 in Las Vegas, Nevada. DefCon is a hackers convention held the weekend after. Bruce Schneier will be speaking at both.
http://www.blackhat.com/
http://www.defcon.org/

The Doghouse: Shopping.com

For security-clueless shopping, you can’t beat this one: “Shopping.com uses RSA Laboratories commercial encryption suited for U.S. export (RC4-Export, 128 bit with 40 secret). What does that mean to you? RSA protects your sensitive communications over the Internet (such as a credit card number) by transforming the data into an unreadable format. Furthermore, Shopping.com ensures the privacy of the information not only online, but through our back-end systems.” Wow. I am in awe.

http://www.shopping.com/store/INFO/INFO_SECURE.ASP?…

The Other Doghouse: ChecksNet

You too can send your bank account name and routing information in the clear over the net. Order your checks from these people. Their Web page clearly states: “ChecksNet protects your personal and bank account information from theft or misuse by encoding and scrambling the data as it is transmitted from this website to us.” However, the order form is sent in the clear; they don’t use SSL.

http://www.checksnet.com/order.htm

Hacking Archives on the WWW

There’s a lot of hacking information on the WWW, but you have to take the time to look for it. Typing “hacker archive” into AltaVista results in over three million hits. Yahoo’s information is much better organized, but there’s still a lot of pages to wade through.

A great starting site is http://www.infoworld.com/cgi-bin/displayNew.pl?/…. These guys write a weekly security column for InfoWorld, and their site is a wealth of useful security links. When I’m looking for something, I usually go there first.

The content site I spent the most time at was http://www.genocide2600.com/~tattooman/main.shtml , because it seemed well-organized. Nevertheless, it was clear that this is an archive, not a directory. If you’re trying to find a particular hack for a particular piece of software on a particular operating system, expect to spend some time searching. The material is sorted by general category, but the descriptions are limited. On the other hand, if you’re looking for write-ups of the latest security holes and exploits, it’s neatly sorted by date.

For a non-hacker like me, most of this material is way beyond my level of expertise. Still, there’s also a fair amount of scary and useful stuff. Just reading through the archive descriptions is enough to make anyone lose faith in any kind of network security. In addition to the vulnerabilities and exploits, there are Windows, Novell, and Unix security tools; password crackers; miscellaneous hacking tools; general utilities; and—just in case you’d forgotten that hacking was a subculture—humor archives. There are also links to archives of hacker discussion lists.

Other archives include:

The Electronic Frontier Foundation “hacker” archive. http://www.eff.org/pub/Net_culture/Hackers/

The archives for 2600 Magazine and for Phrack Magazine.
http://www.2600.com
http://www.phrack.com [link dead; try http://www.phrack.org/]

And Netscape’s hacker page, with links to major hacker sites on the Web.
http://directory.netscape.com/Computers/Hacking/

This last one is the Web page I found most interesting, in the abstract. Hacking has come of age, if Netscape lists the links openly, instead of trying to pretend they don’t exist. In general, hackers (at least in their public face) are more interested in penetrating systems and exposing vulnerabilities than in causing damage or stealing money. But most sites are still have legal disclaimers about how the information is only for educational purposes and is not intended to be used to commit the crimes that could be attributed to the information provided. First amendment or not, much of this is a gray area.

International Encryption Policy

EPIC has released its “Cryptography & Liberty 1999: An International Survey of Encryption Policy.” This is an excellent survey on international encryption policy (it runs about 130 pages), produced by the Electronic Privacy Information Center (EPIC).

Here’s the executive summary:

“Most countries in the world today have no controls on the use of cryptography. In the vast majority of countries, cryptography may be freely used, manufactured, and sold without restriction. This is true for both leading industrial countries and for developing countries. There is a movement towards international relaxation of regulations relating to encryption products, coupled with a rejection of key escrow and recovery policies. Many countries have recently adopted policies expressly rejecting requirements for key escrow systems and a few countries, most notably France, have dropped their escrow systems. There are a small number of countries where strong domestic controls on the use of cryptography exist. These are mostly countries where human rights command little respect.

“Recent trends in international law and policy point toward continued relaxation of controls on cryptography. The Organization for Economic Cooperation and Development’s Cryptography Policy Guidelines and the Ministerial Declaration of the European Union, both released in 1997, argue for the liberalization of controls on cryptography and the development of market-based, user driven cryptography products and services. There is a growing awareness worldwide of encryption and an increasing number of countries have developed policies, driven by the OECD guidelines.

“Export controls remain the most powerful obstacle to the development and free flow of encryption. The revised December 1998 Wassenaar Arrangement may roll back some of the liberalization sought by the OECD, particularly by restricting the key lengths of encryption products that can be exported without approval licenses. However, several major countries have already indicated that they do not plan to adopt new restrictions.

“The United States government continues to lead efforts for encryption controls around the world. The U.S. government has exerted economic and diplomatic pressure on other countries in an attempt to force them into adopting restrictive policies. The U.S. position may be explained, in part, by the dominant role that national intelligence and federal law enforcement agencies hold in the development of encryption policy.”

http://www2.epic.org/reports/crypto1999.html

International Encryption Products

The ACP has commissioned a study on the availability of international encryption products. It’s called “Growing Development of Foreign Encryption Products in the Face of U.S. Export Regulations.”

Here are excerpts from the executive summary:

“Development of cryptographic products outside the United States is not only continuing but is expanding to additional countries; with rapid growth of the Internet, communications-related cryptography especially is experiencing high growth, especially in electronic mail, virtual private network, and IPsec products. This report surveys encryption products developed outside the United States and provides some information on the effect of the United States export control regime on American and foreign manufacturers.

“We have identified 805 hardware and/or software products incorporating cryptography manufactured in 35 countries outside the United States. The most foreign cryptographic products are manufactured in the United Kingdom, followed by Germany, Canada, Australia, Switzerland, Sweden, the Netherlands, and Israel in that order. Other countries accounted for slightly more than a quarter of the world’s total of encryption products.

“The 805 foreign cryptographic products represent a 149-product increase (22%) over the most recent previous survey in December 1997. A majority of the new foreign cryptographic products are software rather than hardware. Also, a majority of these new products are communications-oriented rather than data storage oriented; they heavily tend towards secure electronic mail, IP security (IPsec), and Virtual Private Network applications.

“We identified at least 167 foreign cryptographic products that use strong encryption in the form of these algorithms: Triple DES, IDEA, Blowfish, RC5, or CAST-128. Despite the increasing use of these stronger alternatives to DES, there also continues to be a large number of foreign products offering the use of DES, though we expect to see a decrease in coming years.

“On average, the quality of foreign and U. S. products is comparable. There are a number of very good foreign encryption products that are quite competitive in strength, standards compliance, and functionality.”

http://www.seas.gwu.edu/seas/institutes/cpi/library/… [link dead as of 2000-09-22; try http://www.cpi.seas.gwu.edu/library/docs/…]

Comments from Readers

From: “John C. Kennedy” <transmog worldnet.att.net>
Subject: Novell

Having worked with Novell’s security group closely for the last three and a half years on cryptographic and network security issues, I want to point out a couple of things that aren’t quite apparent about the remote console password encryption hack that you report on in your latest newsletter. (Disclaimer: This is in no way an official response from Novell, merely a constructive comment by an informed party.)

The use of the remote console feature for managing NetWare servers is something that Novell has advised against for quite some time to begin with. Server console access is something that Novell strongly recommends be protected by physical access restrictions: http://developer.novell.com/research/appnotes/1997/…

Novell’s security experts have *always* considered the use of remote console capabilities to be a fundamentally risky proposition to begin with. Console access allows direct access to the NetWare trusted computing base. However, when customers demand such a feature and are willing to take the risk it is difficult for any company to say no.

If one assesses network security from a “weakest link in the chain” perspective, it is the fact that access to console services is available remotely *at all* that is probably a bigger risk than the weak password encryption technique employed. Console access is not something that should be granted based simply on single factor authentication, but in many “low threat” environments this is an acceptable risk/convenience trade-off to make.

The password obfuscation technique may seem amateurish at first glance, but it most likely has more to do with some exportability issue than lack of expertise or knowledge within Novell’s security group. The design pre-dates my association with Novell by a couple of years, but I am confident that it was not due to ignorance within the security staff. Obfuscation techniques are not something anyone likes to bet the farm on, and Novell’s strong caveats about the use of rconsole reflects this.

Novell has been working for the last couple of years on an architecture to permit strong encryption for authentication purposes without allowing that same capability to be exploited as an uncontrolled method for confidentiality. This is not an easy problem to tackle, but Novell’s new international cryptographic services architecture in fact solves this “crypto with a hole” problem for both Novell and its customers. (http://www.novell.com/corp/security/)

Regardless of one’s position on the crypto export issue, we all know that this has been a real problem for software and hardware vendors for quite some time. It is especially difficult to solve for companies that ship to so many different import/export jurisdictions. U.S. export laws are matched by equally restrictive import laws in many countries. The ability to field policy-controlled crypto will allow Novell to bring new network security mechanisms to the global market based on cryptography that is “strong” by anyone’s measure.

I think your chastising of Novell is well-intentioned, but fails to acknowledge that, (1) weak cryptography *is not* always the weakest link in the security chain and (2), that import/export laws have had predictable and, to date, largely unavoidable results in software designs destined for global markets. So-called “strong cryptography” can lend a false sense of security or be otherwise counterproductive when viewed in the larger context that many vendors have to address. A context that, in fact, most casual observers have neither the patience or necessary intimate knowledge to address.

From: “Robert A. Lerche” <ral msbit.com>
Subject: Microsoft’s Internet Explorer

MS IE does not provide a means for encrypting downloaded personal certificates. Netscape prompts for a password and encrypts local storage (although I think you’re allowed to specify a blank password), but MS IE doesn’t.

From: “Jack Hewlett” <jackhewlett hotmail.com>
Subject: Who’s at risk?

You continually publish articles saying how bad various security software products are. So the obvious question is, “Who’s at risk here, the Retailer or the Consumer?” I’ve never understood the need to be secretive about my Credit Card Numbers. It seems to me, I could publish my Credit Card number in the newspaper, and I would not be at any risk!

If a charge appears on my monthly statement and I can show the following:
1. The merchandise was NOT shipped to my address.
2. The Retailer does NOT have a piece of paper containing my signature.
3. The Retailer does NOT have a recording containing my voice. then surely I’m under no legal obligation to pay that portion of the bill.

This is a very important topic for the individual. If all the risk associated with weak security software falls on the Retailer, then I don’t have to care about this topic.

If my suppositions are incorrect, then how do I protect myself against all the clerks who see my Credit Card Number when I use it in a retail establishment? I understand that I have legal obligations to report a card stolen when I no longer have physical possession of it. But, since it is impossible for me to control knowledge of the Number (and Expiration Date), can the “fine print” of the Credit Acceptance I signed hold me fiscally responsible for something I can’t control? Even if I did sign such terms, would they hold up in court, when I argue that I did nothing wrong and acted in a prudent manner?

From: Geoff Thorpe <geoff raas.co.nz>
Subject: Hacking root CAs in Internet Explorer

I note my mate Peter Gutmann’s email about substituting root CAs into IE’s “certificate store”. I think I actually alerted him to this, and the problem remains in more recent versions. IE Version 4 also registers the “.der” file extension so that an ASN encoded self-signed X509 CA certificate saved as cert.der and double-clicked will automatically launch the “Accept new CA cert?” dialog of IE. By default, all the options are enabled (ticked), including authenticating client and server certs (https), authenticating email certs (S/MIME), and software signing (Authenticode). Even the default button is “OK,” so hitting enter is enough. They have, however, added a new dialog box, so that selecting OK gives a quick “Are you sure” type warning, displays all the information about the cert (distinguished name components, expiry dates, etc.) and the default button in this case is “No” (you have to click Yes to accept it). This still does not address the fact that most users will not really grasp the gaping security hole this creates for them—though at least Netscape Communicator goes some way towards letting them know you REALLY should check up on the cert’s authenticity before giving it too much trust—and they have a neat option to always provide warnings when using certs signed by the new CA cert in question.

There’s a very dangerous attack permitted by this lax attitude towards accepting CA certs. If you can get anyone with an Authenticode signing key (perhaps a developer has a signed cert from Verisign or whoever) to accept a phony CA cert, then all hell can break loose. You can then get native code in a signed .cab file (signed with a cert that is signed from the phony CA) onto the developer’s machine (it’s now trusted, so they will not be given warnings—and depending on their settings, they may not even be *told anything*). That native code can use MS’s CryptoAPI to retrieve the developer’s Authenticode private key (in typical fashion, the API does not require a password to retrieve the key) and mail it out to the hacker. That hacker then has someone else’s code-signing cert and key. Using it, they can put signed viruses around, and provide signed hacked versions of software (perhaps providing a “mirror” of popular software all of which is really just dressed-up and highly creative “fdisk” variations)—and if law enforcement ever get involved, their only lead will be the unfortunate developer’s Authenticode cert. Of course, if the hacker can plant phony CA certs around everywhere, he/she can always just create their own phony CA-signed Authenticode certs (perhaps named “Microsoft Corp.”) and use those. But the point being illustrated here is that the hacker only needs to get the phony CA into *one* developer’s machine (not everybody they want to hack); after that, he/she has someone else’s digital identity with which to wreak havoc.

But this brings me around to an issue I had been wanting to mention, and relates to a background project of mine. Microsoft has its own cert-trust settings, store, and API (if any at all); so does Netscape, so does any S/MIME-enabled mailer, so does any secure tunneling utility, etc. etc. Not only has this led to a complete decentralisation (it’s pretty much “per-application”) on a user’s system as to his/her “trust” settings, it has also led to the inevitable incompatibilities of standards—just ask anyone working for a CA about processing cert-requests for IE (and each version thereof), Navigator, and the popular web-servers. They’re all various mutations and modifications of ASN, X509, PEM, and MIME that give massive headaches for anyone who wants to dream of cross-compatibility (as of now, I don’t know anyone who has managed to make a single user-cert (with private key) work on Communicator and IE simultaneously).

My idea had been loosely termed the “PKI kernel”—a core library and interface that is presumed present and callable on all systems being compiled and deployed. Unlike the proliferation of various PKI toolkits using various standards (PKIX, etc.) and proprietary interfaces, I wanted to just put the minimum necessary core in to allow some centralisation—and to ensure it was thin enough that it did not impose functional restrictions on applications using it. E.g., I was thinking that this should not be a “provider plug-in” architecture, as its very benefit would come from it being singular and ubiquitous on a system. It would not provide any cryptographic tools (ciphers, PKC encryption, etc.), and it would not provide any services (SSL tunneling, SSH, etc.)—it would simply be a way to centralise root certs, user certs, pending cert-requests, and private keys, and maintain policies as to their use. At its most rudimentary, it could just be a free-for-all cert repository. At its more refined, it could be a strict framework where a root-user has stipulated that policies are inherited from another system and that only certain certs can be used for certain things. E.g., an app can ask the core for a list of “user certs” for use with “https” or check if a particular CA cert is trusted for a certain task, the policy could stipulate that any signed (user) certs imported into the core for use with S/MIME must be at least 1024 bits and signed by the “X” CA, etc.

It just seems that each operating system has one concept of “print management”, or “the TCP/IP stack”, etc., and yet every single crypto-enabled program seems to have its own concept of trusted root certs, cert-policies, key-usages, and all the incompatibilities that come with them. They all use the same “protocols” (SSL/TLS, S/MIME, etc.), and they all use the same “algorithms” (RC4, RSA, etc.), because everyone sensibly agrees that it’s best to just get one standard right than many different standards simultaneously, yet it’s often overlooked that authenticity and identification depend very much on the careful and coordinated handling of certification, which every application seems to want to have its own individual poke at.

CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security.

To subscribe, visit http://www.schneier.com/crypto-gram.html or send a blank message to crypto-gram-subscribe@chaparraltree.com. Back issues are available at http://www.schneier.com. To unsubscribe, visit http://www.schneier.com/crypto-gram-faq.html.

Please feel free to forward CRYPTO-GRAM to colleagues and friends who will find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.

CRYPTO-GRAM is written by Bruce Schneier. Schneier is president of Counterpane Systems, the author of Applied Cryptography, and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a frequent writer and lecturer on cryptography.

Counterpane Systems is a six-person consulting firm specializing in cryptography and computer security. Counterpane provides expert consulting in: design and analysis, implementation and testing, threat modeling, product research and forecasting, classes and training, intellectual property, and export consulting. Contracts range from short-term design evaluations and expert opinions to multi-year development efforts.

Sidebar photo of Bruce Schneier by Joe MacInnis.