Practical Cryptography

jpetts writes "If you have an interest in cryptography and spend even a small amount of time looking at the subject on the Internet, you will almost certainly have come across the name Bruce Schneier. His book, Applied Cryptography is widely regarded as the most accessible, and one of the most important books on cryptographic algorithms ever published. Schneier has also published other books, including the less technical Secrets and Lies, an thought-provoking book aimed at getting people to think about the whole of the security landscape, not just cryptography. Now, together with Niels Ferguson, renowned cryptographic expert, and longtime collaborator, another immensely valuable book on security has just appeared." Read on for the rest of jpetts' review. Practical Cryptography author Neils Ferguson and Bruce Schneier pages xx + 410 publisher Wiley rating 10/10 reviewer James Petts ISBN 0471223573 summary Pure Hands-On Cryptographic Gold; invaluable guide for cryptographers.

Schneier is one of the world's foremost experts, not just on cryptography, but also on security. It was as he delved deeper into the security of cryptographic systems that he realised that even though - theoretically at least - cryptography could be made arbitrarily secure, this was one of the more tractable problems in the security puzzle. For this reason, his company, Counterpane repositioned itself as a managed security company, rather than continuing to focus solely on cryptography. This transition was also reflected in his publication of Secrets and Lies (SL), which is very different in tone and focus from Applied Cryptography (AC). So where does Practical Cryptography (PC) fit in, and what does it offer? For me, the answer is that it lies pretty much squarely in the middle of the line reaching from AC to SL.

There is no shortage of products in the cryptography arena, but the vast majority of these attract undisguised scorn from professional cryptographers (at least those who can be bothered to comment on them), and although I am only an amateur in this field, I take it as axiomatic that only peer-reviewed cryptosystems (algorithms, protocols, etc) which have stood the test of time are worth taking even a preliminary peek at. This includes many that are described in AC. However, One of the problems with AC, openly acknowledged by the author, is that it contains essentially no implementation details. Furthermore, the cryptographic field has moved on since its publication, most notably with the adoption of Rijndael as the Advanced Encryption Standard, now a mandated Federal Information Processing Standard.

The source code to AC has been available from pretty much the moment of the book's publication, but one of the problems which faced a would-be cryptographic coder, is how to produce a working cryptographic product based on the routines that one could lay one's hands on. Merely incorporating the source code in a program does not a cryptosystem make: as Schneier points out cryptography is hard. And this is where this new book is invaluable: it tells you in great detail how hard it is, what the hardest parts are, and how you can maximise the return on the effort you may invest in developing cryptographic software.

The book pulls no punches, and does not gloss over any issues relating to implementing cryptographic systems. It deals with all the major components of a practical cryptosystem: the book's major sections are titled Message Security, Key Negotiation, Key Management and Miscellaneous.

Within each of these sections there are several chapters, covering virtually all the salient points imaginable, right down to the fundamentals. For example, the first chapter of the Key Management section deals with the clock. It explains from first principles the need for a clock: "At first glance, [a clock] is a decidedly un-cryptographic primitive, but because the current time is often used in cryptographic systems, we need a reliable clock." It is this sort of attention to particular implementation details that turns PC from a mere recipe book into an invaluable reference and a true cookbook.

Another invaluable feature is the generous use of pseudocode snippets, not only for algorithmic details, such as MACs and block cyphers, but also for higher-level operations like sending and receiving messages.

Ferguson and Schneier are refreshingly frank, too. Where they believe strongly in something, they let you know it. For example, the first paragraph of chapter 23, Standards, contains the statement that "[s]ecurity standards rarely work," while the authors go even further when dealing with X.509 certificates, stating on p.339, "[w]hatever you do, stay away from X.509 certificates. If you need a reason, read [40] and weep". This candour is refreshing, especially when juxtaposed with the weasel words that so many consultants and software vendors seem to rely on. However, this advice is not just given in curmudgeonly fashion, and when the authors discuss the matter of X.509 in a different context, they add, humorously, "[i]f you must use X.509, you have out condolences."

I am tempted to continue to analyse the book at great length, but to save space I will just highlight some further jewels from this work:

• Implementation issues such as swap files, language-specific memory handling behaviour, caches, etc. are covered in enough detail for you to understand how to do things, and more importantly, how not to do things.
• Randomness, pseudo-randomness and entropy are covered in enough depth for an implementor to avoid pitfalls, and pseudocode examples are given.
• Mathematical topics such as prime numbers, groups and large integer arithmetic are described in excellent detail.
• PKI, its promise, and failure are covered with wit and wisdom.

As you can probably guess from the above description, I believe that the real value of this book lies in the fact that two renowned experts, in both theory and practice, are sharing what works, and more importantly what you should avoid like the plague when working with cryptosystems. This information has until now generally only been available by listening to people like Schneier and Ferguson talk, either one-to-one or at conferences. Even then, the authors point out that even talking to "experts" is not without danger: chapter 25 begins "There is something strange about cryptography: everybody thinks they know enough about it to design and build their own system. We never ask a second-year physics student to design a nuclear power plant. We wouldn't let a trainee nurse who claims to have found a revolutionary method for heart surgery operate on us. Yet people who have read a book or two think they can design their own cryptographic system. Worse still, they are sometimes able to convince management, venture capitalists, and even some customers that their design is the neatest thing since sliced bread." Given this statement, some people might claim that this book is a little hubristic, but I disagree. Paranoia, self evaluation and a healthy scepticism are pre-requisites for assessing, deploying and implementing cryptosystems, but since a sine qua non of reliable crypto is open examination and peer evaluation, I believe that the authors are here simply offering advice, which once you understand more about the issues surrounding crypto, is merely common sense. Schneier and Ferguson have both "earned their bones" in the glaring light of crypto, and this book admirably fills an obvious gap in the literature of the field. There is not, to my knowledge, another book like it on the subject, and had it been published at around the same time as AC, I am sure that it would have been regarded by the NSA as even more dangerous than that book. After all, it is frighteningly easy for the uninformed to take good cryptographic algorithms and protocols, and through ignorance turn them into worse-than-useless crypto products.

