Schneier on Security

I have observed that programmers, unfortunately, cannot conceive of the fact that some things are simply to complex for them to tackle.

I always recommend that programmers let a security specialist design their cryptosystems. They find the mere suggestion insulting; they are all sure they can figure it out just by reading the documentation.

It's not fair to blame Bruce for this, though. Few human activities are as complicated as programming. This fact drives the (usually justified) programmer hubris. Unfortunately, cryptosystems are among the few tasks which are more complex than programming.

Bruce said, "...will be published in early 2009..."

Cue the Bruce Schneier/Chuck Norris jokes.

Even the best surgeon in the world will lose a patient from time to time. It doesn't mean he didn't do a great job, and it doesn't mean the next 10 patients won't recover just fine. It simply means it is a complex area with many underlying factors often beyond ones control or even understanding. I believe the same holds true in complex areas of technology. It's hard, and skill isn't always enough.

@nick: "I always recommend that programmers let a security specialist design their cryptosystems. They find the mere suggestion insulting; they are all sure they can figure it out just by reading the documentation."
__________

Good point.

A good doctor will treat your condition well. A great doctor will provide a referal to a specialist who can do it better.

“To me the flow of time is irrelevant. You decide what you want. I then merely make sure that is has already happened.”
The Hitch Hiker’s Guide to the Galaxy
Bruce Schneier can publish in the past :)

Rule 1. You don't talk about the Cult of Schneier.
Rule 2. You don't talk about the Cult of Schneier.

Foxdie!

I thought I'd post this relevant quote from the book "Security Engineering (2nd edition)" by Ross Anderson. It's in the "further reading" section of the chapter on cryptography.

"The most popular introduction is Bruce Schneier's Applied Cryptography which covers a lot of ground at a level a non-mathematician can understand, but is slightly dated."

I don't know if there really is a cult of Schneier or not. I mean, there was a movie called "Bruce Almighty" a few years ago, but I haven't seen it so I don't know if it is about the same Bruce.

I'm not a crypto-geek; any cult of Schneier I might consider joining is one where Bruce talks sensibly about security matters, not one that is about cryptography. In other words, my Schneier bibles are more "Secrets and Lies" and "Beyond Fear" than "Applied Cryptography."

"It's not until someone takes the time to break it that the engineer could realize that he didn't do as good a job as he thought."

All the engineers I know are perfect. Just ask them.

@schneier:
"will be published in early 2009"

talking about the past in the future tense? it's already late 2009. did you mean 2010 or did you mean it was already published?

@Nick

> I always recommend that
> programmers let a security specialist
> design their cryptosystems.

As a programmer, thanks for that great advice.

In return, I give you this advice: because history shows that preventable automobile accidents are a leading cause of death, I recommend that you never drive a car yourself, but instead let a qualified professional chauffeur drive you around.

As the sole cryptographer in my company, every once in a while some programmer asks: how do I design a secure system to do ?
I always give the same answer "you don't".
On the puzzled look I try to explain Bruce's point above, and then we can start looking for a well known solution.

@P.E.
> All the engineers I know are perfect.
> Just ask them.

I'll do that. Please provide their contact info.

To echo the point of the first comment with a quote from Alexander Pope:

"A little learning is a dangerous thing; drink deep, or taste not the Pierian spring: there shallow draughts intoxicate the brain, and drinking largely sobers us again."

Obviously, no one should design cryptosystems based on a single book, neither AC or any other book -- educate yourself or let the professionals do the job.

All that being said, I think most people underestimate the impact AC has had on the fields of both cryptology and security engineering; it was the inspiration that led myself to study cryptology and security engineering and I know many others in the field that also read that and afterwards got into the field. It is a strange book, more a collection of essays than a textbook, but it is wellwritten and entertaining and most important, it is hard for a reader not to get inspired by the author's enthusiasm. AC is dated and has many subjects that are simply not relevant anymore, but this is still the book I recommend students wanting to know a little about the field to check out from the library first to take a look at.

