Slashdot Mirror

rar42 writes "The Inquirer is reporting on an analysis of Vista by Peter Gutmann — a medical imaging specialist. This isn't the usual anti-Microsoft story — just a professional looking at what is going to happen to his computer if it is upgraded to Microsoft Vista. From the article: 'Windows Vista includes an extensive reworking of core OS elements in order to provide content protection for so-called "premium content", typically HD data from Blu-Ray and HD-DVD sources. Providing this protection incurs considerable costs in terms of system performance, system stability, technical support overhead, and hardware and software cost,' says Gutmann."

David Gerard writes "Security researcher Peter Gutmann has released A Cost Analysis of Windows Vista Content Protection, a detailed explanation of just what the protected-content paths in Windows Vista mean to you the consumer: increased hardware cost and even less OS robustness. 'This document analyses the cost involved in Vista's content protection, and the collateral damage that this incurs throughout the computer industry ... The Vista Content Protection specification could very well constitute the longest suicide note in history.'"

jkauzlar writes "Have you ever read a math book that was able to carry you through its proofs, heart racing, and make your skin tingle upon reaching its philosophically astounding conclusion? Rarely have I encountered such a book, but among those that I have found (such as the books written by Ian Stewart or Douglas Hofstadter), Gregory Chaitin's 'Metamath! The Quest for Omega' is a favorite. Chaitin takes the reader on a thrilling race through the history of computability research to arrive at the discovery of his own number, Omega." Read on for the rest of jkauzlar's review. MetaMath! The Quest for Omega author Gregory Chaitin pages 157 publisher Self-published e-book rating Excellent! reviewer Joe Kauzlarich ISBN n/a summary Limits of computability

Chaitin's goal is the casual reader's comprehension of an irreducible, uncomputable, and truly random real number. He doesn't actually find one of these numbers, of which there are an indenumerably infinite supply, but he comes as close as a person can to actually referring to it.

Does this sound mysterious (and a little weird)? It is! But this ties in to just the sort of problem mathematicians have been working on for the past hundred or so years. You may be familiar with Goedel's Incompleteness Theorem, in which he proves that no formal axiomatic system (FAS) is powerful enough to prove all of the true statements its notation can express. For a long time, many people were wondering if Fermat's Last Theorem could be one of these statements (although it was finally (and famously) proven by Andrew Wiles about a decade ago). This is the type of "metamathematical" problem Chaitin attacks with his arsenal of complexity and information theory.

Key to understanding the book's premise is understanding the problems involved in defining a truly random number. Chaitin works in binary, so it is easy to find a random number by flipping a coin multiple times, although defining what a random number is supposed to look like (without circularly using the word 'random') is impossible. If you can define exactly what it should look like, then you can use that definition to create (or compress (see below)) a random number. It would not, then, be random.

The next key word is 'reducibility' (or 'compressibility'). If a number is random then it cannot be reduced or compressed into a smaller equation or algorithm. The digits of pi appear to be random, but they are reducible. This entire infinitely long real number can be expressed with just a few symbols- 4*sum_(k=1)^n(((-1)^(k+1))/(2k-1)). The same is true with 'e' or the golden ratio. You might be aware of the distinction between denumerable and nondenumberable infinities-- Chaitin explains this in his book; in short, there are (at least) two kinds of infinite sets, those that map directly to the integers (e.g. the rationals) and those that don't (e.g. the reals). It has been shown that all computer programs may be mapped to integers and hence are denumerable. Any number that can be generated by a computer program (pi, e, etc) therefore is denumerable. For Chaitin's random real number to be truly random, we must look only at real numbers that are indenumerable (cannot be calculated-- otherwise it would be compressible).

Here is where we run into problems-- we can't possibly generate a random real number and we can't even define what it looks like! Chaitin discusses the philosophical arguments for the very existence of such a number, and in the end uses Turing's Halting Program idea to show that a random real number can exist-- and the random real number vaguely referenced in this way, he calls Omega, the halting probability. The probability that an arbitrary program halts is the random real number that Chaitin had been searching for.

But this is not giving away the ending by any means. In fact he tells us this before even embarking upon his journey. What is remarkable about the book is that, in plain English, and using ideas that a non-mathematician like myself can understand, in only 157 pages, Chaitin can explain the grandest ideas on the cutting edge of mathematics. "As you have no doubt noticed," began Chaitin's conclusion, "this is really a book on philosophy, not just a math book. And as Leibniz says... math and philosophy are inseparable."