Is there anything I didn't like about the book? Frankly, no. Some might complain that it is priced too high (it lists at USD50 for the softcover, and USD70 for the hardcover), but it is printed on acid-free paper, and the density of useful advice is such that it outstrips in value many works which cost half the price or less.

If you are interested in crypto, do yourself a favour: buy this book.

You can purchase Practical Cryptography from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

DMCA

[ih8apple]

Isn't this review a violation of the DMCA?


I'm not joking...if you take the wording of the law literally?

Re:DMCA

[Anonymous Coward]

Encryption algorithms don't usually control access

Considering that the only reason to use an encryption algorithm is to control access to a message, I have to say you don't have a clue what you're talking about. Not only that, your humor detection circuit seems to be on the fritz.

Too expensive?

[analog_line]

Is there anything I didn't like about the book? Frankly, no. Some might complain that it is priced too high (it lists at USD50 for the softcover, and USD70 for the hardcover), but it is printed on acid-free paper, and the density of useful advice is such that it outstrips in value many works which cost half the price or less.

Taking a look at my paperback copy of Applied Cryptography, it's listed at $55, so I hardly consider that any more expensive. And I paid full cover price for this bugger, as opposed to getting it online for a song, like I should have.

I don't think Applied Cryptography had a hardcover edition available, at least of the Second Edition. I certainly may consider picking that thing up. Hopefully it'll be able to stick together for awhile.

And on another note, what isn't printed on acid-free paper these days? Aside from little paperback novels, etc. I thought that was all done away with.

On a somewhat related note,

[Anonymous Coward]

I wish that the bignum libraries were a little more straightforward. For example, lots of cryptographic algorithms involve enormous numbers like 1024 bit primes and so forth. But I think libcrypto's bn_* function family is something like 4000 lines of code, and GMP is enormous too. For secure applications, I want to be able to understand and audit the entire library, so I wish they were written for readability instead of speed or whatever they're currently going for. The encryption protocol is useless if there is an overflow on line 8 billion of some underlying library.

Re:On a somewhat related note,

[nestler]

I think it is somewhat unreasonable to expect a big number (BN) library to be completely transparent on a casual reading. Public key (BN) operations in software are very slow. The OpenSSL implementation uses every optimisation it can to speed up its BN operations, just like compiler writers do everything they can to optimize the compiler output.

Did you write your own compiler? No, well have you read every line of gcc? Especially all of the complicated optimizer that makes the binary run faster? Even if you wrote a very dumb BN library that was easier to read, you would still have to worry about an "overflow on line 8 billion of some underlying library" (your compiler in this case).

I agree that OpenSSL's BN library could be better documented internally, but I don't think they should unoptimize it for clarity. People want transparent crypto, meaning they don't like experiencing 100-fold slowdowns when they add crypto to their application. BN optimization is critical in minimizing this slowdown (CRT, Montgomery reduction, sliding windows, Karatsuba, etc.).

Re:Practical vs Applied

[Anonymous Coward]

I'm sorry, but it is attitudes (and books) like these that give rise to the woeful state of affairs that have existed in "practical cryptography" over the years. Schneier's book, while certainly well-meaning, has promoted the idea that you don't need to understand formal notions of security to be a serious cryptographer. It is hard to overestimate the damage that this idea (and this) book have caused.

Currently, the only way to argue that a cryptosystem is secure is by reducing its security to that a well-studied primitive, like factoring, DLP, even DES! (Of course, it is true that we don't currently know of any explicit intractable problems, but if you are going to use a cryptosystem handed to you on a platter, better to know that its security has an undeniable link to factoring than merely that some group of software engineers somewhere couldn't find a way to break it.)

The point is that there is no "royal road" to cryptography. If you want to be a serious cryptographer, you need to get your hands dirty: understand what a reduction is, learn some complexity theory, learn some computational number theory. Of course, it is fine for end users or businesses to use prepackaged systems if they trust them. The dangerous road is the middle road, where we have "experts" who don't really understand the foundations of the subject.

If you want a laugh, read the description of pseudorandomness in Schneier's book and cf. that of, say, Goldreich's.

speaking of experts

[Anonymous Coward]

Has Slashdot considered adding a little about the credentials of book reviewers, especially on more technical topics?

I am not in any way passing judgement on "jpetts" here. He, or she, is quite articulate, but could be anywhere from an expert with years of experience to someone who's "read a book or two" and talks a very good game.

Generally I try to assess a writer by coherence and consistency when I don't know the subject material myself. But that only gets one so far - and I usually spot some discrepancies when I do know the subject material.

So the rough outlines of the writer's experience would add (or subtract, as the case may be) a little confidence in their accuracy.