Schneier on Security's Journal
[Most Recent Entries]
[Calendar View]
Friday, July 5th, 2013
| Time |
Event |
| 7:04a |
Is Cryptography Engineering or Science? Responding to a tweet by Thomas Ptacek saying, "If you're not learning crypto by coding attacks, you might not actually be learning crypto," Colin Percival published a well-thought-out rebuttal, saying in part:
If we were still in the 1990s, I would agree with Thomas. 1990s cryptography was full of holes, and the best you could hope for was to know how your tools were broken so you could try to work around their deficiencies. This was a time when DES and RC4 were widely used, despite having well-known flaws. This was a time when people avoided using CTR mode to convert block ciphers into stream ciphers, due to concern that a weak block cipher could break if fed input blocks which shared many (zero) bytes in common. This was a time when people cared about the "error propagation" properties of block ciphers that is, how much of the output would be mangled if a small number of bits in the ciphertext are flipped. This was a time when people routinely advised compressing data before encrypting it, because that "compacted" the entropy in the message, and thus made it "more difficult for an attacker to identify when he found the right key". It should come as no surprise that SSL, designed during this era, has had a long list of design flaws.
Cryptography in the 2010s is different. Now we start with basic components which are believed to be highly secure e.g., block ciphers which are believed to be indistinguishable from random permutations and which have been mathematically proven to be secure against certain types of attacks e.g., AES is known to be immune to differential cryptanalysis. From those components, we then build higher-order systems using mechanisms which have been proven to not introduce vulnerabilities. For example, if you generate an ordered sequence of packets by encrypting data using an indistinguishable-from-random-permutation block cipher (e.g., AES) in CTR mode using a packet sequence number as the CTR nonce, and then append a weakly-unforgeable MAC (e.g., HMAC-SHA256) of the encrypted data and the packet sequence number, the packets both preserve privacy and do not permit any undetected tampering (including replays and reordering of packets). Life will become even better once Keccak (aka. SHA-3) becomes more widely reviewed and trusted, as its "sponge" construction can be used to construct -- with provable security -- a very wide range of important cryptographic components.
He recommends a more modern approach to cryptography: "studying the theory and designing systems which you can prove are secure."
I think both of statements are true -- and not contradictory at all. The apparent disagreement stems from differing definitions of cryptography.
Many years ago, on the Cryptographer's Panel at an RSA conference, then-chief scientist for RSA Bert Kaliski talked about the rise of something he called the "crypto engineer." His point was that the practice of cryptography was changing. There was the traditional mathematical cryptography -- designing and analyzing algorithms and protocols, and building up cryptographic theory -- but there was also a more practice-oriented cryptography: taking existing cryptographic building blocks and creating secure systems out of them. It's this latter group he called crypto engineers. It's the group of people I wrote Applied Cryptography, and, most recently, co-wrote Cryptography Engineering, for. Colin knows this, directing his advice to "developers" -- Kaliski's crypto engineers.
Traditional cryptography is a science -- applied mathematics -- and applied cryptography is engineering. I prefer the term "security engineering," because it necessarily encompasses a lot more than cryptography -- see Ross Andersen's great book of that name. And mistakes in engineering are where a lot of real-world cryptographic systems break.
Provable security has its limitations. Cryptographer Lars Knudsen once said: "If it's provably secure, it probably isn't." Yes, we have provably secure cryptography, but those proofs take very specific forms against very specific attacks. They reduce the number of security assumptions we have to make about a system, but we still have to make a lot of security assumptions.
And cryptography has its limitations in general, despite the apparent strengths. Cryptography's great strength is that it gives the defender a natural advantage: adding a single bit to a cryptographic key increases the work to encrypt by only a small amount, but doubles the work required to break the encryption. This is how we design algorithms that -- in theory -- can't be broken until the universe collapses back on itself.
Despite this, cryptographic systems are broken all the time: well before the heat death of the universe. They're broken because of software mistakes in coding the algorithms. They're broken because the computer’s memory management system left a stray copy of the key lying around, and the operating system automatically copied it to disk. They're broken because of buffer overflows and other security flaws. They're broken by side-channel attacks. They're broken because of bad user interfaces, or insecure user practices.
Lots of people have said: "In theory, theory and practice are the same. But in practice, they are not." It’s true about cryptography. If you want to be a cryptographer, study mathematics. Study the mathematics of cryptography, and especially cryptanalysis. There's a lot of art to the science, and you won't be able to design good algorithms and protocols until you gain experience in breaking existing ones. If you want to be a security engineer, study implementations and coding. Take the tools cryptographers create, and learn how to use them well.
The world needs security engineers even more than it needs cryptographers. We're great at mathematically secure cryptography, and terrible at using those tools to engineer secure systems.
After writing this, I found a conversation between the two where they both basically agreed with me. | | 12:08p |
Sixth Movie-Plot Threat Contest Winner On April 1, I announced the Sixth Mostly-Annual Movie-Plot Threat Contest:
For this year's contest, I want a cyberwar movie-plot threat. (For those who don't know, a movie-plot threat is a scare story that would make a great movie plot, but is much too specific to build security policy around.) Not the Chinese attacking our power grid or shutting off 911 emergency services -- people are already scaring our legislators with that sort of stuff. I want something good, something no one has thought of before.
On May 15, I announced the five semi-finalists. Voting continued through the end of the month, and the winner is Russell Thomas:
It's November 2015 and the United Nations Climate Change Conference (UNCCC) is underway in Amsterdam, Netherlands. Over the past year, ocean level rise has done permanent damage to critical infrastructure in Maldives, killing off tourism and sending the economy into freefall. The Small Island Developing States are demanding immediate relief from the Green Climate Fund, but action has been blocked. Conspiracy theories flourish. For months, the rhetoric between developed and developing countries has escalated to veiled and not-so-veiled threats. One person in elites of the Small Island Developing States sees an opportunity to force action.
He's Sayyid Abdullah bin Yahya, an Indonesian engineer and construction magnate with interests in Bahrain, Bangladesh, and Maldives, all directly threatened by recent sea level rise. Bin Yahya's firm installed industrial control systems on several flood control projects, including in the Maldives, but these projects are all stalled and unfinished for lack of financing. He also has a deep, abiding enmity against Holland and the Dutch people, rooted in the 1947 Rawagede massacre that killed his grandfather and father. Like many Muslims, he declared that he was personally insulted by Queen Beatrix's gift to the people of Indonesia on the 50th anniversary of the massacre -- a Friesian cow. "Very rude. That's part of the Dutch soul, this rudeness", he said at the time. Also like many Muslims, he became enraged and radicalized in 2005 when the Dutch newspaper Jyllands-Posten published cartoons of the Prophet.
Of all the EU nations, Holland is most vulnerable to rising sea levels. It has spent billions on extensive barriers and flood controls, including the massive Oosterscheldekering storm surge barrier, designed and built in the 80s to protect against a 10,000-year storm surge. While it was only used 24 times between 1986 and 2010, in the last two years the gates have been closed 46 times.
As the UNCCC conference began in November 2015, the Oosterscheldekering was closed yet again to hold off the surge of an early winter storm. Even against low expectations, the first day's meetings went very poorly. A radicalized and enraged delegation from the Small Island Developing States (SIDS) presented an ultimatum, leading to denunciations and walkouts. "What can they do -- start a war?" asked the Dutch Minister of Infrastructure and the Environment in an unguarded moment. There was talk of canceling the rest of the conference.
Overnight, there are a series of news stories in China, South America, and United States reporting malfunctions of dams that resulted in flash floods and death of tens or hundreds people in several cases. Web sites associated with the damns were all defaced with the text of the SIDS ultimatum. In the morning, all over Holland there were reports of malfunctions of control equipment associated with flood monitoring and control systems. The winter storm was peaking that day with an expected surge of 7 meters (22 feet), larger than the Great Flood of 1953. With the Oosterscheldekering working normally, this is no worry. But at 10:43am, the storm gates unexpectedly open.
Microsoft Word claims it's 501 words, but I'm letting that go.
This is the first professional -- a researcher -- who has won the contest. Be sure to check out his blogs, and his paper at WEIS this year.
Congratulations, Russell Thomas. Your box of fabulous prizes will be on its way to you soon.
History: The First Movie-Plot Threat Contest rules and winner. The Second Movie-Plot Threat Contest rules, semifinalists, and winner. The Third Movie-Plot Threat Contest rules, semifinalists, and winner. The Fourth Movie-Plot Threat Contest rules and winner. The Fifth Movie-Plot Threat Contest rules, semifinalists, and winner. | | 1:33p |
How Apple Continues to Make Security Invisible Interesting article:
Apple is famously focused on design and human experience as their top guiding principles. When it comes to security, that focus created a conundrum. Security is all about placing obstacles in the way of attackers, but (despite the claims of security vendors) those same obstacles can get in the way of users, too.
[...]
For many years, Apple tended to choose good user experience at the expense of leaving users vulnerable to security risks. That strategy worked for a long time, in part because Apple's comparatively low market share made its products less attractive targets. But as Apple products began to gain in popularity, many of us in the security business wondered how Apple would adjust its security strategies to its new position in the spotlight.
As it turns out, the company not only handled that change smoothly, it has embraced it. Despite a rocky start, Apple now applies its impressive design sensibilities to security, playing the game its own way and in the process changing our expectations for security and technology. | | 4:01p |
Friday Squid Blogging: Giant Origami Squid Giant origami squid photo found -- without explanation -- on Reddit.
As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered. |
|