Although the book can be read quickly and painlessly (there are only a few simple equations in the book), the insights it contains are profound and likely to stick in your brain for some time. Furthermore Chaitin's enthusiastic style is contagious and will leave you on the edge of your seat. He floats through dozens of interesting anecdotes about the great mathematicians-- Leibniz, Newton, Turing, Godel and others--, the process of mathematical discovery from the vantage-point of an actual mathematician, insights into the mind of a working mathematician, and the craft of mathematics, interjecting his own educated thoughts on all of these matters. His style is aimed towards those whose education in mathematics extends only a little past high school and the ideas are simply followed (don't worry if you can't follow my own explanations above; I'm not nearly as skilled an expositer as Chaitin!)

This book is available for free on Chaitin's own website (so why not give it a try?) and also at ArXiv.org. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

jkauzlar writes "Have you ever read a math book that was able to carry you through its proofs, heart racing, and make your skin tingle upon reaching its philosophically astounding conclusion? Rarely have I encountered such a book, but among those that I have found (such as the books written by Ian Stewart or Douglas Hofstadter), Gregory Chaitin's 'Metamath! The Quest for Omega' is a favorite. Chaitin takes the reader on a thrilling race through the history of computability research to arrive at the discovery of his own number, Omega." Read on for the rest of jkauzlar's review. MetaMath! The Quest for Omega author Gregory Chaitin pages 157 publisher Self-published e-book rating Excellent! reviewer Joe Kauzlarich ISBN n/a summary Limits of computability

Chaitin's goal is the casual reader's comprehension of an irreducible, uncomputable, and truly random real number. He doesn't actually find one of these numbers, of which there are an indenumerably infinite supply, but he comes as close as a person can to actually referring to it.

Does this sound mysterious (and a little weird)? It is! But this ties in to just the sort of problem mathematicians have been working on for the past hundred or so years. You may be familiar with Goedel's Incompleteness Theorem, in which he proves that no formal axiomatic system (FAS) is powerful enough to prove all of the true statements its notation can express. For a long time, many people were wondering if Fermat's Last Theorem could be one of these statements (although it was finally (and famously) proven by Andrew Wiles about a decade ago). This is the type of "metamathematical" problem Chaitin attacks with his arsenal of complexity and information theory.

Key to understanding the book's premise is understanding the problems involved in defining a truly random number. Chaitin works in binary, so it is easy to find a random number by flipping a coin multiple times, although defining what a random number is supposed to look like (without circularly using the word 'random') is impossible. If you can define exactly what it should look like, then you can use that definition to create (or compress (see below)) a random number. It would not, then, be random.

The next key word is 'reducibility' (or 'compressibility'). If a number is random then it cannot be reduced or compressed into a smaller equation or algorithm. The digits of pi appear to be random, but they are reducible. This entire infinitely long real number can be expressed with just a few symbols- 4*sum_(k=1)^n(((-1)^(k+1))/(2k-1)). The same is true with 'e' or the golden ratio. You might be aware of the distinction between denumerable and nondenumberable infinities-- Chaitin explains this in his book; in short, there are (at least) two kinds of infinite sets, those that map directly to the integers (e.g. the rationals) and those that don't (e.g. the reals). It has been shown that all computer programs may be mapped to integers and hence are denumerable. Any number that can be generated by a computer program (pi, e, etc) therefore is denumerable. For Chaitin's random real number to be truly random, we must look only at real numbers that are indenumerable (cannot be calculated-- otherwise it would be compressible).

Here is where we run into problems-- we can't possibly generate a random real number and we can't even define what it looks like! Chaitin discusses the philosophical arguments for the very existence of such a number, and in the end uses Turing's Halting Program idea to show that a random real number can exist-- and the random real number vaguely referenced in this way, he calls Omega, the halting probability. The probability that an arbitrary program halts is the random real number that Chaitin had been searching for.

But this is not giving away the ending by any means. In fact he tells us this before even embarking upon his journey. What is remarkable about the book is that, in plain English, and using ideas that a non-mathematician like myself can understand, in only 157 pages, Chaitin can explain the grandest ideas on the cutting edge of mathematics. "As you have no doubt noticed," began Chaitin's conclusion, "this is really a book on philosophy, not just a math book. And as Leibniz says... math and philosophy are inseparable."

