Slashdot Mirror
Bruce Schneier Interview on Salon
citmanual wrote to us with the Schneier interview on Salon. He's promoting his new book Secrets and Lies. I'm just about finished with it, and will be doing a review soon - it's quite good.
← Back to Stories (view on slashdot.org)
That's one of the reasons Schneier rocks as hard as he does. He's a down-to-earth kind of renaissance man and he's pretty much always been like that in the years I've known him. Not only is he one of the best 10 or 50 cryptographers in the world (of which about 40 are probably NSA), but he's a regular guy. I had the good fortune to see Richard Thieme speak and he's similar in that regard (though he's more of a humanities guy than a science guy).
I read something recently describing a self-proclaimed epiphany he experienced a few years ago that set him in the direction of holistic security versus the crypto-heavy approach he favored since he entered the field. I'd be curious to know more about it because I felt he's always had a hint of that approach. Just go back and read his essays "Why Cryptography Is Harder Than It Looks" and "Security Pitfalls in Cryptography"... substitute "cryptography" for "computer security" or "network security" and you'll see what I mean.
In 1996 I think it was, Bruce, Niels Ferguson, and I were working on the problem of creating a file system offering plausible deniability of the existence of any files the user wanted to keep secret. We came up with some really neat ideas on how to avoid creating proof that certain files existed. I think it would have worked, but I made the realization that it wouldn't work successfully with technology of the day. Microsoft Word (heck, the Start -> Documents listing broke us too) will list the last several documents accessed: what if one of them was supposed to remain secret? If it's hidden, but the attacker sees you modified it and they can't find it, the game is over--you can't deny it exists and the system is broken.
Why is this such a big problem? Because if we were to create a special OS and set of applications that didn't track that stuff, the only people who would use it were those with something to hide (this wasn't a court of law--we couldn't assume you were innocent until proven guilty). So, the user loses the game before it even started simply by having that special OS and application set.
Keep on "keeping on", Bruce.
For example, it is possible to easily execute money transfers and stock trades as someone else at A Large Internet Broker Who Will Remain Unnamed. This sounds bad, and it is bad, but it isn't much worse than the equivalent security at non-Internet banks and brokerages. At my bank, I can execute a money transfer by simply sending a fax with my signature to the bank. Now, any waiter, billing clerk, or grocery checkout monkey to whom I have ever given a check has my account number, the name of my bank, the bank's routing number, and an original of my signature. Photo reproduction is more than good enough for a forged fax, so it would be trivial to walk down to the local copy shop and start faxing money transfers to people's banks.
Credit cards are even worse. You need only possess the physical card, or a reproduction thereof, to use the card fraudulently. The number of register operators who actually check the card signature against positive identification and then note the form and number of the identification is incredibly small. With near-full employment here in the U.S.A., the diligence of the rank register operator has become even worse in recent years. Fraud is trivially perpetrated in real-world banking and retail.
My final example involves my own clients. I am in a line of business that automates business processes in medium and large companies. Invariably, the client wants to ensure that the computer-automated process is totally secure. This is good and I applaud their concern. However, it is funny to note that the manual processes they are replacing haven't the least bit of security at all. Often, the "process" involves one person rubber-stamping a piece of paper and placing it in an open bin on some other person's desk. Yet they insist on impenetrable electronic security.
Or the coder throws in a 1024 byte buffer and says to himself "I'll go make this more robust once it is working". A couple days latter, he's got the system working, so he runs off, shows it to his boss, and moves on to the next project, forgetting about the work he has left to do on the program that "works".
Usually the tradeoff isn't program performance vs. security but coding time vs. security/performance/whataver.
The cake is a pie
Salon takes this quote out of context. Schneier goes on to say:
I haven't read the book yet, but my understanding from what Schneier says regularly on his very interesting mailing list is that he and others had been looking at security the wrong way. The analogy he uses frequently is to safes. Safes don't claim to be uncrackable; instead they come with ratings specifying how many minutes it would take a skilled safecracker to open them. Schneier's argument is that this is the same approach we should be taking to information security. Not "this security is crackable and that security isn't," but "this security can be cracked by a skilled intruder after X minutes/hours, giving you that much lead time to respond. Plan accordingly."
-
-
Give me liberty or give me something of equal or lesser value from your glossy 32-page catalog.
Hey Taco, This book is for you man!
Bruce simply has given up on the idea of perfect security. I don't think that he (or anyone) will be accepting some black box that promises magic. Why? Having to fight (in public) against all kinds of agencies wanting to restrict our personal freedoms is another matter. This will not change with or without Bruce's book.
In my opinion, many of the security problems that plague the internet (and computers in general) are caused by the fact that companies still put their priorities in the wrong place. Most programmers still choose performance over stability and security.
An example:
The article mentions buffer overflows, which, in my experience, have been virtually deleted in a language like Java. Sure, checking array bounds every single time may be a performance hit, but I will choose a performance hit over a security hit any day.
Basically, when you write software, don't make assumptions. Not on anything. I've seen plenty programs crash because they tried to access the network and found that it was not installed, or play a sound and find the device busy.
We may not be able to fix the people, but I think fixing the the software is possible. All it requires is ridding the world of software licences that deny responsibility. Once financial gain is at stake, corporations will put a lot more time into security, and hopefully a lot less in screwing eachother for financial gain.
Going from one extreme to the other.
Of course you can't have full safety, but that holds true as well for the real world. You can't prevent anyone from getting into a building, but you can make it so hard, that only a few will manage. And you have to pay in a way for that.
Simply because it's not possible to create perfect security does not mean that we should give up the ghost and go home. Quite the contrary, it is simply an indication that computers are indeed a part of the real world. Are real world banks 100% secure? Do the never get robbed? Obviously not, but we still have trust in them. Simply because "you cannot build a robbery proof bank" does not mean that we should give up banks (and their like) alltogether. And, while the Fort Knox gold repository isn't precisely invulnerable, it is sufficiently close to being so for the purposes necessary.
Computer security will necessarily ebb and flow as people recognize the issues and concerns and understand how to deal with them, etc., etc. Currently, there are many examples of poor and lax security because A) the favored model for computing has many security problems, B) unix is not a very secure operating system (face it guys, I love unix to death, but in many ways it is fundamentally broken when it comes to security [luckily, unix is so flexible that you can patch up the huge gigantic rents enough to make it pretty a box pretty damn secure]), C) everyone and their mother has some sort of semi-important server, which when combined with D) very few people actually understand even the basics of making a network / server / system secure can only cause problems.
In the semi near term, one of two things will most likely happen. Either 1) people will in general become more security concious, or 2) programs and systems will be made more inherently secure. I think 2 is much more likely, though a combination of 2 and a little bit of 1 would go a very long way.
This last line of the article is telling. A user of an Internet-connected computer is in possession of a powerful, potentially dangerous tool - maybe it's been long enough that people look at them as some kind of silly toy. On the one hand computing ought to be fun and people shouldn't have to do it in fear (implying they should be given software tools that, though they can never be completely secure, at least aren't braindamagedly insecure). On the other hand they should probably need some bare cognizance of what they're getting into and what they might, through ignorance and negligence, allow someone else to do in the world. Dancing pigs (or penguins) might be cute, but people need to consider that there can be real-world consequences of what they allow to be done to their networked computer.
We tell our kids not to take toys from strangers, but then we go and download and play with the software equivalent without a second thought...
The proof, as they say, is in the pudding. I can definitely associate his work with Ron Rivest, for instance. Rivest wrote RC6, an AES candidate which had 15 rounds broken. Schneier wrote Twofish, an AES candidate which has fared much better. RC6 isn't going to be selected as AES (I'll wager $20 on it), but Twofish is still in the running.
Insofar as "Bruce Schneier, by his work, is not a cryptographer (nor is he a cryptologist)"... I've got to recommend that you talk to your dealer about the purity of your rock. Strictly speaking, a cryptographer is one who develops and devises codes and ciphers. Schneier has written lots of ciphers, ranging from the lousy (MacGuffin) to the profoundly brilliant (Blowfish, and maybe Twofish).
He has also published cryptanalytic results against the major AES candidates, including (I believe) RIJNDAEL. I like RIJNDAEL. Joan Daemen (I'm misspelling the name here) is a brilliant cryptographer, responsible for a lot of extremely high-quality stuff--and if Schneier, et. al., can cryptanalize RIJNDAEL, that says something about Schneier's skill.
Insofar as Applied Cryptography being shady, I'm going to have to ask you for some verification. How is his description of Blowfish "shady"? After reading his description of Blowfish I was able to implement it, from scratch, without looking at any source code. My version passed the Blowfish compatability vectors, so apparently his description was clear and concise.
Finally there is a better crypto book out there anyways: it called the Handbook for Applied Cryptography by Vanstone et al.
Err... no. The Handbook of Applied Cryptography (notice the name), edited by Menezes, Vanstone, et. al., is a very good book. I refer to it often. However, I refer to Applied Cryptography more--why? Because I want to know the accepted way of how to do something, not a formal proof that the accepted way works. If you want to know how to encrypt the last block of a CBC mode cipher so that the cleartext is the same size as the ciphertext, Schneier tells you this in the space of a paragraph or two. The Handbook of Applied Cryptography goes into much more mathematical rigor.
This is not to say that the Handbook of Applied Cryptography is inferior: it's not. The two books are meant for different audiences who need different things, and claiming that one is superior to the other is pretty specious.
His papers are imprecise and obvious
... Are you telling me that you could have cryptanalyzed RIJNDAEL?
Seriously. Get a grip. Schneier is no demigod, that much is true; he's a human being just like anyone else, and occasionally screws it up past all recognition (just like anyone else). However, he is a hell of a lot better than I am.
My own beef with Schneier is something totally different. Schneier works as part of a team, not a solo operator. His best work has always been collaborative, with Doug Whiting, Niels Ferguson, etc. While I don't begrudge Schneier his fame--I think he's more than earned it--I do wish that people, particularly Slashdotters and the news media, would realize that Schneier may be the crypto version of Buckaroo Banzai, but--just like Buckaroo Banzai--he's nothing without his crew of Hong Kong Cavaliers and Blue Blazes Irregulars backing him up.
It seems to me that while there may not be a hope of totally securing anything, that doesn't mean that the act of breaking in will be worth it. Right now, I'm sure that the FBI's headquarters isn't totally secure, but the effort to break in isn't worth it to the average individual who would do it just for the novelty of it.
--------------------
`Lex - Find Me Here: Text Appeal
A long, long time ago I was utterly taken with formal methods. I lived and breathed Z and VDM.
Then one day I read a paper about the *limits* of formal methods. The one phrase summary of the article was that once a formally-verified program meets the real world, each time it's executed is a conjecture.
The paper seemed to be an argument against formal methods and as you might guess, all the heavy hitters with PhDs and post-doctoral work to defend generated a storm of complaint, the one phrase summary of which was that while formal methods might not be perfect, they shouldn't be abandoned.
I mention this because of the author's original notion of protecting ourselves by wrapping ourselves in mathematics, and his current appearance of despair.
It appears to me that the book's more a reaction to a crisis in faith than anything else. I don't think anyone really expects security to be uncrackable - we're got history going back to the pharaohs on that one, but neither should we throw the baby out with the bath water. I mean, I think I've seen at least one reaction that uses this article to predict the *imminent* *death* *of* *the* *internet*. As if!
668: Neighbour of the Beast