This website does readability filtering of other pages. All styles, scripts, forms and ads are stripped. If you want your website excluded or have other feedback, use this form.

Schneier on Security: Blog Entries Tagged cryptography

Schneier on Security

Blog > Entries by Tag >

Entries Tagged “cryptography”

Page 5 of 44

Whistleblower Investigative Report on NSA Suite B Cryptography

The NSA has been abandoning secret and proprietary cryptographic algorithms in favor of commercial public algorithms, generally known as "Suite B." In 2010, an NSA employee filed some sort of whistleblower complaint, alleging that this move is both insecure and wasteful. The US DoD Inspector General investigated and wrote a report in 2011.

The report -- slightly redacted and declassified -- found that there was no wrongdoing. But the report is an interesting window into the NSA's system of algorithm selection and testing (pages 5 and 6), as well as how they investigate whistleblower complaints.

Posted on November 9, 2016 at 12:00 PMView Comments

Self-Propagating Smart Light Bulb Worm

This is exactly the sort of Internet-of-Things attack that has me worried:

"IoT Goes Nuclear: Creating a ZigBee Chain Reaction" by Eyal Ronen, Colin OFlynn, Adi Shamir and Achi-Or Weingarten.

Abstract: Within the next few years, billions of IoT devices will densely populate our cities. In this paper we describe a new type of threat in which adjacent IoT devices will infect each other with a worm that will spread explosively over large areas in a kind of nuclear chain reaction, provided that the density of compatible IoT devices exceeds a certain critical mass. In particular, we developed and verified such an infection using the popular Philips Hue smart lamps as a platform. The worm spreads by jumping directly from one lamp to its neighbors, using only their built-in ZigBee wireless connectivity and their physical proximity. The attack can start by plugging in a single infected bulb anywhere in the city, and then catastrophically spread everywhere within minutes, enabling the attacker to turn all the city lights on or off, permanently brick them, or exploit them in a massive DDOS attack. To demonstrate the risks involved, we use results from percolation theory to estimate the critical mass of installed devices for a typical city such as Paris whose area is about 105 square kilometers: The chain reaction will fizzle if there are fewer than about 15,000 randomly located smart lights in the whole city, but will spread everywhere when the number exceeds this critical mass (which had almost certainly been surpassed already).

To make such an attack possible, we had to find a way to remotely yank already installed lamps from their current networks, and to perform over-the-air firmware updates. We overcame the first problem by discovering and exploiting a major bug in the implementation of the Touchlink part of the ZigBee Light Link protocol, which is supposed to stop such attempts with a proximity test. To solve the second problem, we developed a new version of a side channel attack to extract the global AES-CCM key that Philips uses to encrypt and authenticate new firmware. We used only readily available equipment costing a few hundred dollars, and managed to find this key without seeing any actual updates. This demonstrates once again how difficult it is to get security right even for a large company that uses standard cryptographic techniques to protect a major product.

EDITED TO ADD: BoingBoing post. Slashdot thread.

Posted on November 9, 2016 at 6:54 AMView Comments

Hacking Bridge-Hand Generation Software


Roughly three weeks later, there is a operation program available to crack ACBL hand records.

  • Given three consecutive boards, all the remaining boards for that session can be determined.
  • The program can be easily parallelized. This analysis can be finished while sessions are still running

this would permit the following type of attack:

  • A confederate watch boards 1-3 of the USBF team trials on vugraph
  • The confederate uses Amazon web services to crack all the rest of the boards for that session
  • The confederate texts the hands to a players smart phone
  • The player hits the head, whips out his smart phone, and ...

Posted on September 16, 2016 at 12:12 PMView Comments

Collision Attacks Against 64-Bit Block Ciphers

We've long known that 64 bits is too small for a block cipher these days. That's why new block ciphers like AES have 128-bit, or larger, block sizes. The insecurity of the smaller block is nicely illustrated by a new attack called "Sweet32." It exploits the ability to find block collisions in Internet protocols to decrypt some traffic, even though the attackers never learn the key.

Paper here. Matthew Green has a nice explanation of the attack. And some news articles. Hacker News thread.

