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 45

Google Releases Crypto Test Suite

Google has released Project Wycheproof -- a test suite designed to test cryptographic libraries against a series of known attacks. From a blog post:

In cryptography, subtle mistakes can have catastrophic consequences, and mistakes in open source cryptographic software libraries repeat too often and remain undiscovered for too long. Good implementation guidelines, however, are hard to come by: understanding how to implement cryptography securely requires digesting decades' worth of academic literature. We recognize that software engineers fix and prevent bugs with unit testing, and we found that many cryptographic issues can be resolved by the same means

The tool has already found over 40 security bugs in cryptographic libraries, which are (all? mostly?) currently being fixed.

News article. Slashdot thread.

Posted on December 20, 2016 at 6:12 AMView Comments

Let's Encrypt Is Making Web Encryption Easier

That's the conclusion of a research paper:

Once [costs and complexity] are eliminated, it enables big hosting providers to issue and deploy certificates for their customers in bulk, thus quickly and automatically enable encryption across a large number of domains. For example, we have shown that currently, 47% of LE certified domains are hosted at three large hosting companies (Automattic/wordpress.com, Shopify, and OVH).

Paper: "No domain left behind: is Let's Encrypt democratizing encryption?"

Abstract: The 2013 National Security Agency revelations of pervasive monitoring have lead to an "encryption rush" across the computer and Internet industry. To push back against massive surveillance and protect users privacy, vendors, hosting and cloud providers have widely deployed encryption on their hardware, communication links, and applications. As a consequence, the most of web traffic nowadays is encrypted. However, there is still a significant part of Internet traffic that is not encrypted. It has been argued that both costs and complexity associated with obtaining and deploying X.509 certificates are major barriers for widespread encryption, since these certificates are required to established encrypted connections. To address these issues, the Electronic Frontier Foundation, Mozilla Foundation, and the University of Michigan have set up Let's Encrypt (LE), a certificate authority that provides both free X.509 certificates and software that automates the deployment of these certificates. In this paper, we investigate if LE has been successful in democratizing encryption: we analyze certificate issuance in the first year of LE and show from various perspectives that LE adoption has an upward trend and it is in fact being successful in covering the lower-cost end of the hosting market.

Reddit thread.

Posted on December 14, 2016 at 6:46 AMView Comments

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

Interesting:

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

←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 45 Next→

Photo of Bruce Schneier by Per Ervland.

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