Although the book can be read quickly and painlessly (there are only a few simple equations in the book), the insights it contains are profound and likely to stick in your brain for some time. Furthermore Chaitin's enthusiastic style is contagious and will leave you on the edge of your seat. He floats through dozens of interesting anecdotes about the great mathematicians-- Leibniz, Newton, Turing, Godel and others--, the process of mathematical discovery from the vantage-point of an actual mathematician, insights into the mind of a working mathematician, and the craft of mathematics, interjecting his own educated thoughts on all of these matters. His style is aimed towards those whose education in mathematics extends only a little past high school and the ideas are simply followed (don't worry if you can't follow my own explanations above; I'm not nearly as skilled an expositer as Chaitin!)

This book is available for free on Chaitin's own website (so why not give it a try?) and also at ArXiv.org. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

imaginaryNumber writes "Peter Gutmann distinguishes his renowned cryptographic library, cryptlib, from other security toolkits available by claiming it provides a 'coherent security model' that other toolkits omit. His criticism goes further to say that some security toolkits 'lack real security features altogether.' It comes as no surprise, then, that his recent book, Cryptographic Security Architecture: Design and Verification, is a 320-page paean documenting the coherence and the sure-footed construction of his security toolkit. I am a student of electronic privacy, cryptography, security, and mathematics, and I am an admirer of Peter Gutmann's work. He is prolific in the security field, and Gutmann's website at the University of Auckland is a good introduction to his work. I had the pleasure of meeting him recently in New Zealand, after he agreed to field some questions about his book. As you will read in my review, I highly recommend the book even though it has a handful of flaws. And while I have a great deal of respect for the author's work, I'm not ready to accept all of his ideas as gospel." Read on for the rest of imaginaryNumber's review. Cryptographic Security Architecture: Design and Verification author Peter Gutmann pages 320 publisher Springer-Verlag rating 8 reviewer imaginaryNumber ISBN 0387953876 summary A technical book about security architectures, verification techniques, and cryptographic software and hardware

Cryptographic Security Architecture is a technical book that focuses on security architectures, verification techniques, and cryptographic software and hardware. It is an excellent reference source that intricately captures the design process of a security toolkit that has been in use for several years across the globe. The security architecture presented in the book is platform-independent, but the book does touch on platform-specific issues when necessary, especially when cryptlib implementation details are described. The toolkit has been ported to a slew of platforms.

Even though the book and the toolkit benefit from each other's companionship, both can certainly stand alone. The reader doesn't have to be familiar with or even interested in cryptlib to gain from reading Cryptographic Security Architecture . In this review of the book I will keep toolkit discussion to a minimum. The semi-GPL cryptlib security toolkit is OSI-certified open source. The security toolkit includes an excellent user manual which is a formidable 310 pages.

The Passion of the Cryptographic Security Architecture

Cryptographic Security Architecture's first chapter covers the foundational software architecture and is a bit dull. I would hope that the target audience is familiar with basic subjects like object-oriented design and inter-object communications. Too much attention is given to what should have been prerequisite knowledge at the expense of security related matter. For instance, while Gutmann gives a lot of attention to basic object synchronisation (the Kiwi spelling, which is suitably preferred by him) he only alludes to a class of security issues involved with multi-threading. If you can make it through the first chapter, rest assured that Gutmann avoids this flaw in the rest of the book. To be fair, this back-to-basics review does well at underpinning the rest of the security architecture, even though it often reads like a software architecture primer.

The second chapter covers the security architecture, which features such things as permission-based access, least privilege and isolation, mediation, and other expected elements. The design goals include some common goals, like simplicity and efficient implementation. But three of the design goals represent the core philosophy of Gutmann's architecture: The separation of policy definition and enforcement mechanism, a verifiable design (practical vs. theoretical viability), and a flexible security policy.

The separation of the policy definition from the enforcement mechanism solves problems that exist in previous attempts at security architecture (e.g. some Orange Book-based systems hardcode the policy). One claimed benefit of separation is the reduction of complexity in the enforcement mechanism and the improved verifiability that simplicity brings. But I would argue that complexity has been shifted from the toolkit to the toolkit user, who can opt to configure their specialized security policy. What mechanism is going to be used to verify these user-defined policies? It's unlikely the toolkit user's policy will receive the scrutiny that the open source community bestows upon the factory bits.

