Here are several essays from the Internet on topics Will had hoped to get to during the talk. He wrote:

"Indeed, I brought several of these to the talk. But,... Its ad hoc nature put paid to that idea; I trust a look into these should repair some of the damage. None is mathematical nor very technical (no algorithm or protocol design or analysis, complex acounts of cryptanalytic attacks, ...), so all should be accessible to all. In addition, I have included a few brief pieces of my own which attempt to illuminate some normally obscure corners of the field, and even some diagrams of assorted algorithms and protocols. And finally, there is a brief reading list for those who really want to go farther.

All the pieces from the Web are in plain text format on the theory that it's most likely to be readable by all. This has the unfortunate effect of making links inoperable; the original pages are, however, still available and the links can be followed from them. I have highlighted some points with ***highlights*** as they seemed to me to be of particular importance. Most of my stuff is also in plain text on the same theory. The remainder (the algorithm page and the diagrams) are in RTF since they can't be translated at all readily to some more universally readable format. So I've left them in RTF. Word, WordPerfect, and several of the Linux word processors (eg, KWord, AbiWord, Star Office, Open Office, ...) should be able to read them without much trouble. NOTE: Some of the titles have been run together so as to avoid problems with software that doesn't like spaces in filenames.

In no particular order, then:

--- Why Cryptosystems Fail -- analysis and review of real world use (and misuse) of cryptography by a major industry. As RJA observes, there is little access to this sort of overview of actual deployed crypto systems since most major users have not been (and remain not) inclined to allow external public examination of their systems. Ross Anderson is a Professor at Cambridge University, an excellent writer (not all that common in this field, unfortunately), and a serious cryptographer on both the algorithm / protocol development side and the cryptanalytic side. He has a diverting taste for lurid name coinages (it was he -- or his group at least -- who coined the term Programming Satan's Computer for any effort to develop secure software, including crypto systems). He (and his team) developed one of the AES finalist encryption algorithms, and have been prominent in discovering workable attacks against the assorted smart cards (credit cards with micropower CPUs in them) widely used in Europe. His Web site is a rich source of pointers to responsible research, analysis, and public policy debate on security and crypto issues generally. The problem of distinguishing between responsible crypto information (especially on the Net) and the bogus (but superficially reasonable sounding) is as difficult in most respects as the problem of identifying good crypto algorithms/protocols, and then good crypto system designs using them, and then good implementations of those designs, and finally good configuration and use of those good implementations. Even luridly bogus information is sometimes sufficiently plausible to the non-crypto informed to guide purchase and use choices. Would be users should avoid being misled by the bogus, whether lurid or not.

--- Economics and Security Resource Page is RJA's Web site pages. Crypto is more than simply keeping folks out of your stuff, and the economics of the real world have serious consequences on what cryptography is adopted, what is banned, ... It's not merely a technical question. Chasing the pointers on the original page will give an enlightening view of many of the relevant issues.

--- The TCPA-Palladium FAQ is also from RJA's Web site. Note that all control of content on user computers (on behalf of whomever) will be done cryptographically, as this is the only even remotely feasible way to accomplish such things. Given the abysmal record of Microsoft in designing and implementing crypto (and security generally), the whole thing may be expected to bear a more than trivial resemblance to Swiss Cheese; the assorted intellectual property holders interested in controlling what is on, or runnable on, your computer may be less than pleased if MS runs true to form on this. On the other hand, maybe BG has gotten MS off the dime with his security initiative ("Now we're really going to care about this stuff"). Intel too has had toubles in its security products. Maybe they will escape their history as well? This an actual FAQ. There is another, from Microsoft, which is largely a sales piece explaining how everything will be just fine in this best of all possible worlds when Palladium (and TCPA too I suppose) are finally universally adopted. Maybe it should be called a Sales FAQ?

--- Why Cryptography Is Harder Than It Looks is from Bruce Schneier of Counterpane Labs. There are reasons why there is so much Bozo crypto on the market. They are related to universal human tendencies to fool ourselves, some of which are dealt with here. Crypto users should be aware that developers and vendors have a splotchy record at best. Schneier is a practicing cryptographer (he and his team invented the Blowfish and Twofish encryption algorithms; Twofish was an AES finalist) and an author and speaker. His prose more 'American' than RJA's, but almost as entertaining, and equally reliable.

Security Pitfalls in Cryptography is another essay from Schneier covering crypto pratfalls from another direction -- the attacker's. What you think about in attempting to figure out what to do about security is not necessarily what you need to think about. You must counter what the attacker could try, not what you think he (she or it) will try. Not at all the same thing. This is not ordinary engineering, a point that Schneier is very clear about. It cannot be designed, implemented, or evaluated in any ordinary engineering way. For instance, your estimate of your vulnerability to xxx attack is not necessarily your actual vulnerability. Likewise, your estimate of how interested in your computer, files, Internet identity, ... attackers might be is, on principle, not relevant to your risk. Your risk is related to the actual interest any single attacker (or his automated attack scripts) has now (or might in the future) in your machine, files, identity, info, ... combined with that attacker's competence as an attacker. Your kid sister wouldn't be, presumably, much of a risk because she doesn't know much about computers. But you don't know anything about many possible attackers; and that means you know nothing about their interest in you, their motivations generally, or about their competence. Telling yourself you do is merely self-delusional. Consider the following: Your machine, in particular, would be useful to some kinds of attackers simply because it exists and not because of anything on it or who you are or who your clients are or ... Indeed, some attackers might be interested in your clients' information (in files on your machine(s); see a letter to Mossberg in WSJ for Wed or Thurs 8 or 9 Jan 03 from a lawyer wondering if his clients' files on his machine are vulnerable. Mossberg, less than adequately, suggests a firewall product.), but some couldn't care less. They are interested in damaging information on your machines (sabotage, etiehr external or internal to your organization) or in using your machines to further an attack on someone else (you get the blame because your machines' IDs are on the attacks) or in counting coup (Hey, look at me! I broke into your machine) or an attack may be a purely automated one looking for vulnerabilities for future use (pointers to machines with credit card numbers on them, for instance, which probably have some value to some thief or other). This last attack has nothing to do with you at all -- no human probably even knows your machine(s) were probed.

Real-World-Security. And not necessarily cryptographic attacks either. Think about the example here of the California house breakers who used a chain saw to go through the walls. Good crypto systems divert attacks to easy targets. The OS, users, the system development process (new versions, patches, and all that), system administrators,... Another Schneier essay.

Snake Oil Warning Sign FAQ Some years ago, some crypto people tried to figure out how to identify Bozo crypto software. They got this far -- some signs and symptoms that might justify a preliminary diagnosis of bogus crypto. It's still pretty right on. Actually it's exactly right on; it just doesn't go quite far enough now, and didn't then either. See the next item.

Crypto-Gram, 15/02/99. Schneier produces a newsletter each month discussing this and that in the security and crypto world that has caught his attention. This issue contains what is essentially a supplement to the Snake Oil Warning Sign FAQ, only with real world examples. Things haven't gotten ***any*** better in the past 4 years. Watch out folks, there's a lot of real crud out there!

Who are these people? This is a somewhat lighthearted look at the dramatis personnae in most cryptographic papers and discussions. The comments on Trent and his fellows are seriously meant however. In the real world reliance on the trustworthiness of some third party invites new and more varied attacks and courts disaster. Calling Trent a PKI provider doesn't change anything but the name. See Schneier's comments on vulnerabilities resulting from poorly designed trust models.

a page of algorithms. This is part of a list of publicly known algorithms I put together some years ago. It's important to note that not one of these is Bozo Crypto quality. All were produced by serious crypto folks, and nearly all were published in the academic crypto literature. These are among the best algorithms we humans have ever managed to dream up. Count them all and then count those which have been broken. The ratio is not very inspiring, is it?

Below are links to a few diagrams on assorted algorithms and protocols. Might be of some interest in following the (somewhat detailed) operation of some of these.

asymmetric key encryption algorithms

'public key / private key' asymmetric key algorithm use in one-way communication
'public key / private key' asymmetric key algorithm use in two-way communication

Public Key Infrastructures -- 1 identity certificate creation
Public Key Infrastructures -- 2 typical operation
digital signatures using asymmetric key algorithms
cryptographic one-way hash functions
message integrity checking w/cryptographic message digest functions
symmetric key encryption algorithms
two-way communication using a symmetric key algorithm
distributed trust Public Key Infrastructure -- 1 certificate generation / endorsement
distributed trust Public Key Infrastructure -- 2 endorsement vetting / trust decision

Reading List a bibliography of books and references.



==============================

A note on what to do.
There was some comment on the lack of recommendations for what folks should do at the presentation. Partially this was due to the ad hoc nature of the talk and partially it was deliberate. Everyone's situation is different both in principle and in detail. What is to be protected varies from one person to another, one machine to another, and from one time to another. An attorney (or other professional) may have legal obligations to keep client information secure. Non-attorneys might not want their Quicken files (with their financial information, tax return stuff, ...) spread around. Others may want to keep information about amatory adventures secure. Different degrees of effort (time, money, learning about whatever, ...) to secure the information will be justifiable in these (and in all the other) cases. In principle then, the only ethical advice one can offer is to 1) learn enough about crypto to at least rule out most of the Bozo quality stuff and then chose among the remainder keeping in mind the value of what you are trying to secure with the crypto, or 2) hire someone to do the same (making sure somehow, that the person hired is not some Bozo Crypto rep him (or her) self). In either case, the crypto system chosen should:

1) use ONLY publicly known and unbroken encryption/message digest algorithms with key lengths sufficient to make brute force search infeasible by anyone.

2) use only publicly known and unbroken protocols (eg, for digital signatures or time stamping)

3) trust ONLY sources of information that YOU (not your consultant or anyone else) have explicitly decided are worthy of trusting the security of your information to. This specifically includes any use of "digital certificates" from any source, including any recommended by Microsoft, your uncle the Earl of Dartmouth, or your dog. That "everyone else" trusts Verisign, Thawte, the USPO, ... doesn't mean that you should. Remember that PKI systems rely on 'digital certificates' whose only useful property is a claim that this key here belongs to that entity (person, company, government agency, dog) there. It is in effect an electronic notary stamp. Nothing else, however whizbang impressive, is relevant. Would you trust a notary you have never met, is not licensed by any supervisory authority (however superficial), and whose stamp is accessible to whoever can get to or subvert the computer(s)? Maybe not.

