September 15, 2010
by Bruce Schneier
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-1009.html>. These same essays and news items appear in the "Schneier on Security" blog at <http://www.schneier.com/blog>, along with a lively comment section. An RSS feed is available.
In this issue:
If you're a typical wired American, you've got a bunch of tech tools you like and a bunch more you covet. You have a cell phone that can easily text. You've got a laptop configured just the way you want it. Maybe you have a Kindle for reading, or an iPad. And when the next new thing comes along, some of you will line up on the first day it's available.
So why can't work keep up? Why are you forced to use an unfamiliar, and sometimes outdated, operating system? Why do you need a second laptop, maybe an older and clunkier one? Why do you need a second cell phone with a new interface, or a BlackBerry, when your phone already does e-mail? Or a second BlackBerry tied to corporate e-mail? Why can't you use the cool stuff you already have?
More and more companies are letting you. They're giving you an allowance and allowing you to buy whatever laptop you want, and to connect into the corporate network with whatever device you choose. They're allowing you to use whatever cell phone you have, whatever portable e-mail device you have, whatever you personally need to get your job done. And the security office is freaking.
You can't blame them, really. Security is hard enough when you have control of the hardware, operating system and software. Lose control of any of those things, and the difficulty goes through the roof. How do you ensure that the employee devices are secure, and have up-to-date security patches? How do you control what goes on them? How do you deal with the tech support issues when they fail? How do you even begin to manage this logistical nightmare? Better to dig your heels in and say "no."
But security is on the losing end of this argument, and the sooner it realizes that, the better.
The meta-trend here is consumerization: cool technologies show up for the consumer market before they're available to the business market. Every corporation is under pressure from its employees to allow them to use these new technologies at work, and that pressure is only getting stronger. Younger employees simply aren't going to stand for using last year's stuff, and they're not going to carry around a second laptop. They're either going to figure out ways around the corporate security rules, or they're going to take another job with a more trendy company. Either way, senior management is going to tell security to get out of the way. It might even be the CEO, who wants to get to the company's databases from his brand new iPad, driving the change. Either way, it's going to be harder and harder to say no.
At the same time, cloud computing makes this easier. More and more, employee computing devices are nothing more than dumb terminals with a browser interface. When corporate e-mail is all webmail, corporate documents are all on GoogleDocs, and when all the specialized applications have a web interface, it's easier to allow employees to use any up-to-date browser. It's what companies are already doing with their partners, suppliers, and customers.
Also on the plus side, technology companies have woken up to this trend and -- from Microsoft and Cisco on down to the startups -- are trying to offer security solutions. Like everything else, it's a mixed bag: some of them will work and some of them won't, most of them will need careful configuration to work well, and few of them will get it right. The result is that we'll muddle through, as usual.
Security is always a tradeoff, and security decisions are often made for non-security reasons. In this case, the right decision is to sacrifice security for convenience and flexibility. Corporations want their employees to be able to work from anywhere, and they're going to have loosened control over the tools they allow in order to get it.
This essay first appeared as the second half of a point/counterpoint with Marcus Ranum in Information Security Magazine. You can read Marcus's half there.
Breaking into a garage in seconds. Garage doors with automatic openers have always seemed like a lot of security theater to me: people regularly treat their garage door as if it had the same security as their front door.
Hacking cars through wireless tire-pressure sensors. It's minor, but this kind of thing is only going to get worse.
Good essay by Seth Godin on the "Fear Tax":
Intel buying McAfee is another example of a large non-security company buying a security company. I've been talking about this sort of thing for two and a half years.
Malware might have been a contributory cause of an air crash. I say "might" because it's hard to get reliable information.
danah boyd on social steganography:
Full-body scanners in roving vans:
Since a fatal crash a few years ago, Boston T (their subway) operators have been forbidden from using -- or even having -- cell phones while on the job. Passengers are encouraged to report violators. But sometimes T operators need to use their official radios on the job, and passengers can't tell the difference. The solution: mark their official radios with orange tape. Of course, no T operator would ever think of putting bright orange tape on his cell phone. Because if he did that, the passengers would immediately know not to report him.
In Australia, a high school teacher assigned a movie-plot threat contest problem to his students, and everyone went crazy. He sounds like me, really.
Interesting research: eavesdropping on smart homes with distributed wireless sensors.
Great article on terrorism entrapment:
In Japan, paint-filled orange balls are an anti-robbery device.
Problems with Twitter's OAuth authentication system.
The Onion on national security: "Smart, Qualified People Behind the Scenes Keeping America Safe: 'We Don't Exist.'"
Vulnerabilities in US-CERT network:
Popular usernames and passwords, in graphical form.
Back in May, I attended the EastWest Institute's First Worldwide Cybersecurity Summit in Dallas. I only had eight minutes to speak, and tried to turn the dialog to security, privacy, and the individual.
On September 16, I'll be a keynote speaker at IDC's IT Security Conference 2010 in London.
On October 1, I'll be a keynote speaker at CELAES 2010: XXV FELABAN Conference on Bank Security in Miami.
On October 8, I'll be giving a luncheon keynote speech at the Minnesota Library Association Conference in Rochester, MN.
On October 12, I'll be a keynote speaker at RSA Europe in London.
Skein is my new hash function. Well, "my" is an overstatement; I'm one of the eight designers. It was submitted to NIST for their SHA-3 competition, and one of the 14 algorithms selected to advance to the second round.
Last week was the Second SHA-3 Candidate Conference. Lots of people presented papers on the candidates: cryptanalysis papers, implementation papers, performance comparisons, etc. There were two cryptanalysis papers on Skein. The first was by Kerry McKay and Poorvi L. Vora. They tried to extend linear cryptanalysis to groups of bits to attack Threefish (the block cipher inside Skein). It was a nice analysis, but it didn't get very far at all.
The second was a fantastic piece of cryptanalysis by Dmitry Khovratovich, Ivica Nikolie, and Christian Rechberger. They used a rotational rebound attack to mount a "known-key distinguisher attack" on 57 out of 72 Threefish rounds faster than brute force. It's a new type of attack -- some go so far as to call it an "observation" -- and the community is still trying to figure out what it means. It only works if the attacker can manipulate both the plaintexts and the keys in a structured way. Against 57-round Threefish, it requires 2**503 work -- barely better than brute force. And it only distinguishes reduced-round Threefish from a random permutation; it doesn't actually recover any key bits.
Even with the attack, Threefish has a good security margin. Also, the attack doesn't affect Skein. But changing one constant in the algorithm's key schedule makes the attack impossible. NIST has said they're allowing second-round tweaks, so we're going to make the change. It won't affect any performance numbers or obviate any other cryptanalytic results -- but the best attack would be 33 out of 72 rounds.
The second-round algorithms are: BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grostl, 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-2 Zoo site. NIST will select approximately five algorithms to go on to the third round by the end of the year.
In other news, we're once again making Skein polo shirts available to the public. Those of you who attended either of the two SHA-3 conferences 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 October 1, and we'll have all the shirts made in one batch.
The Second SHA-3 Candidate Conference:
Skein source code:
As part of NIST's SHA-3 selection process, people have been implementing the candidate hash functions on a variety of hardware and software platforms. Our team has implemented Skein in Intel's 32 nm ASIC process, and got some impressive performance results. Several other groups have implemented Skein in FPGA and ASIC, and have seen significantly poorer performance. We need help understanding why.
For example, a group led by Brian Baldwin at the Claude Shannon Institute for Discrete Mathematics, Coding and Cryptography implemented all the second-round candidates in FPGA. Skein performance was terrible, but when they checked their code, they found an error. Their corrected performance comparison has Skein performing much better and in the top ten.
We suspect that the adders in all the designs may not be properly optimized, although there may be other performance issues. If we can at least identify (or possibly even fix) the slowdowns in the design, it would be very helpful, both for our understanding and for Skein's hardware profile. Even if we find that the designs are properly optimized, that would also be good to know.
A group at George Mason University led by Kris Gaj implemented all the second-round candidates in FPGA. Skein had the worst performance of any of the implementations. We're looking for someone who can help us understand the design, and determine if it can be improved.
Another group, led by Stefan Tillich at University of Bristol, implemented all the candidates in 180 nm custom ASIC. Here, Skein is one of the worst performers. We're looking for someone who can help us understand what this group did.
Three other groups -- one led by Patrick Schaumont of Virginia Tech, another led by Shin'ichiro Matsuo at National Institute of Information and Communications Technology in Japan, and a third led by Luca Henzen at ETH Zurich -- implemented the SHA-3 candidates. Again, we need help understanding how their Skein performance numbers are so different from ours.
We're looking for people with FPGA and ASIC skills to work with the Skein team. We don't have money to pay anyone; co-authorship on a paper -- and an Erdos number of 4 -- is our primary reward. (Also, a Skein polo shirt.) Please send me e-mail if you're interested.
Our presentation and paper on Skein in a custom ASIC:
Stefan Tillich's presentation and paper:
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) 2010 by Bruce Schneier.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.