CRYPTO-GRAM, September 15, 2009

Bruce Schneier schneier at SCHNEIER.COM
Mon Sep 14 21:04:42 PDT 2009


                 CRYPTO-GRAM

              September 15, 2009

              by Bruce Schneier
      Chief Security Technology Officer, BT
             schneier at schneier.com
            http://www.schneier.com


A free monthly newsletter providing summaries, analyses, insights, and 
commentaries on security: computer and otherwise.

For back issues, or to subscribe, visit 
<http://www.schneier.com/crypto-gram.html>.

You can read this issue on the web at 
<http://www.schneier.com/crypto-gram-0909.html>.  These same essays 
appear in the "Schneier on Security" blog: 
<http://www.schneier.com/blog>.  An RSS feed is available.


** *** ***** ******* *********** *************

In this issue:
     Eighth Anniversary of 9/11
     Skein News
     Real-World Access Control
     News
     File Deletion
     On London's Surveillance Cameras
     Robert Sawyer's Alibis
     Schneier News
     Stealing 130 Million Credit Card Numbers
     "The Cult of Schneier"
     Comments from Readers


** *** ***** ******* *********** *************

     Eighth Anniversary of 9/11



On September 30, 2001, I published a special issue of Crypto-Gram 
discussing the terrorist attacks.  I wrote about the novelty of the 
attacks, airplane security, diagnosing intelligence failures, the 
potential of regulating cryptography -- because it could be used by the 
terrorists -- and protecting privacy and liberty.   Much of what I wrote 
is still relevant today.

http://www.schneier.com/crypto-gram-0109a.html

Me from 2006: "Refuse to be Terrorized."
http://www.schneier.com/essay-124.html


** *** ***** ******* *********** *************

     Skein News



Skein is one of the 14 SHA-3 candidates chosen by NIST to advance to the 
second round.  As part of the process, NIST allowed the algorithm 
designers to implement small "tweaks" to their algorithms.  We've 
tweaked the rotation constants of Skein.

The revised Skein paper contains the new rotation constants, as well as 
information about how we chose them and why we changed them, the results 
of some new cryptanalysis, plus new IVs and test vectors.

Tweaks were due today, September 15.  Now the SHA-3 process moves into 
the second round.  According to NIST's timeline, they'll choose a set of 
final round candidate algorithms in 2010, and then a single hash 
algorithm in 2012.  Between now and then, it's up to all of us to 
evaluate the algorithms and let NIST know what we want.  Cryptanalysis 
is important, of course, but so is performance.

The second-round algorithms are: BLAKE, Blue Midnight Wish, CubeHash, 
ECHO, Fugue, Grxstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, 
and Skein.  You can find details on all of them, as well as the current 
state of their cryptanalysis, at the SHA-3 Zoo.

In other news, we're making Skein shirts available to the public.  Those 
of you who attended the First Hash Function Candidate Conference in 
Leuven, Belgium, earlier this year might have noticed the stylish black 
Skein polo shirts worn by the Skein team.  Anyone who wants one is 
welcome to buy it, at cost.  All orders must be received before 1 
October, and then we'll have all the shirts made in one batch.

Skein website:
http://www.skein-hash.info/

Revised Skein paper:
http://www.schneier.com/skein.pdf

Revised Skein source code:
http://www.schneier.com/code/skein.zip

My 2008 essay on SHA-3:
http://www.schneier.com/essay-249.html

Details on Skein shirts:
http://www.schneier.com/skein-shirts.html

NIST SHA-3 Website:
http://csrc.nist.gov/groups/ST/hash/sha-3/index.html
http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/submissions_rnd2.html

SHA-3 Zoo:
http://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo


** *** ***** ******* *********** *************

     Real-World Access Control



Access control is difficult in an organizational setting. On one hand, 
every employee needs enough access to do his job. On the other hand, 
every time you give an employee more access, there's more risk: he could 
abuse that access, or lose information he has access to, or be socially 
engineered into giving that access to a malfeasant. So a smart, 
risk-conscious organization will give each employee the exact level of 
access he needs to do his job, and no more.