4) use only crypto systems which manage (store, generate, use) keys very very carefully. Where are they stored on disk (if at all), how are they sent from here to there (if they are), ... ANY slop in this aspect of crypto system operation makes perfect choices (for all the other points here) pointless.

5) use only crypto systems which randomly generate keys (this is a hard problem and there are no good solutions) and which generate them on your site. NEVER accept any vendor that "streamlines" key generation in the interest of your or anyone's convenience.

6) use only crypto systems that run on secure operating systems. This is LARGE qualification, but a necessary one. If the key you supply to the crypto system is available to others through the local version of the ps command, or if the OS keeps it in the swap file, or ... It won't take all that much for an attack on the OS to subvert your crypto system.

7) use only crypto systems running on OS which are properly and securely installed, configured, and maintained. Not the same point as 7, but related.

8) use only crypto systems which have no whiff of snake oil about them.

9) always (ALWAYS -- no exceptions) use the crypto system you get properly. This means you (and all other users of it) must understand what proper use is, and do it. This means mastering some not so obvious things (reading the manual might be the first, sorry about that) and if the documentation is incompetent, incomplete, misleading, ... (all too common) understanding proper use of the crypto system may be impossible.

Open source has the virtue that those who can read code well can "reverse engineer" proper operation from the code, thereby avoiding the misleading instructions in the documentation. It also has the virtue that you can compile your own version from the source, reducing the chance of a Trojan Horse in a precompiled binary. It also increases the chance that someone in the public crypto community (who knows what he's about) will notice design or implementation blunders -- no guarantees though.

Checklists for choosing crypto systems are like too much strong drink for some of us. It's a vice I have sworn off, again and again. On the other hand, if you can choose your crypto system to meet each of the 9 points above, you'll increase your chances of avoiding some crypto blunder or other very considerably. No promises that you'll be secure, that the crypto system will be convenient to use, ... There are no good, easy, answers. There is no solution which simply solves YOUR problem --regardless of any marketing claims. The XYZ package might be optimum for you, but knowing it is hard. It takes careful consideration. Good luck with it all, Will"

Back to Home Page