But I may not fully understand the capabilities of the security policy scheme. Perhaps, when using Gutmann's cryptlib, it is impossible for the toolkit user to configure an incoherent policy. In George Orwell's 1984, the Party worked to deconstruct the English language so that only 'legal' speech could occur. As designed, Newspeak would make illegal statements unspeakable --- and in time, unthinkable. I'm unconvinced that Gutmann's security policy scheme is such a controlled means of expression, where only safe security policies can be spoken. Granted, one could always use the predefined policies, but this path undermines a chief design goal of the architecture: a flexible security policy.

Notwithstanding my nitpicking about the policy, the security architecture chapter is a good example of how the book shines. Gutmann covers in detail his design process and chocks the chapter full of references for the reader's further study. In all, there are almost 700 reference listings, which consume 15% of the book's 320 pages.

The policy definition scheme is followed by a detailed discussion of the security kernel implementation. (The kernel is the policy enforcement mechanism, referred to earlier.) Like most of the book, the writing is as dense as most detailed architectural designs and sometimes sleep-inducing. But Gutmann's writing style is clear, concise, and sometimes funny. Gutmann's writing talent makes even descriptions of "Access Control List for public-key/certificate access" and "Access Control List for an attribute that triggers an object state change" endurable.

Verification techniques for the security architecture are a major theme of the book. Anyone who has attempted to verify that software does what it was specified to do, especially in the security field, will find Gutmann's insights worthwhile reading. This is especially true for anyone who has ever done a Common Criteria-based evaluation, or a verification employing any of its ilk. Gutmann makes an excellent point about the semantic pitfalls of formal methods: "As with ISO 9000, it's possible to produce an arbitrarily bad product but still claim it's correct, since it complies with the paperwork."

Cryptographic Security Architecture also contains the obligatory chapter on random number generation. The chapter includes more of Gutmann's trademark insights. He discusses many software and hardware implementations, including the generators contained in: PGP (Pretty Good Privacy), /dev/random, ssh, Capstone / Fortezza, Intel Pentium III, Microsoft's CryptoAPI, cryptlib, and others. Random number generation flaws abound. For example, he discusses the flaws in the ssh and SSLeay/OpenSSL generators that make it possible to "...suck infinite amounts of state information out of [the random number generators] by repeatedly connecting to the server..."

Towards the end of the book, Gutmann includes a dessert-like discussion of hardware encryption modules. Gutmann's predilection for security hardware is evident as he writes about problems with crypto on end-user systems. This chapter includes all sorts of cryptographic hardware including the designed-for-hostile-environments HiDan embedded PC. One interesting technique to secure modules like the HiDan is to pour a hardening material (e.g. epoxy) into the chamber before sealing it shut.

Regarding the book's construction, while the references are excellent, the glossary and index are poor. Even if you rely on external sources for acronyms, as the author suggests, some of his acronyms are not included in the glossary. For instance, it took me awhile to determine that CMP stood for Certificate Mismanagement Protocol. The index is also oddly incomplete, considering Gutmann's otherwise good documentation habits.

Conclusion I expected Cryptographic Security Architecture to treat the topic of security architecture in a general way, offering many alternatives for designers to ponder while designing their own security architecture. The book does this, but often Gutmann whittles down the prudent design options to one, with most paths arriving at a single destination, namely Gutmann's cryptlib. Don't get me wrong: It's good to be decisive when faced with many architectural tradeoffs, and the ugly alternative is all too often design paralysis. And it's no surprise that cryptlib, according to Gutmann, contains the best architectural elements - he is the author of both the book and the toolkit. Still, the homage to cryptlib often made me unsure that a wide spectrum of design options had been considered: Did the security architecture spawn the cryptlib implementation, or did the implementation spawn the architecture?

To be clear, the strong points of the book (and concepts therein) far outnumber the weak ones, and I highly recommend it to anyone interested in security architectures, verification techniques, and cryptographic software and hardware in general. Simply put, the book is excellent and it should expand most reader's knowledge of cryptographic security.

You can purchase Cryptographic Security Architecture: Design and Verification from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