Over the years, there's been a lot of work put into role-based access 
control. But despite the large number of academic papers and 
high-profile security products, most organizations don't implement it -- 
at all -- with the predictable security problems as a result.

Regularly we read stories of employees abusing their database 
access-control privileges for personal reasons: medical records, tax 
records, passport records, police records. NSA eavesdroppers spy on 
their wives and girlfriends.  Departing employees take corporate secrets

A spectacular access control failure occurred in the UK in 2007. An 
employee of Her Majesty's Revenue & Customs had to send a couple of 
thousand sample records from a database on all children in the country 
to National Audit Office. But it was easier for him to copy the entire 
database of 25 million people onto a couple of disks and put it in the 
mail than it was to select out just the records needed. Unfortunately, 
the discs got lost in the mail and the story was a huge embarrassment 
for the government.

Eric Johnson at Dartmouth's Tuck School of Business has been studying 
the problem, and his results won't startle anyone who has thought about 
it at all. RBAC is very hard to implement correctly. Organizations 
generally don't even know who has what role. The employee doesn't know, 
the boss doesn't know -- and these days the employee might have more 
than one boss -- and senior management certainly doesn't know. There's a 
reason RBAC came out of the military; in that world, command structures 
are simple and well-defined.

Even worse, employees' roles change all the time -- Johnson chronicled 
one business group of 3,000 people that made 1,000 role changes in just 
three months -- and it's often not obvious what information an employee 
needs until he actually needs it. And information simply isn't that 
granular. Just as it's much easier to give someone access to an entire 
file cabinet than to only the particular files he needs, it's much 
easier to give someone access to an entire database than only the 
particular records he needs.

This means that organizations either over-entitle or under-entitle 
employees. But since getting the job done is more important than 
anything else, organizations tend to over-entitle. Johnson estimates 
that 50 percent to 90 percent of employees are over-entitled in large 
organizations. In the uncommon instance where an employee needs access 
to something he normally doesn't have, there's generally some process 
for him to get it. And access is almost never revoked once it's been 
granted. In large formal organizations, Johnson was able to predict how 
long an employee had worked there based on how much access he had.

Clearly, organizations can do better. Johnson's current work involves 
building access-control systems with easy self-escalation, audit to make 
sure that power isn't abused, violation penalties (Intel, for example, 
issues "speeding tickets" to violators), and compliance rewards. His 
goal is to implement incentives and controls that manage access without 
making people too risk-averse.

In the end, a perfect access control system just isn't possible; 
organizations are simply too chaotic for it to work. And any good system 
will allow a certain number of access control violations, if they're 
made in good faith by people just trying to do their jobs. The "speeding 
ticket" analogy is better than it looks: we post limits of 55 miles per 
hour, but generally don't start ticketing people unless they're going 
over 70.

This essay previously appeared in Information Security, as part of a 
point/counterpoint with Marcus Ranum.  You can read Marcus's response 
here -- after you answer some nosy questions to get a free account.
http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1365957_mem1,00.html 
or http://tinyurl.com/m7qhf4

Role-based access control:
http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1257133_mem1,00.html 
or http://tinyurl.com/n5mjmx
http://technet.microsoft.com/en-us/library/cc780256(WS.10).aspx
http://csrc.nist.gov/groups/SNS/rbac/documents/design_implementation/Intro_role_based_access.htm 
or http://tinyurl.com/ku8vnd
http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-92.pdf

Abuse of database access:
http://articles.latimes.com/2009/may/09/local/me-hospital9
http://www.marketwatch.com/story/irs-worker-snooped-on-tax-records-of-almost-200-celebrities 
or http://tinyurl.com/mrh7a8
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9115297 
or http://tinyurl.com/mwr9je
http://rawstory.com/08/news/2009/06/18/reporter-nsa-analysts-spied-on-own-wives-and-girlfriends/ 
or http://tinyurl.com/mbgmw3
http://www.thetechherald.com/article.php/200924/3849/Trust-still-an-issue-in-IT-as-insiders-abuse-access-rights 
or http://tinyurl.com/mk3lyf
http://searchsecurity.techtarget.co.uk/news/article/0,289142,sid180_gci1318850,00.html 
or http://tinyurl.com/mu5ovb