Posted on August 26, 2016 at 2:19 PMView Comments

Google's Post-Quantum Cryptography

News has been bubbling about an announcement by Google that it's starting to experiment with public-key cryptography that's resistant to cryptanalysis by a quantum computer. Specifically, it's experimenting with the New Hope algorithm.

It's certainly interesting that Google is thinking about this, and probably okay that it's available in the Canary version of Chrome, but this algorithm is by no means ready for operational use. Secure public-key algorithms are very hard to create, and this one has not had nearly enough analysis to be trusted. Lattice-based public-key cryptosystems such as New Hope are particularly subtle -- and we cryptographers are still learning a lot about how they can be broken.

Targets are important in cryptography, and Google has turned New Hope into a good one. Consider this an opportunity to advance our cryptographic knowledge, not an offer of a more-secure encryption option. And this is the right time for this area of research, before quantum computers make discrete-logarithm and factoring algorithms obsolete.

Posted on July 12, 2016 at 12:53 PMView Comments

CIA Director John Brennan Pretends Foreign Cryptography Doesn't Exist

Last week, CIA director John Brennan told a Senate committee that there wasn't any strong cryptography outside of the US.

CIA director John Brennan told US senators they shouldn't worry about mandatory encryption backdoors hurting American businesses.

And that's because, according to Brennan, there's no one else for people to turn to: if they don't want to use US-based technology because it's been forced to use weakened cryptography, they'll be out of luck because non-American solutions are simply "theoretical."

Here's the quote:

"US companies dominate the international market as far as encryption technologies that are available through these various apps, and I think we will continue to dominate them," Brennan said.

"So although you are right that there's the theoretical ability of foreign companies to have those encryption capabilities available to others, I do believe that this country and its private sector are integral to addressing these issues."

Is he actually lying there? I suppose it is possible that he's simply that ignorant. Strong foreign cryptography hasn't been "theoretical" for decades. And earlier this year, I released a survey of foreign cryptography products, listing 546 non-theoretical products from 54 countries outside the US.

I know Sen. Wyden knows about my survey. I hope he asks Brennan about it.

Slashdot thread. HackerNews thread.

EDITED TO ADD (6/22): Herb Lin comments.

Posted on June 20, 2016 at 12:24 PMView Comments

The Unfalsifiability of Security Claims

Interesting research paper: Cormac Herley, "Unfalsifiability of security claims":

There is an inherent asymmetry in computer security: things can be declared insecure by observation, but not the reverse. There is no observation that allows us to declare an arbitrary system or technique secure. We show that this implies that claims of necessary conditions for security (and sufficient conditions for insecurity) are unfalsifiable. This in turn implies an asymmetry in self-correction: while the claim that countermeasures are sufficient is always subject to correction, the claim that they are necessary is not. Thus, the response to new information can only be to ratchet upward: newly observed or speculated attack capabilities can argue a countermeasure in, but no possible observation argues one out. Further, when justifications are unfalsifiable, deciding the relative importance of defensive measures reduces to a subjective comparison of assumptions. Relying on such claims is the source of two problems: once we go wrong we stay wrong and errors accumulate, and we have no systematic way to rank or prioritize measures.

This is both true and not true.

Mostly, it's true. It's true in cryptography, where we can never say that an algorithm is secure. We can either show how it's insecure, or say something like: all of these smart people have spent lots of hours trying to break it, and they can't -- but we don't know what a smarter person who spends even more hours analyzing it will come up with. It's true in things like airport security, where we can easily point out insecurities but are unable to similarly demonstrate that some measures are unnecessary. And this does lead to a ratcheting up on security, in the absence of constraints like budget or processing speed. It's easier to demand that everyone take off their shoes for special screening, or that we add another four rounds to the cipher, than to argue the reverse.

But it's not entirely true. It's difficult, but we can analyze the cost-effectiveness of different security measures. We can compare them with each other. We can make estimations and decisions and optimizations. It's just not easy, and often it's more of an art than a science. But all is not lost.

Still, a very good paper and one worth reading.

Posted on May 27, 2016 at 6:19 AMView Comments

←Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 Next→

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.