I would really, really like to have an accurate, terse, sourced, and complete online resource for all the things in Applied Cryptography which have been obsoleted, broken, or proved wrong. It would be invaluable when checking people's design work.

the Schneier crypto cannot be crappy.
it is the math in our universe corner that somehow lately shifted...

@Bernie:

Bruce Schneier has a work factor of O(-∞).

If you design a provably perfectly secure end-to-end cryptosystem, you've defined your endpoints incorrectly.

You should create a non-profit called The Cult of Schneier, and collect dues. You can think of something altruistic to do with the money.

Hey, it worked for L. Ron Hubbard. :-)

I loathe twitter, so I'll just comment here.

I first heard about AC shortly after the publication of the 2nd ed, when I became a subscriber of the coderpunks mailing list. His name wasn't revered as some holy of holies, but there were several people working on independent and open source cryptography libraries, and a few more working on offshore electronic banking systems.

Some 70% of the time if someone new had a question about a particular algorithm, one of the regulars would, bored, simply reply "Schneier, pp###"

I'm actually already a member of the cult of Don Knuth, sorry Bruce.

You mean you *aren't* looking at the photos of our weekly goat sacrifices on Flickr, extracting the steganographic prayers and answering via hacking into the Christian Science Monitor's astrology column?

Excuse me, I need to call my stock broker to cancel some trades.

@Bruce: speaking of cults, are you planning to join in on the voting system advisory council?

@ChristianB
"Obviously, no one should design cryptosystems based on a single book, neither AC or any other book -- educate yourself or let the professionals do the job."

Even more than that. Read the book to educate yourself so that you can tell the professionals from the snake-oil salesmen.

Bruce's greatest contribution (IMO) is not making more people crypto experts who write perfect systems ... it is educating more people on what is possible and what is snake-oil.

First things first, where do I order my "Bruce Schneier Cult Member" T-shirt???
Wow, I never realized that popularizing intelligent approaches was cult-like! Weird, and Cool! :) Now that I think of it, where're my Feyman, Sagan, Russell, Darwin Cult T-Shirts?

But more importantly, it's odd to see a critique of intelligent thinking that mentions developers "using someone else's guide" to crypto as a "cookbook"--isn't that exactly the opposite of what we've been taught here?: use this data carefully, think for yourself, observe, anticipate, test and observe again? Learn, use logic and observe the results, then iterate? Until safe, keep iterating? I make fun of language, but isn't that sort of 'rinse, repeat' logic the only way we currently know to make systems safe? I too would like the magic solution, but I haven't found one with computer systems yet.
I think Schneier's books have educated us so that we are able to sit back and think about an issue, realize how hard it is to make anything really secure, and figure out how to make the best logical choices in the arenas we find ourselves securing. "Trade offs" are important. I see that everyday, even with my new and probably insecure iphone.
Maybe Schneier's best gift to us in his writings is teaching us that even the best laid plans will be plundered, so you have to keep thinking and designing, and maybe one day we'll move beyond mousetrap psychology and into a way of living sensibly. In my own life, it's made me try to keep security sane: keep it simple, only defend what you know must be defended, keep that defense really simple, and hop like a random rabbit when you need to.
Ultimately what good security is about is changing people, and that is an arduous task.
I give Schneier a thumbs up on educating us, so please, where is my cult T-Shirt? :)
Tamara

John Viega's essay reminds me that I haven't read AC since before Hurricane Charlie which ripped floor-to-ceiling windows out of my office and destroyed a part of my library. Bruce will have to thank him for me having to order a copy tonight so that I can have another read.

Can I buy an autographed copy, Bruce?

No, I'm not a crypto expert, but I did stay at a Holiday Inn Express last night!

Re: the "early 2009" comment

I think he meant "early 2010. According to Amazon, it's due out on 23 March: http://www.amazon.co.uk/...

@Bruce: "If there's actually a cult out there, I want to hear about it."

You mean you haven't heard of it already? All those virgins sacrificed for nothing. Such a shame.

Imagine a world without Applied Cryptography.
Publicly available crypto applications would be a couple of years behind, there'd be way more snake oil around and it would still be difficult to find a good textbook for a first contact with the topic.