UK access control failure:
http://www.hmrc.gov.uk/news/hartnett-poynter-icc.htm
http://news.bbc.co.uk/2/hi/uk_news/politics/7103566.stm
http://www.computerweekly.com/Articles/2008/06/27/231267/hmrc-left-the-door-open-to-data-loss.htm 
or http://tinyurl.com/mdqvm9

Johnson's work:
http://mba.tuck.dartmouth.edu/digital/Research/ResearchProjects/DataFinancial.pdf 
or http://tinyurl.com/ln4vhr
http://weis2008.econinfosec.org/papers/Zhao.pdf
http://mba.tuck.dartmouth.edu/digital/Research/ResearchProjects/wise_v1.pdf 
or http://tinyurl.com/mtgsq2


** *** ***** ******* *********** *************

     News



Flash has the equivalent of cookies, and they're hard to delete.
http://www.wired.com/epicenter/2009/08/you-deleted-your-cookies-think-again/ 
or http://tinyurl.com/l2gqaz

Movie-plot threat alert: robot suicide bombers.  Let's all be afraid.
http://www.telegraph.co.uk/news/newstopics/politics/lawandorder/6028144/Robot-suicide-bombers-fear.html 
or http://tinyurl.com/orxxuz
I'm sure I've seen this stuff in movies.

It's possible to fabricate DNA evidence:
http://arstechnica.com/science/news/2009/08/dna-samples-used-by-crime-labs-faked-in-research-lab.ars 
or http://tinyurl.com/pxwosm
http://www.nytimes.com/2009/08/18/science/18dna.html
http://www.fsigenetics.com/article/S1872-4973(09)00099-4/abstract

The legal term "terroristic threats" is older than 9/11, but these days 
it evokes too much of an emotional response:
http://www.schneier.com/blog/archives/2009/08/the_continuing_2.html

Interesting developments in lie detection:
http://www.scientificamerican.com/article.cfm?id=the-load-of-lying&sc=WR_20090804 
or http://tinyurl.com/njnn3o

Marc Webar Tobias on hacking the Assa Solo lock:
http://www.thesidebar.org/insecurity/?p=447
Me on locks and lockpicking:
http://www.schneier.com/blog/archives/2009/08/lockpicking_and.html

>From the humor website Cracked: "The 5 Most Embarrassing Failures in 
the History of Terrorism."  Yes, it's funny.  But remember that these 
are the terrorist masterminds that politicians invoke to keep us scared.
http://www.cracked.com/article/79_the-5-most-embarrassing-failures-in-history-terrorism/ 
or http://tinyurl.com/lt68pa
My 2007 essay, "Portrait of the Modern Terrorist as an Idiot," is also 
relevant.  But less funny.
http://www.schneier.com/essay-174.html

Modeling zombie outbreaks: the math doesn't look good.  "When Zombies 
Attack!: Mathematical Modelling of an Outbreak of Zombie Infection."
http://www.mathstat.uottawa.ca/~rsmith/Zombies.pdf

It turns out that flipping a coin has all sorts of non-randomness:
http://www.codingthewheel.com/archives/the-coin-flip-a-fundamentally-unfair-proposition 
or http://tinyurl.com/d9kgt7
http://www-stat.stanford.edu/~susan/papers/headswithJ.pdf

As part of their training, federal agents engage in mock exercises in 
public places.  Sometimes, innocent civilians get involved.  It's actual 
security theater.
http://www.washingtonpost.com/wp-dyn/content/article/2009/08/16/AR2009081602250.html?hpid=artslot&sid=ST2009081602301 
or http://tinyurl.com/qd6zzz
http://www.startribune.com/59017377.html?elr=KArksUUUoDEy3LGDiO7aiU

