Review:
Cryptography Engineering, by Niels Ferguson, et al.
| Publisher: |
Wiley |
| Copyright: |
2010 |
| ISBN: |
0-470-47424-6 |
| Format: |
Kindle |
| Pages: |
384 |
Subtitled
Design Principles and Practical Applications,
Cryptography Engineering is intended as an overview and
introduction to cryptography for the non-expert. It doesn't dive deeply
into the math, although there is still a fairly thorough mathematical
introduction to public-key cryptography. Instead, it focuses on the
principles, tools, and algorithms that are the most concretely useful to a
practitioner who is trying to design secure systems rather than doing
theoretical cryptography.
The "et al." in the author summary hides Bruce Schneier and Tadayoshi
Kohno, and this book is officially the second edition of
Practical
Cryptography by Ferguson and Schneier. Schneier's name will be familiar
from, among other things,
Applied
Cryptography, and I'll have more to say later about which of the two
books one should read (and the merits of reading both). But one of the
immediately-apparent advantages of
Cryptography Engineering is that
it's recent. Its 2010 publication date means that it recommends AES as a
block cipher, discusses MD5 weaknesses, and can discuss and recommend
SHA-2. For the reader whose concern with cryptography is primarily "what
should I use now for new work," this has huge benefit.
"What should I use for new work" is the primary focus of this book. There
is some survey of the field, but that survey is very limited compared to
Applied Cryptography and is tightly focused on the algorithms and
approaches that one might reasonably propose today.
Cryptography
Engineering also attempts to provide general principles and simplifying
assumptions to steer readers away from trouble. One example, and the
guiding principle for much of the book, is that any new system needs at
least a 128-bit security level, meaning that any attack will require
2
128 steps. This requirement may be overkill in some edge cases, as
the authors point out, but when one is not a cryptography expert,
accepting lower security by arguments that sound plausible but may not be
sound is very risky.
Cryptography Engineering starts with an overview of cryptography,
the basic tools of cryptographic analysis, and the issues around designing
secure systems and protocols. I like that the authors not only make it
clear that security programming is hard but provide a wealth of practical
examples of different attack methods and failure modes, a theme they
continue throughout the book. From there, the book moves into a general
discussion of major cryptographic areas: encryption, authentication,
public-key cryptography, digital signatures, PKI, and issues of
performance and complexity.
Part two starts the in-depth discussion with chapters on block ciphers,
block cipher modes, hash functions, and MACs, which together form part two
(message security). The block cipher mode discussion is particularly good
and includes algorithms newer than those in
Applied Cryptography.
This part closes with a walkthrough of constructing a secure channel, in
pseudocode, and a chapter on implementation issues. The implementation
chapters throughout the book are necessarily more general, but for me they
were one of the most useful parts of the book, since they take a step back
from the algorithms and look at the perils and pitfalls of using them to
do real work.
The third part of the book is on key negotiation and encompasses random
numbers, prime numbers, Diffie-Hellman, RSA, a high-level look at
cryptographic protocols, and a detailed look at key negotiation. This
will probably be the hardest part of the book for a lot of readers, since
the introduction to public-key is very heavy on math. The authors feel
that's unavoidable to gain any understanding of the security risks and
attack methods against public-key. I'm not quite convinced. But it's
useful information, if heavy going that requires some devoted attention.
I want to particularly call out the chapter on random numbers, though.
This is an often-overlooked area in cryptography, particularly in
introductions for the non-expert, and this is the best discussion of
pseudo-random number generators I've ever seen. The authors walk through
the design of Fortuna as an illustration of the issues and how they can be
avoided. I came away with a far better understanding of practical PRNG
design than I've ever had (and more sympathy for the annoying OpenSSL
~/.rnd file).
The last substantial part of the book is on key management, starting with
a discussion of time and its importance in cryptographic protocols. From
there, there's a discussion of central trusted key servers and then a much
more comprehensive discussion of PKI, including the problems with
revocation, key lifetime, key formats, and keeping keys secure. The
concluding chapter of this part is a very useful discussion of key
storage, which is broad enough to encompass passwords, biometrics, and
secure tokens. This is followed by a short part discussing standards,
patents, and experts.
A comparison between this book and
Applied Cryptography reveals
less attention to the details of cryptographic algorithms (apart from
random number generators, where
Cryptography Engineering provides
considerably more useful information), wide-ranging surveys of algorithms,
and underlying mathematics.
Cryptography Engineering also makes
several interesting narrowing choices, such as skipping stream ciphers
almost entirely. Less surprisingly, this book covers only a tiny handful
of cryptographic protocols; there's nothing here about zero-knowledge
proofs, blind signatures, bit commitment, or even secret sharing, except
a few passing mentions. That's realistic: those protocols are often
extremely difficult to understand, and the typical security system doesn't
use them.
Replacing those topics is considerably more discussion of implementation
techniques and pitfalls, including more assistance from the authors on how
to choose good cryptographic building blocks and how to combine them into
useful systems. This is a difficult topic, as they frequently
acknowledge, and a lot of the advice is necessarily fuzzy, but they at
least provide an orientation. To get much out of
Applied
Cryptography, you needed a basic understanding of what cryptography can
do and how you want to use it.
Cryptography Engineering tries to
fill in that gap to the point where any experienced programmer should be
able to see what problems cryptography can solve (and which it can't).
That brings me back to the question of which book you should read, and a
clear answer: start here, with
Cryptography Engineering. It's more
recent, which means that the algorithms it discusses are more directly
applicable to day-to-day work. The block cipher mode and random number
generator chapters are particularly useful, even if, for the latter, one
will probably use a standard library. And it takes more firm stands,
rather than just surveying. This comes with the risk of general
principles that aren't correct in specific situations, but I think for
most readers the additional guidance is vital.
That said, I'm still glad I read
Applied Cryptography, and I think
I would still recommend reading it after this book. The detailed analysis
of DES in
Applied Cryptography is worth the book by itself, and
more generally the survey of algorithms is useful in showing the range of
approaches that can be used. And the survey of cryptographic protocols,
if very difficult reading, provides tools for implementing (or at least
understanding) some of the fancier and more cutting-edge things that one
can do with cryptography.
But this is the place to start, and I wholeheartedly recommend
Cryptography Engineering to anyone working in computer security.
Whether you're writing code, designing systems, or even evaluating
products, this is a very useful book to read. It's a comprehensive
introduction if you don't know anything about the field, but deep enough
that I still got quite a bit of new information from it despite having
written security software for years and having already read
Applied
Cryptography. Highly recommended. I will probably read it from cover to
cover a second time when I have some free moments.
Rating: 9 out of 10
I used to work for Bytemark, being a sysadmin and sometimes handling support requests from end-users, along with their clients.
One thing that never got old was marking DNS-related tickets as "resolved", or managing to slip that word into replies.
Similarly being married to a Finnish woman you'd be amazed how often Finnish and Finished become interchangable.
Anyway that's enough pun-discussion.
Over the past few days I've, obviously, been playing with DNS. There are two public results:
I ve been pondering co-ops, and their value in the world, lately. The
thought has come to mind that a co-op which ran a Certificate Authority
seems like an absolute no-brainer the members each contribute to the
operational costs (servers, software, and the eye-watering auditing
expenses) and in return get to issue all the domain-verified certificates
they like (and pay reasonable rates for organization-verified certificates,
and perhaps even EV certs).
I know there are some superficially similar examples of this idea out there
already. 
Last week was the
The summit has been great. It was my third OpenStack design summit, and the
first one not being a PTL, meaning it was a largely more relaxed summit for
me!
On Monday, we started by a 2.5 hours meeting with Ceilometer core developers
and contributors about the Gnocchi experimental project that I've started a
few weeks ago. It was a great and productive afternoon, and allowed me to
introduce and cover this topic extensively, something that would not have
been possible in the allocated session we had later in the week.
Ceilometer had his design sessions running mainly during Wednesday. We noted
a lot of things and commented during the sessions in our
Expiring my old 1024 bit GPG key
Today I have expired my old 1024 bit GPG, 0xAC583520, ten years and a bit after creating it, as part of my journey to become a DD. Since 2010 I've been using 0x069AAA1C instead, but up until now I haven't had done anything about the old key, also because revoking a GPG key is a permanent and unrevocable action. Thanks to an unnamed friend in Berlin who gave me the idea I can expire a key too, which basically has the same effect, except that is's possible to undo...
This is the fourth post in a series of posts (
I m holding a Debian packaging workshop for our trainees at 
I had a really productive day today actually working on Debian, as planned
for my Mondays.
I'm still working through my list of packages, trying to get them all
vaguely up to date for jessie. It's mostly just addressing Lintian issues
that mostly revolve around old standards versions, with the occasional new
upstream release. I've also been doing bug triage where the bugs aren't
overwhelming.
Today I made uploads for pssh (a new upstream release),
pymetrics (mostly
just a rebuild), rcs-blame (mostly just a rebuild) and
simpleproxy (mostly
just a rebuild).
I need to revisit simpleproxy, because I'm having problems convincing the
resulting binary to be linked correctly for relro. It's weird, because I'm
doing everything I'm supposed to be doing and I can see all the other
hardening flags being passed in except for this one.
I really like simplifying down debian/rules using dh,
that really makes things readable. You can see the useful stuff without
losing it in all the boilerplate. For some reason I was never a fan of CDBS,
but I'm quite liking dh. I think it's because it's less opaque than
CDBS.
Wow. 3G delta. I haven t booted this laptop for a while I think I m finally ready to make the move from gnome2 to gnome3. There are bits that still annoy me, but I think it s off to a good start. Upgrading perl from 5.10 to 5.14.
You probably know about 