I'd rather have my pneumonia treated by a MD in the 50s than a shaman of today. There is progress in all fields, but that does not make fundamental works useless. Even MIX has it's uses :)

After the controversy between the MQV and HMQV protocols, some authors have presented a new protocol called FHMQV, and claims that bot MQV and HMQV are vulnerable to some impersonation and man in the middle attack if some informations leakages happen (see http://eprint.iacr.org/2009/408).
How secure is the FHMQV protocol? Why do the claimed attacks hold against (H)MQV and not FHMQV?

I wouldn't say a cult. More like a fanboy following :)

About Bruce's book, or any other book:
You do not become a musician by listening to concerts, you do not become a cryptographer/security expert by reading books.

Lets assume Jacques-Yves Cousteau wrote a book "Practical scuba diving".

Would that book be useful for scuba divers?
Most likely, given what we know about Jacques.

Would that book be useful for those who would like to start into scuba diving?
See previous answer.

Would the book be dated?
Most certainly, the man is dead.

Would anyone who has used the book to become an autodidact be eligible for a Darwin Award?
See previous answer.

What I miss in "Security is hard" is a good explanation about what is meant by "hard".

I think the proof of 'Fermat's Last Theorem' can be considered just as deceptive and "hard" as good security (is this even exaggerated?).

I think any amateur would-be cryptographer could be send away to come back when s/he can summarize the proof of Wiles.

Winter

Hi all,

I have Bruce's books and finding them useful particularly from the point of view of understanding the underlying theory, without which one cannot implement a practical system.

Sadly, in my 30 years of experience in development, I have seen a progression of down playing the importance of knowing the underlying theory and jumping straight to implementation.

Robert L. Glass finds this 'Write-First-and-Read-later' attitude is only found in computing. In other discipline, practitioners are forced to do years of 'reading', try literature and music, before letting loose on 'writing'. Not so in computing. Why? Particularly luminary like Frederick Brooks says writing program is the most complicated task human can undertake.

I have found many developers, condoned equally by their managers, who think they can write something to a file and reading it back can write something that rivals a commercial database. Dig around and you will see many home-cooked XML parsers whose author can give you all sorts of claims of benefits except for standard compliance, which escapes their comprehension.

This problem, as elaborated by many's contributions, seen to be prevalent and proud of in IT 'professional'. In other real professionals - like medical practitioners, accountants or architects - this kind of suck-and-see-practitioners will not be tolerated and practitioners are often deregistered or sent to jail. Many do not even read a book before implementing things! Every heard of Googlism?

Perhaps it is time for IT 'Professional' to mature and to give the consumers a better deal.

Imagine allowing a builder of your two soteys home to build a Sears Tower!

Jack

Viega's Schneier cult stuff sounds like sour grapes to me.

I'm sorry, I missed the blurb on the cover that said AC would bestow upon you the knowledge and divine insight from on high that would allow you to create a robust and secure system.

It's like saying a high-school math class prepares you for divining the workings of the universe via calculus.

I originally bought AC simply because I was interested in cryptography, not because I'm a programmer or security specialist.

The problem with "get a security expert to design it" is:
a) you may not have one handy
b) finding a consultant that actually *is* a security expert rather than merely claiming to be one isn't exactly a non-trivial task
c) security amateurs have to become security experts *somehow*, so you may be best off tasking one of your smarter employees with learning how to design crypto properly rather than spending your time trying to find a competent security consultant