The sorts of crimes we've been seeing perpetrated against individuals 
are starting to be perpetrated against small businesses.  The problem 
will get much worse, and the security externalities means that the banks 
care much less.
http://www.schneier.com/blog/archives/2009/08/small_business.html

Interesting video demonstrating how a policeman can manipulate the 
results of a Breathalyzer.
http://www.bing.com/videos/search?q=Breath+tests&qs=n&docid=992451363282&mid=AC91324DD782741BE4F2AC91324DD782741BE4F2&FORM=VIVR30# 
or http://tinyurl.com/kkq8dk

There is a movement in the U.K. to replace the pint glasses in pubs with 
plastic because too many of them are being used as weapons.  I don't 
think this will go anywhere, but the sheer idiocy is impressive. 
Reminds me of the call to ban pointy knives.  That recommendation also 
came out of the UK.  What's going on over there?
http://www.schneier.com/blog/archives/2009/08/banning_beer_gl.html

More security stories from the natural world: marine worms with glowing 
bombs:
http://www.schneier.com/blog/archives/2009/08/marine_worms_wi.html

Weird:  "The U.S. Federal Bureau of Investigation is trying to figure 
out who is sending laptop computers to state governors across the U.S., 
including West Virginia Governor Joe Mahchin and Wyoming Governor Dave 
Freudenthal. Some state officials are worried that they may contain 
malicious software."
http://www.itworld.com/government/75885/fbi-investigating-laptops-sent-us-governors 
or http://tinyurl.com/llf53a

Fascinating story of a 16-year-old blind phone phreaker.
http://www.rollingstone.com/news/story/29787673/the_boy_who_heard_too_much/print 
or http://tinyurl.com/nxnb9h

Hacking swine flu:  "So it takes about 25 kilobits -- 3.2 Kbytes -- of 
data to code for a virus that has a non-trivial chance of killing a 
human. This is more efficient than a computer virus, such as MyDoom, 
which rings in at around 22 Kbytes.  It's humbling that I could be 
killed by 3.2 Kbytes of genetic data. Then again, with 850 Mbytes of 
data in my genome, there's bound to be an exploit or two."
http://www.bunniestudios.com/blog/?p=353

Good article on the exaggerated fears of cyberwar:
http://bostonreview.net/BR34.4/morozov.php
The real risk isn't cyberterrorism, it's cybercrime.

SIGABA and the history of one-time pads:
http://www1.cs.columbia.edu/~smb/blog/control/
I wrote about one-time pads, and their practical insecurity, in 2002:
http://www.schneier.com/crypto-gram-0210.html#7

Interesting discussion of subpoenas as a security threat:
http://www.freedom-to-tinker.com/blog/felten/subpoenas-and-search-warrants-security-threats 
or http://tinyurl.com/lwtdaz

A very interesting hour-long interview with David Kilcullen on security 
and insurgency.
http://www.abc.net.au/unleashed/stories/s2668177.htm

Nils Gilman's lecture on the global illicit economy  Malware is one of 
Nils Gilman's examples, at about the nine-minute mark.
http://video.google.com/videoplay?docid=3173247273890946684#
The seven rules of the illicit global economy (he seems to use "illicit" 
and "deviant" interchangeably in the talk):
1.  Perfectly legitimate forms of demand can produce perfectly deviant 
forms of supply.
2.  Uneven global regulatory structures create arbitrage opportunities 
for deviant entrepreneurs.
3.  Pathways for legitimate globalization are always also pathways for 
deviant globalization.
4.  Once a deviant industry professionalizes, crackdowns merely promote 
innovation.
5.  States themselves undermine the distinction between legitimate and 
deviant economics.
6.  Unchecked, deviant entrepreneurs will overtake the legitimate economy.
7.  Deviant globalization presents an existential challenge to state 
legitimacy.

Perfectly legal (obtained with a FISA warrant) NSA intercepts used to 
convict liquid bombers.
http://www.schneier.com/blog/archives/2009/09/nsa_intercepts.html
The BBC has a video demonstration of a 16-ounce bottle of liquid blowing 
a hole in the side of a plane.  I know no more details than what's in 
the video.
http://news.bbc.co.uk/2/hi/uk_news/7536167.stm