imaginaryNumber writes "Peter Gutmann distinguishes his renowned cryptographic library, cryptlib, from other security toolkits available by claiming it provides a 'coherent security model' that other toolkits omit. His criticism goes further to say that some security toolkits 'lack real security features altogether.' It comes as no surprise, then, that his recent book, Cryptographic Security Architecture: Design and Verification, is a 320-page paean documenting the coherence and the sure-footed construction of his security toolkit. I am a student of electronic privacy, cryptography, security, and mathematics, and I am an admirer of Peter Gutmann's work. He is prolific in the security field, and Gutmann's website at the University of Auckland is a good introduction to his work. I had the pleasure of meeting him recently in New Zealand, after he agreed to field some questions about his book. As you will read in my review, I highly recommend the book even though it has a handful of flaws. And while I have a great deal of respect for the author's work, I'm not ready to accept all of his ideas as gospel." Read on for the rest of imaginaryNumber's review. Cryptographic Security Architecture: Design and Verification author Peter Gutmann pages 320 publisher Springer-Verlag rating 8 reviewer imaginaryNumber ISBN 0387953876 summary A technical book about security architectures, verification techniques, and cryptographic software and hardware

Cryptographic Security Architecture is a technical book that focuses on security architectures, verification techniques, and cryptographic software and hardware. It is an excellent reference source that intricately captures the design process of a security toolkit that has been in use for several years across the globe. The security architecture presented in the book is platform-independent, but the book does touch on platform-specific issues when necessary, especially when cryptlib implementation details are described. The toolkit has been ported to a slew of platforms.

Even though the book and the toolkit benefit from each other's companionship, both can certainly stand alone. The reader doesn't have to be familiar with or even interested in cryptlib to gain from reading Cryptographic Security Architecture . In this review of the book I will keep toolkit discussion to a minimum. The semi-GPL cryptlib security toolkit is OSI-certified open source. The security toolkit includes an excellent user manual which is a formidable 310 pages.

The Passion of the Cryptographic Security Architecture

Cryptographic Security Architecture's first chapter covers the foundational software architecture and is a bit dull. I would hope that the target audience is familiar with basic subjects like object-oriented design and inter-object communications. Too much attention is given to what should have been prerequisite knowledge at the expense of security related matter. For instance, while Gutmann gives a lot of attention to basic object synchronisation (the Kiwi spelling, which is suitably preferred by him) he only alludes to a class of security issues involved with multi-threading. If you can make it through the first chapter, rest assured that Gutmann avoids this flaw in the rest of the book. To be fair, this back-to-basics review does well at underpinning the rest of the security architecture, even though it often reads like a software architecture primer.

The second chapter covers the security architecture, which features such things as permission-based access, least privilege and isolation, mediation, and other expected elements. The design goals include some common goals, like simplicity and efficient implementation. But three of the design goals represent the core philosophy of Gutmann's architecture: The separation of policy definition and enforcement mechanism, a verifiable design (practical vs. theoretical viability), and a flexible security policy.

The separation of the policy definition from the enforcement mechanism solves problems that exist in previous attempts at security architecture (e.g. some Orange Book-based systems hardcode the policy). One claimed benefit of separation is the reduction of complexity in the enforcement mechanism and the improved verifiability that simplicity brings. But I would argue that complexity has been shifted from the toolkit to the toolkit user, who can opt to configure their specialized security policy. What mechanism is going to be used to verify these user-defined policies? It's unlikely the toolkit user's policy will receive the scrutiny that the open source community bestows upon the factory bits.

But I may not fully understand the capabilities of the security policy scheme. Perhaps, when using Gutmann's cryptlib, it is impossible for the toolkit user to configure an incoherent policy. In George Orwell's 1984, the Party worked to deconstruct the English language so that only 'legal' speech could occur. As designed, Newspeak would make illegal statements unspeakable --- and in time, unthinkable. I'm unconvinced that Gutmann's security policy scheme is such a controlled means of expression, where only safe security policies can be spoken. Granted, one could always use the predefined policies, but this path undermines a chief design goal of the architecture: a flexible security policy.

Notwithstanding my nitpicking about the policy, the security architecture chapter is a good example of how the book shines. Gutmann covers in detail his design process and chocks the chapter full of references for the reader's further study. In all, there are almost 700 reference listings, which consume 15% of the book's 320 pages.

The policy definition scheme is followed by a detailed discussion of the security kernel implementation. (The kernel is the policy enforcement mechanism, referred to earlier.) Like most of the book, the writing is as dense as most detailed architectural designs and sometimes sleep-inducing. But Gutmann's writing style is clear, concise, and sometimes funny. Gutmann's writing talent makes even descriptions of "Access Control List for public-key/certificate access" and "Access Control List for an attribute that triggers an object state change" endurable.