Having been stuck in the situation of being told "build a crypto system to do X" despite being a rank amateur when it comes to crypto, the only advice I can offer is to:
1. Steal shamelessly from published protocols whenever you can. If a published one fits your requirements then *use* it (looking at the AES based scheme in IEEE 802.11i is a great place to start).
2. Try to find out if/how the protocols you're borrowing from have been broken and try not to replicate those mistakes (you'll probably make new ones instead, but your management haven't given you a lot of options here)
3. NIST have some excellent practical guides for crypto implementations. Download them and do your best to follow them (even if you aren't an American).
4. Keep an eye out for system defects that will render your crypto irrelevant (bad random sources, bad key management, bad IV management, bad plaintext management, etc)
5. Bug your management every chance you get to point out that the final design should *really* be checked out by a proper crypto expert (and preferably more than one)

At least that way you know that *you've* tried to do it right, even if you probably still forgot something and left a hole wide enough for Bruce to drive an oil tanker through :)

I can't be the only one (outside the US) who bought the book just because silly people in the US government were attempting to prevent its export.

As if one can prevent the "export" of mathematics.

I did read it.. Honest.

Regarding the "immaturity" of computer science as a discipline: that would be because it *is* immature. We only have decades of experience at this as a species, compared to the centuries (at least) we have behind us in other disciplines.

Experienced programmers are rightfully sceptical of new fads because they're exactly that - random junk foisted off on gullible management based on largely irrelevant anecdotal evidence.

Where it becomes a problem is when *bad* developers fail to recognise when something has made the transition from "latest fad" to "proven technology".

As far as not reading books goes... many IT books are lousy. By the time they get through the publisher's editing process and into bookstores they're already 6-12 months out of date. For some mature technologies or background reading on underlying theory that's not a problem, but for a lot of other things the internet is going to offer more accurate and up to date information.

Applied Cryptography brought cryptography to the average programmer. While one may correctly argue that a cryptosystem should be implemented by an "expert", this is often very difficult in practice. First, someone who can recognize the difference between an expert and a snake-oil salesman is likely already an expert themselves. Secondly, most firms are oblivious to the security implications of their designs, and if the programmer/architect doesn't make it a point to secure the design, it isn't secured at all.

Granted, we'd all prefer correctly designed systems, but AC makes the difference between no security and at least an honest attempt at security. At least some of them are bound to work correctly, and better - if the programmer understands AC, they'll better understand the kind of security they *need* to implement, rather than the kind often proposed by management or other naive colleagues (i.e. ROT13, etc...) As mentioned previously, the endpoints are often of crucial importance, and a flaw in, say, a key rotation schedule is often less of a security problem than the employee leaving work with the company database on their unencrypted laptop. Even the most secure of algorithms and protocols can be rendered moot by things as simple as greed and incompetence.

AC brought an awareness of the need, and the degree to which cryptography should be considered when implementing cryptosystems. I'm not sure that any publication can prevent people from making mistakes, but at least the mistakes they'll make after reading AC will be much less severe than the programmer who naively thinks that ROT13 (or some other homebrew algorithm) is secure enough for his firm's secret data.

@Tamara:
"First things first, where do I order my "Bruce Schneier Cult Member" T-shirt???"

You could try http://www.spreadshirt.com You'll need to design it yourself though.

Heh. I remember reviewing a system in which they had reimplemented RSA in Java from AC. They were very proud of their system, which used a 48 bit key. (After all, RSA is a really strong cryptosystem, why use tons of bits....)

Nick (the other) the thing is that security ≠ cryptography. Certainly you can become a security expert by reading books; even old timers (like me) read books on what aspects there were books available. They weren't all on crypto.

"If there's actually a cult out there, I want to hear about it."

There is a Cult, but it's not "The Cult of Schneier" but "The Cult of Squid ".

They came for the Squid but they stay for the TSA bashing.

@ P.E.,

"All the engineers I know are perfect. Just ask them."

I don't which engineers you know but from your description they are "software engineers" or charlatens (some would say little or no difference).

Most engineers working with "hard stuff" actually know that their designs are compramises and tend to be cautious about it.

I've said it many many times before on this blog "software engineering" is a poor attempt to sound like a proffesional. In practice the majority are "code cutters" or "software artisans" not enginers...

(Please send all flames to the unix furnace /dev/nul)

>Granted, we'd all prefer correctly designed systems, but AC makes the difference between no security and at least an honest attempt at security.

Bad. A " honest attempt" isnt enoug. Some black-hat just needs to write an Expolit for the Application and every dump Skript-kiddy can reduce the security of your Application down to "no security".

@ Bruce,

When are you and Ross going to produce a book together?

In many ways you have complimentry skills and knowledge.

So if I smash my thumb with a hammer, it's the fault of the guy who wrote the book about hammers?

@anon: "Bad. A " honest attempt" isnt enoug. Some black-hat just needs to write an Expolit for the Application and every dump Skript-kiddy can reduce the security of your Application down to "no security"."
________
Partially true. Poorly implemented cryptography may not give adequate protection against knowledgeable attackers or kids with tools, and it may give a false sense of security to the sender. But on the plus side it may keep out people who won't work for it but given the opportunity would misuse the system.

An analogy would be password protecting sensitive information in a word document whene emaling it. A knowledgeable person could easily crack it. But if you email it to the wrong person (or someone else forwards it) it will stop some people from looking at it (and using the info, spreading it, embarrassing you/and or the business, etc).

Sort of like locking your car doors...it won't stop a serious theif from getting into your car, but will deter some people who won't break in but would open an unlocked door and steal whatever they could otherwise.

@ anon,

'A " honest attempt" isnt enoug.'

The first problem is that people that actually know what they are doing from the silicon upwards are scarcer than hens teeth.

And there are just not enough of them to go around for even a select number of projects let alone all the Open Source projects.

In many ways the "cutting software" side of a system is not realy the issue, it runs much deeper than that.

The big weaknesses in systems these days are "side channels" leaking information and to name a couple of others, a lack of understanding about what is and is not random and why, and such things as not sending large numbers of files with known plaintext at fixed offsets from the start of files under the same key.

Understanding these issues and knowing how to deal with them should be a prerequisit before even the design specification gets written.

But even more fundemental to that is understanding such things as "clocking the inputs and outputs" of systems and exclusivity of operation on any given hardware platform.

As an over simple rule of thumb "efficiency and security" are at opposit ends of the "see-saw", and great care has to be taken when doing any kind of optomisation or resource sharing.

This effectivly starts at the IO protocol level and goes up through the IO hardware, the rest of the hardware and through the OS/BIOS. All before you get to what most code cutters would think is the "meat" of the system.

It is all to easy to open up a side channel or protocol hole that can be exploited in some way or another without making efficiency optomisations or alowing the sharing of resources.

For instance "clocking the inputs and outputs" will stop certain types of timing attacks, but incorectly dealing with an input timing fault may well open up another side channel through the system all be it at a lower bandwidth. Likewise using the hardware for other applications can alow alow covert timing side channels to be opened up on top of the communications application even though the other application has no communications channel of it's own.

It will be interesting to see what happens with technology (if and) when InfoSec/TEMPEST is made mandatory for systems storing of sensitive personal information. I get the feeling that COTS systems are not going to be running the current OS's.

@Clive
> (Please send all flames to the
> unix furnace /dev/nul)

Advice one might apply to oneself.

Although one may be shocked to find that /dev/nul may not be as available as one expected.

I got it right.

@Jack
"Robert L. Glass finds this 'Write-First-and-Read-later' attitude is only found in computing. In other discipline, practitioners are forced to do years of 'reading', try literature and music, before letting loose on 'writing'. "

Maybe that was true when Mr. Glass was younger, but not now. The intertubes are filled with unskilled amateur writers and songwriters who are more than happy to publish their work. And there's even a TV show whose auditions show there's a huge pool of unskilled singers (although their own ability to discern their inability is obviously compromised).

http://en.wikipedia.org/wiki/...

the T-shirt is at geekz shop

http://geekz.co.uk/shop/store/show/...

^ @blank reg: You barely beat me to it.

I agree that Applied Cryptography is not a good modern intro to engineering good crypto, but I wouldn't say it's a poor book. It's written, more or less, as an encyclopedia. It serves to be consulted, not to be designed after. No one faults you for not knowing a foreign culture in detail after you read the relevant Wikipedia articles on it. For what it aspired to do, I think A.P. did a good job. It's just that security engineers (not cryptographers, but the actual security engineers) needed more than what A.P. gave them, and they wound up filling in the gaps themselves.

Thus was born Practical Cryptography. It didn't replace A.P. -- it couldn't -- but it did fill in a lot of gaps. If A.P. was an encyclopedia, P.C. was a "How to" book.

Since then we've had more books that are even more practical on how to write good/secure/stable code.

For nostalgic purposes, A.C. was the first "real" crypto book I read. I've since spent a lot of time reading and learning about crypto, but A.C. was what actually got my feet wet. I will never forget it.

And a lot of the info in A.P. is still valid. The big complaint against it is that the info on specific algorithms, practical computing power, and known mathematical cryptanalysis is practically all out of date. Not wrong, just out of date -- anyone seeking to become a cryptographer today would need to go through quite a bit of material anyway just both historical context and to learn about old designs. Just because it's old doesn't mean that we can't learn from it.

I wouldn't tell someone to go design good crypto after just reading A.P., but if someone is aspiring to be a cryptographer and wanted to read a few books, I'd include A.P. on the list.

>"If there's actually a cult out there, I want to hear about it."

The real question here is not whether or not you have a cult, it's "Can Schneierism achieve tax-exempt status?"

NC

@ Neighborcat,

"Can Schneierism achieve tax-exempt status?"

They tell me that in California all things are possible ;)