** *** ***** ******* *********** *************

     File Deletion



File deletion is all about control. This used to not be an issue. Your 
data was on your computer, and you decided when and how to delete a 
file. You could use the delete function if you didn't care about whether 
the file could be recovered or not, and a file erase program -- I use 
BCWipe for Windows -- if you wanted to ensure no one could ever recover 
the file.

As we move more of our data onto cloud computing platforms such as Gmail 
and Facebook, and closed proprietary platforms such as the Kindle and 
the iPhone, deleting data is much harder.

You have to trust that these companies will delete your data when you 
ask them to, but they're generally not interested in doing so. Sites 
like these are more likely to make your data inaccessible than they are 
to physically delete it. Facebook is a known culprit: actually deleting 
your data from its servers requires a complicated procedure that may or 
may not work. And even if you do manage to delete your data, copies are 
certain to remain in the companies' backup systems. Gmail explicitly 
says this in its privacy notice.

Online backups, SMS messages, photos on photo sharing sites, smartphone 
applications that store your data in the network: you have no idea what 
really happens when you delete pieces of data or your entire account, 
because you're not in control of the computers that are storing the data.

This notion of control also explains how Amazon was able to delete a 
book that people had previously purchased on their Kindle e-book 
readers. The legalities are debatable, but Amazon had the technical 
ability to delete the file because it controls all Kindles. It has 
designed the Kindle so that it determines when to update the software, 
whether people are allowed to buy Kindle books, and when to turn off 
people's Kindles entirely.

Vanish is a research project by Roxana Geambasu and colleagues at the 
University of Washington. They designed a prototype system that 
automatically deletes data after a set time interval. So you can send an 
e-mail, create a Google Doc, post an update to Facebook, or upload a 
photo to Flickr, all designed to disappear after a set period of time. 
And after it disappears, no one -- not anyone who downloaded the data, 
not the site that hosted the data, not anyone who intercepted the data 
in transit, not even you -- will be able to read it. If the police 
arrive at Facebook or Google or Flickr with a warrant, they won't be 
able to read it.

The details are complicated, but Vanish breaks the data's decryption key 
into a bunch of pieces and scatters them around the web using a 
peer-to-peer network. Then it uses the natural turnover in these 
networks -- machines constantly join and leave -- to make the data 
disappear. Unlike previous programs that supported file deletion, this 
one doesn't require you to trust any company, organization, or website. 
It just happens.

Of course, Vanish doesn't prevent the recipient of an e-mail or the 
reader of a Facebook page from copying the data and pasting it into 
another file, just as Kindle's deletion feature doesn't prevent people 
from copying a book's files and saving them on their computers. Vanish 
is just a prototype at this point, and it only works if all the people 
who read your Facebook entries or view your Flickr pictures have it 
installed on their computers as well; but it's a good demonstration of 
how control affects file deletion. And while it's a step in the right 
direction, it's also new and therefore deserves further security 
analysis before being adopted on a wide scale.

We've lost the control of data on some of the computers we own, and 
we've lost control of our data in the cloud. We're not going to stop 
using Facebook and Twitter just because they're not going to delete our 
data when we ask them to, and we're not going to stop using Kindles and 
iPhones because they may delete our data when we don't want them to. But 
we need to take back control of data in the cloud, and projects like 
Vanish show us how we can.

Now we need something that will protect our data when a large 
corporation decides to delete it.

This essay originally appeared in The Guardian.
http://www.guardian.co.uk/technology/2009/sep/09/bruce-schneier-file-deletion 
or http://tinyurl.com/m9k2cm

BCWipe:
http://www.jetico.com/data-protection-wiping-bcwipe-enterprise/

Me on cloud computing:
http://www.schneier.com/essay-274.html

Control and the iPhone:
http://www.schneier.com/essay-204.html

Social networking companies don't want to delete data:
http://www.schneier.com/essay-278.html

