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'm replacing my OTR key for XMPP because of heartbleed (see below). If the plain ASCII text below is mangled beyond verification, you can retrieve a copy of it from my web site that should be able to be verified. 
PyCon 2014 happened. (Sprints are still happening.)
This was my 3rd PyCon, but my first year as a serious contributor to the
event, which led to an incredibly different feel. I also came as a
person running a company building a complex system in Python, and I
loved having the overarching mission of what I'm building driving my
approach to what I chose to do. PyCon is one of the few conferences
I go to where the feeling of acceptance and at-homeness mitigates the
introvert overwhelm at nonstop social interaction. It's truly a special
event and community.
Here are some highlights:
We had a bit of a rough night last night. I noticed Zoe was pretty hot when she
had a nap yesterday after not really eating much lunch. She still had a mild
fever after her nap, so I gave her some paracetamol (aka acetaminophen, that
one weirded me out when I moved to the US) and called for a home doctor to
check her ears out.
Her ears were fine, but her throat was a little red. The doctor said it was
probably a virus. Her temperature wasn't so high at bed time, so I skipped the
paracetamol, and she went to bed fine.
She did wake up at about 1:30am and it took me until 3am to get her back to
bed. I think it was a combination of the fever and trying to phase out her
white noise, but she just didn't want to sleep in her bed or her room. At 3am I
admitted defeat and let her sleep with me.
She had only a slightly elevated temperature this morning, and otherwise seemed
in good spirits. We were supposed to go to a family lunch today, because my
sister and brother are in town with their respective families, but I figured
we'd skip that on account that Zoe may have still had something, and
coupled with the poor night's sleep, I wasn't sure how much socialising she was
going to be up for.
My ear has still been giving me grief, and I had a home doctor check it
yesterday as well, and he said the ear canal was 90% blocked. First thing this
morning I called up to make an appointment with my regular doctor to try and
get it flushed out. The earliest appointment I could get was 10:15am.
So we trundled around the corner to my doctor after a very slow start to the
day. I got my ear cleaned out and felt like a million bucks afterwards. We went
to Woolworths to order an undecorated mud slab cake, so I can try doing a trial
birthday cake. I've given up on trying to do the sitting minion, and
significantly scaled back to just a flat minion slab cake. The should be ready
tomorrow.
The family thing was originally supposed to be tomorrow, and was only moved to
today yesterday. My original plan had been to take Zoe to a free Dora the
Explorer live show that was on in the Queen Street Mall.
I decided to revert back to the original plan, but by this stage, it was too
late to catch the 11am show, so the 1pm show was the only other option. We had
a "quick" lunch at home, which involved Zoe refusing the eat the sandwich I
made for her and me convincing her otherwise.
Then I got a time-sensitive phone call from a friend, and once I'd finished
dealing with that, there wasn't enough time to take any form of public
transport and get there in time, so I decided to just drive in.
We parked in the Myer Centre car park, and quickly made our way up to the mall,
and made it there comfortably with 5 minutes to spare.
The show wasn't anything much to phone home about. It was basically just 20
minutes of someone in a giant Dora suit acting out was was essentially a
typical episode of Dora the Explorer, on stage, with a helper. Zoe started out
wanting to sit on my lap, but made a few brief forays down to the "mosh pit"
down the front with the other kids, dancing around.
After the show finished, we had about 40 minutes to kill before we could get a
photo with Dora, so we wandered around the Myer Centre. I let Zoe choose our
destinations initially, and we browsed a cheap accessories store that was
having a sale, and then we wandered downstairs to one of the underground bus
station platforms.
After that, we made our way up to Lincraft, and browsed. We bought a $5
magnifying glass, and I let Zoe do the whole transaction by herself. After that
it was time to make our way back down for the photo.
Zoe made it first in line, so we were in and out nice and quick. We got our
photos, and they gave her a little activity book as well, which she thought was
cool, and then we headed back down the car park.
In my haste to park and get top side, I hadn't really paid attention to
where we'd parked, and we came down via different elevators than we
went up, so by the time I'd finally located the car, the exit gate was trying
to extract an extra $5 parking out of me. Fortunately I was able to use the
intercom at the gate and tell my sob story of being a nincompoop, and they let
us out without further payment.
We swung by the Valley to clear my PO box, and then headed home. Zoe
spontaneously announced she'd had a fun day, so that was lovely.
We only had about an hour and half to kill before Sarah was going to pick up
Zoe, so we just mucked around. Zoe looked at stuff around the house with her
magnifying glass. She helped me open my mail. We looked at some of the photos
on my phone. 
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.
Between 2001 and 2004, 
Today I took down my KVM-host machine, rebooting it and restarting all of my guests. It has been a while since I'd done so and I was a little nerveous, as it turned out this nerveousness was prophetic.
I'd forgotten to hardwire the use of proxy_arp so my guests were all broken when the systems came back online.
If you're curious this is what my incoming graph of email SPAM looks like:
First of all, good news, MirBSD is not vulnerable to 
A new release of the
Using address extension
Postfix (and many other mail servers) offers one nice address
extension feature: addresses like
As 
There are several friends and family I want to be able to call with free software. The only way I could make it accessible to them was to burn 
WebRTC has been in the most recent stable releases of 
Users have 