Verification techniques for the security architecture are a major theme of the book. Anyone who has attempted to verify that software does what it was specified to do, especially in the security field, will find Gutmann's insights worthwhile reading. This is especially true for anyone who has ever done a Common Criteria-based evaluation, or a verification employing any of its ilk. Gutmann makes an excellent point about the semantic pitfalls of formal methods: "As with ISO 9000, it's possible to produce an arbitrarily bad product but still claim it's correct, since it complies with the paperwork."

Cryptographic Security Architecture also contains the obligatory chapter on random number generation. The chapter includes more of Gutmann's trademark insights. He discusses many software and hardware implementations, including the generators contained in: PGP (Pretty Good Privacy), /dev/random, ssh, Capstone / Fortezza, Intel Pentium III, Microsoft's CryptoAPI, cryptlib, and others. Random number generation flaws abound. For example, he discusses the flaws in the ssh and SSLeay/OpenSSL generators that make it possible to "...suck infinite amounts of state information out of [the random number generators] by repeatedly connecting to the server..."

Towards the end of the book, Gutmann includes a dessert-like discussion of hardware encryption modules. Gutmann's predilection for security hardware is evident as he writes about problems with crypto on end-user systems. This chapter includes all sorts of cryptographic hardware including the designed-for-hostile-environments HiDan embedded PC. One interesting technique to secure modules like the HiDan is to pour a hardening material (e.g. epoxy) into the chamber before sealing it shut.

Regarding the book's construction, while the references are excellent, the glossary and index are poor. Even if you rely on external sources for acronyms, as the author suggests, some of his acronyms are not included in the glossary. For instance, it took me awhile to determine that CMP stood for Certificate Mismanagement Protocol. The index is also oddly incomplete, considering Gutmann's otherwise good documentation habits.

Conclusion I expected Cryptographic Security Architecture to treat the topic of security architecture in a general way, offering many alternatives for designers to ponder while designing their own security architecture. The book does this, but often Gutmann whittles down the prudent design options to one, with most paths arriving at a single destination, namely Gutmann's cryptlib. Don't get me wrong: It's good to be decisive when faced with many architectural tradeoffs, and the ugly alternative is all too often design paralysis. And it's no surprise that cryptlib, according to Gutmann, contains the best architectural elements - he is the author of both the book and the toolkit. Still, the homage to cryptlib often made me unsure that a wide spectrum of design options had been considered: Did the security architecture spawn the cryptlib implementation, or did the implementation spawn the architecture?

To be clear, the strong points of the book (and concepts therein) far outnumber the weak ones, and I highly recommend it to anyone interested in security architectures, verification techniques, and cryptographic software and hardware in general. Simply put, the book is excellent and it should expand most reader's knowledge of cryptographic security.

You can purchase Cryptographic Security Architecture: Design and Verification from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

SiliconEntity writes "Cryptographer and security expert Peter Gutmann has demolished several Linux security software packages in a recent posting to the cryptography mailing list. He says, 'It's possible to create insecure 'security' products just as readily with open-source as with closed-source software. CIPE and vtun must be the OSS community's answer to Microsoft's PPTP implementation. What's even worse is that some of the flaws were pointed out nearly two years ago, but despite the hype about open-source products being quicker with security fixes, some of the protocols still haven't been fixed.'"

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.

ncostigan writes "Peter Gutmann of cryptlib fame has written a very readable paper on real-world constraints for cryptographers, and points out problems that their designs will run into when attempts are made to deploy them. Also included is a motivational list of extremely uncool problems that implementors have been building ad-hoc solutions for since no formal ones exist."

Jacky Baltes writes: "Thought that Deep Thought vs. Kasparov was a big deal. I am part of a research group that attempts to beat the world champion in Formula 1. The goal of the Man v. Machine Challenge is to design and implement a robotic system that can drive a F1 car faster than the current world champion. You can have a look at the progress at the Man v. Machine Challenge Web site . We will had some more technical details about our control system design, data fusion, and car model to the site later. So Michael, hold on to your head. Jacky Baltes"

A new monthly column Brave GNU World has started, with the mission to inform everybody about new GNU software. Apparently dd if=/dev/zero of=/dev/hda does not completely delete the contents of you hard-drive. You should use shred instead. Paul Smith wrote in to plug a Free lecture by Richard Stallman which is going to be held tomorrow - Tuesday 23 March at 7pm at the Commonwealth Institute in London. Finally, jbc wrote in with "In his latest 'Ask Tim' piece, Tim O'Reilly talks about the differences between himself and RMS in terms of how they view OSS/FSF licensing issues." null -> zero (*blush*)