How to delete your Facebook account:
http://www.wikihow.com/Permanently-Delete-a-Facebook-Account

Kindle:
http://bit.ly/KindleDelete
http://www.techdirt.com/articles/20090416/0246064526.shtml

Vanish:
http://www.economist.com/sciencetechnology/tm/displaystory.cfm?story_id=14162535 
or http://tinyurl.com/nxtkfg
http://vanish.cs.washington.edu/index.html
http://vanish.cs.washington.edu/pubs/usenixsec09-geambasu.pdf


** *** ***** ******* *********** *************

     On London's Surveillance Cameras



A recent report has concluded that the London's surveillance cameras 
have solved one crime per thousand cameras per year.

I haven't seen the report, but I know it's hard to figure out when a 
crime has been "solved" by a surveillance camera.  To me, the crime has 
to have been unsolvable without the cameras.  Repeatedly I see 
pro-camera lobbyists pointing to the surveillance-camera images that 
identified the 7/7 London Transport bombers, but it is obvious that they 
would have been identified even without the cameras.

And it would really help my understanding of the report's per-crime 
cost-to-detect of #20,000 (I assume it is calculated from #200 million 
for the cameras times 1 in 1000 cameras used to solve a crime per year 
divided by ten years) if I knew what sorts of crimes the cameras 
"solved."  If the #200 million solved 10,000 murders, it might very well 
be a good security trade-off.  But my guess is that most of the crimes 
were of a much lower level.

http://news.bbc.co.uk/2/hi/uk_news/england/london/8219022.stm
http://www.telegraph.co.uk/news/uknews/crime/6082530/1000-CCTV-cameras-to-solve-just-one-crime-Met-Police-admits.html 
or http://tinyurl.com/nblfwd


** *** ***** ******* *********** *************

     Robert Sawyer's Alibis



Back in 2002, science fiction author Robert J. Sawyer wrote an essay 
about the trade-off between privacy and security.  I've never forgotten 
the first sentence:  "Whenever I visit a tourist attraction that has a 
guest register, I always sign it. After all, you never know when you'll 
need an alibi."

Since I read that, whenever I see a tourist attraction with a guest 
register, I do the same thing. I sign "Robert J. Sawyer, Toronto, ON" -- 
because you never know when he'll need an alibi.


Sawyer's essay:
http://sfwriter.com/privacy.htm

Essays I've written about privacy:
http://www.schneier.com/essay-109.html
http://www.schneier.com/blog/archives/2006/05/the_value_of_pr.html
http://www.schneier.com/essay-261.html


** *** ***** ******* *********** *************

     Schneier News



I'm speaking at the University of Kentucky on September 17.
http://www.cs.engr.uky.edu/events/distingLectures.php

I'm also speaking at the II International Symposium on Network and Data 
Communications, in Lima, Peru on September 25.
http://www.tecsup.edu.pe/simposio09/redes/preventaingles.html

And I'm speaking at GOVCERT.NL in Rotterdam on October 6.
https://www.govcert.nl/symposium/index.html

Here's a video of a talk, "The Future of the Security Industry," I gave 
at an OWASP meeting in August in Minneapolis.
http://vimeo.com/6495257


** *** ***** ******* *********** *************

     Stealing 130 Million Credit Card Numbers



Someone has been charged with stealing 130 million credit card numbers.

Yes, it's a lot, but that's the sort of quantities credit card numbers 
come in.  They come by the millions, in large database files.  Even if 
you only want ten, you have to steal millions.  I'm sure every one of us 
has a credit card in our wallet whose number has been stolen.  It'll 
probably never be used for fraudulent purposes, but it's in some stolen 
database somewhere.

Years ago, when giving advice on how to avoid identity theft, I would 
tell people to shred their trash.  Today, that advice is completely 
obsolete.  No one steals credit card numbers one by one out of the trash 
when they can be stolen by the millions from merchant databases.

http://news.yahoo.com/s/ap/20090817/ap_on_re_us/us_hacker_charges