And Deleware is a place where little is asked.

Untill recently I would have suggested the Turks and Cacos Islands but the UK gov has just put it's big boot back into colonialisum again there.

Which leaves the Dutch Antilies, but you have to hold your AGM there 8(

Alternatively you either need a deity or place of transendance etc to become a formal "god bothering" organisation.

Then of course you need a "god botherer in chief" who has the power to ordain into the faith and a ministry to teach the word etc.

But you need a "look" I think beard, pony tail, well cut black jacket black shirt black jeans/slacks (or whatever the call stylish casuals in your part of the world) and deck shoes / mochas to give the radical preacher look ;)

Oh and don't forget the ring (Bruce has designed on already so no probs there) and a symbol at the neck, how about an early cipher wheel on a black bootlace...

The question then is does Mr Schneier want to be "Bruce All Mighty" or just the "Head of the faith".

As an ordained teacher of the faith you are exempt etc taxation in most parts of the world and there are various schemes (or legitimate scams ;) that can be pulled in various ways.

So as Bruce has a book coming out if it's not to late a quick change to the title and a little re-ordering and conversion to "consultant speak" and it can become "The Word of Bruce" used as the primary text of faith.

Yup why bother with a cult that the IRS & FBI are only going to come sniffing around when you can be a legitimate full blown charitable TV Ministry, shaking the hands of the "great and the good" and "spreading the word" unto the faithfull.

