Ferguson, Niels and Bruce Schneier, Practical Cryptography

There is still a chance of 2-128 that our IsPrime function will give you the wrong answer. To give you an idea of how small this chance actually is, the chance that you will be killed by a meteorite while you read this sentence is far larger. Still alive? Okay, so don’t worry about it. (p. 204)


Practical Cryptography is a nicely written, fun read about cryptographic computer systems. I thought it was going to be about deploying cryptographic systems, but instead it is a compendium of advice, tricks, design principles and frothy-mouthed rants directed at the designers and engineers of cryptgraphic systems. As such, it would also make a great evaluation guide for people purchasing and analyzing security systems. The advice the authors give to implementors could be interpreted as a checklist for buyers to look for when considering systems for purchase or deployment.

You’re going to spending at least 8 hours with this book, so ergonimics are important. The typesetting is very pleasant to look at (LaTeX, the math geek’s standard); however, the flimsy binding (not even as good as one of the cheap O’Reilly ones) makes the volume kind of annoying to physically manipulate, and does not withstand much wear and tear. For a USD50 paperback (410 pages), I expect better.

Practical Cryptography takes you through the implementation of a cryptographic system from start to finish, including:

It does a nice job of providing both easy answers (“Use algorithm A, it’s the best available”) and a clear presentation of the principles underlying the authors’ judgements. However, sometimes their advice falls flat; for example: “Error handling is too complex to give you a simple set of rules. This is something we as a community do not know enough about yet. At the moment, the best we can say is: be very careful.” (p. 257) Honesty is refreshing, but give us something!

There is a nice exposition of various classes of attack (birthday, meet-in-the-middle, timing and other side-channel attacks). There is also a nice explanation of cryptographic hash functions, and how “regular” hash functions are not sufficient for cryptography.

The authors are occasionally strident and always extremely reluctant to compromise, but thankfully much less hate-filled than e.g. C. J. Date in An Introduction to Database Systems. I think they take the right attitude for the most part, but see the section on The Problems, below.

Since I’m not a cryptographer or mathematician of any stripe, I’m not going to try to evaluate the correctness, quality or cryptographic tastiness of the authors’ math. (As of 21 June 2003, the known errata are few.) However, the math is relatively approachable (even for me, and I know very little math) and is well-tuned to the capabilities of the book’s presumed audience — it might even take things a bit too easily. While there are some sections where deep magic is referred to but not explained, the heavily referenced and long bibliography might satisfy the curious.


In many places Ferguson and Schneier appear to invalidate their own goals and methods.

Correct software has a specified functionality. If you hit button A, then B will happen. Secure software has an additional requirement: a lack of functionality. No matter what the attacker does, she cannot do X. This is a very fundamental difference; you can test for functionality, but not for lack of functionality. The security aspects of the software cannot be tested in any effective way, which makes writing secure software much more difficult than writing correct software. The inevitable conclusion is: Standard implementation techniques are entirely inadequate to create secure code. (p. 135, emphasis in original)

They assert in several places that the task at hand is impossible or pointless.

And given the choice between security and downloading a program that will show dancing pigs on the screen, users will choose dancing pigs just about every time. (p. 356)

Schneier also flogs himself for publishing Applied Cryptography, saying that the book is partly to blame for the proliferation of low-quality cryptographic systems out in the wild. That is an odd accusation, unless Applied Cryptography is somehow insufficient on technical grounds — a charge which I have heard nobody assert.

For all the book’s ideological brow-beating and advocacy of specific techniques, there is a surprising remark on page 130: “But none of the operating systems in widespread use is designed with security as a primary goal. The logical conclusion to draw from this is that it is impossible to implement a secure system.” First, there exist a fair number of operating systems which were desgined (or refactored) primarily with security in mind, including EROS, OpenBSD, TrustedBSD and Trusted Solaris. I seem to recall there was a trusted version of Windows NT, as well. Granted, most of these are not in “widespread use” — but why not?

Second, it is not necessarily the case that the supposed lack of securely-designed operating systems is due to the impossibility of the task. Maybe none exist because user/customer priorities lie elsewhere.