** *** ***** ******* *********** *************

     "The Cult of Schneier"



If there's actually a cult out there, I want to hear about it.  In an 
essay by that name, John Viega writes about the dangers of relying on 
Applied Cryptography to design cryptosystems:

    But, after many years of evaluating the security of software
    systems, I'm incredibly down on using the book that made Bruce
    famous when designing the cryptographic aspects of a system. In
    fact, I can safely say I have never seen a secure system come out
    the other end, when that is the primary source for the crypto
    design. And I don't mean that people forget about the buffer
    overflows. I mean, the crypto is crappy.

    My rule for software development teams is simple: Don't use
    Applied Cryptography in your system design. It's fine and
    fun to read it, just don't build from it.

    [...]

    The book talks about the fundamental building blocks of
    cryptography, but there is no guidance on things like, putting
    together all the pieces to create a secure, authenticated
    connection between two parties.

    Plus, in the nearly 13 years since the book was last revised, our
    understanding of cryptography has changed greatly. There are
    things in it that were thought to be true at the time that turned
    out to be very false....

I agree.  And, to his credit, Viega points out that I agree:

    But in the introduction to Bruce Schneier's book, Practical
    Cryptography, he himself says that the world is filled with
    broken systems built from his earlier book. In fact, he wrote
    Practical Cryptography in hopes of rectifying the problem.

This is all true.

Designing a cryptosystem is hard.  Just as you wouldn't give a person -- 
even a doctor -- a brain-surgery instruction manual and then expect him 
to operate on live patients, you shouldn't give an engineer a 
cryptography book and then expect him to design and implement a 
cryptosystem.  The patient is unlikely to survive, and the cryptosystem 
is unlikely to be secure.

Even worse, security doesn't provide immediate feedback.  A dead patient 
on the operating table tells the doctor that maybe he doesn't understand 
brain surgery just because he read a book, but an insecure cryptosystem 
works just fine.  It's not until someone takes the time to break it that 
the engineer might realize that he didn't do as good a job as he 
thought.  Remember: Anyone can design a security system that he himself 
cannot break.  Even the experts regularly get it wrong.  The odds that 
an amateur will get it right are extremely low.

For those who are interested, a second edition of Practical Cryptography 
will be published in early 2010, renamed Cryptography Engineering and 
featuring a third author: Tadayoshi Kohno.

http://broadcast.oreilly.com/2009/01/the-cult-of-schneier.html

Applied Cryptography:
http://www.schneier.com/book-applied.html

Practical Cryptography:
http://www.schneier.com/book-practical.html


** *** ***** ******* *********** *************

     Comments from Readers



There are thousands of comments -- many of them interesting -- on these 
topics on my blog. Search for the story you want to comment on, and join in.

http://www.schneier.com/blog


** *** ***** ******* *********** *************

Since 1998, CRYPTO-GRAM has been a free monthly newsletter providing 
summaries, analyses, insights, and commentaries on security: computer 
and otherwise.  You can subscribe, unsubscribe, or change your address 
on the Web at <http://www.schneier.com/crypto-gram.html>.  Back issues 
are also available at that URL.

Please feel free to forward CRYPTO-GRAM, in whole or in part, to 
colleagues and friends who will find it valuable.  Permission is also 
granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.

CRYPTO-GRAM is written by Bruce Schneier.  Schneier is the author of the 
best sellers "Schneier on Security," "Beyond Fear," "Secrets and Lies," 
and "Applied Cryptography," and an inventor of the Blowfish, Twofish, 
Threefish, Helix, Phelix, and Skein algorithms.  He is the Chief 
Security Technology Officer of BT BCSG, and is on the Board of Directors 
of the Electronic Privacy Information Center (EPIC).  He is a frequent 
writer and lecturer on security topics.  See <http://www.schneier.com>.

Crypto-Gram is a personal newsletter.  Opinions expressed are not 
necessarily those of BT.

Copyright (c) 2009 by Bruce Schneier.

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE





More information about the cypherpunks-legacy mailing list