@ Filias Cupio

Your post is enshrined in my archive of Internet humor at its best.

(N.B.: The fact that I bother to post this, using my usual ID, even though I know it really adds nothing to the thread and therefore detracts from my reputation, should be a tip-off to how much I really do appreciate it.)

@ Reverend Jim,

"Although one may be shocked to find that /dev/nul may not be as available as one expected."

Hmmm not quite as shocked to realise that for some reason "l ;" went missing, it should have been,

"(Please send all flames to the unix furnace /dev/null ;)"

As a little levity, ho hum, such is the joy (or lack there of,) of typing on a small mobile phone whilst traveling on the London Slumberground 8(

I have issue with the "anyone can design a crypto system they cannot break".

Perhaps I'm more stupid that most. But i can't. Even a cipher I still play with. I break it every time I try!

> "Can Schneierism achieve tax-exempt status?"

Personally, I think "Schneierist" rolls off the tongue pretty well. Perhaps Bruce's next book should be "The Gospel of the Flying Crypo Monster"

Scheneir is an anagram of Cthulu. So, cult, yeah.

"Scheneir is an anagram of Cthulu. So, cult, yeah."

Ia! Ia! Schneier fhtagn!

Re: Rule 1. You don't talk about the Cult of Schneier

So... The Cult of Schneier uses Security Through Obscurity?