Even if they fail, these operating systems do have security as a (or the) primary goal. Since so much of the rest of the book takes a role of advocacy, it’s surprising the authors don’t try to advocate some of the secure operating systems in existence, to get them into more widespread use (and hence better tested!). For example, on page 139 the authors say, “Of course, most virtual memory systems do not make any serious attempt to keep the data secret, or to encrypt it before it is written to the disk.” But OpenBSD does ship with that feature, and a single switch turns it on.

The Problems

Wrong Focus

According to the authors, the greatest weakness in most security systems is the human component: “Key management is especially difficult because it involves people instead of mathematics, and people are much harder to understand and predict.” (p. 309) If that is the case, then why do we need this book about the technical aspects of cryptographic systems? While many cryptosystems have technical problems, wouldn’t user education help more?

There are many reasonably good security systems in wide deployment, the security of which is sometimes undermined by user behavior. Examples are SSL, SSH and passwords (not so great, but made worse by user habits). Ferguson and Schneier stress that a system is no stronger than the weakest link in the chain. Since humans are often the weakest link, shouldn’t we first dedicate our greatest effort to educating the users of security systems?

Perhaps the problem is that security consultants and normal people have vastly different priorities.

In some student houses it is customary for one person to go to the ATM and get cash for several people. The other students lend him their ATM card and PIN code. This is an eminently stupid thing to do, yet it is done by some of the supposedly smarter people in our society. As consultants, we’ve visited many companies and sometimes had work-related reasons to have access to the local network. It is amazing how much access we got. We’ve had system administrators give us unrestricted access to the research data, when all we needed to do was look at a file or two. If system administrators can’t get this right, ordinary users certainly won’t. [...] There is undoubtedly a lot of interesting research to do on human interactions with security systems. (p. 331)

Yet even Schneier himself has mismanaged cryptographic keys (p. 333, “lost” PGP key). (Even Phil Zimmerman has!) If high-profile security analysts and developers can’t get this right, ordinary users certainly won’t.

Research on human behavior with security systems needs to be funded and performed if we are to have any hope of developing computer systems capable of providing us the security and privacy we need. Authors like Ferguson and Schneier are well-placed to advocate this line of enquiry. More research into the user interfaces of security systems could help reduce the human-caused failures of security systems by making the more secure actions easier and less secure actions harder, hopefully while also reducing the extent to which security systems burden the user with things they don’t understand.

For example, web hosting companies could turn off the unsecure FTP and telnet services if only there were easy to use, high quality SSH and SFTP clients for all client operating systems (preferably shipped with the OS). Perhaps user interaction research could bring to light a way to easily get users to use public/private key pairs with SSH and SFTP as well, instead of weak passwords. Perhaps generating the keys and educating customers on their importance could be part of the customer sign-up process.

Self-justifying Industry?

Of all the rants in the book, the best has to be the chapter devoted to software patents:

Our current patent system is completely out of control. At best, patents are a necessary evil. At worst, they are an entirely legal form of fraud and blackmail. [...]

There is, of course, one group of people that consistently benefits from the patent system: the lawyers. No prizes foor guessing which professional group claims that the current system is workable, or even good. (p. 378)

While anyone with experience in the software industry will agree that software patents are an incredibly nasty mess1, their statement about lawyers leads to a dilemma for the authors.

If we can leave you with one piece of advice, it is to use cryptographic experts if at all possible. If your project involves cryptography, then you need input from an experienced cryptographic designer. Involve one in your project at the beginning. The earlier you consult a cryptographic expert, the cheaper and easier it will be in the long run. (p. 383)

Replace “cryptographic expert/designer” with “intellectual property lawyer”, and “cryptography” with “intellectual property”, and you’ll see the problem: priesthood.

Clearly, users and security consultants have different ideals, goals, limitations and priorities. Cryptography will not be practical until the designers of security systems take the strengths and weaknesses of humans into account.


For what it is — a guide for engineers and analysts — this book is an informative, fascinating and critical resource. While somewhat expensive for a chintzy paperback, it will more than pay for itself if you need it. However, it does not begin to address the larger problems of practical cryptography, which have very little to do with cryptography itself and very much to do with the humans whom cryptography was invented to serve.


  1. While they’ll almost certainly agree with that it’s a mess, they might not think the mess is a bad thing...