NIST Helps You With Cryptography

Getting cryptography right isn’t easy, and it’s a lot worse on constrained devices like microcontrollers. RAM is usually the bottleneck — you will smash your stack computing a SHA-2 hash on an AVR — but other resources like computing power and flash code storage space are also at a premium. Trimming down a standard algorithm to work within these constraints opens up the Pandora’s box of implementation-specific flaws.

NIST stepped up to the plate, starting a lightweight cryptography project in 2013 which has now come out with a first report, and here it is as a PDF. The project is ongoing, so don’t expect a how-to guide. Indeed, most of the report is a description of the problems with crypto on small devices. Given the state of IoT security, just defining the problem is a huge contribution.

Still, there are some concrete recommendations. Here are some spoilers. For encryption, they recommend a trimmed-down version of AES-128, which is a well-tested block cipher on the big machines. For message authentication, they’re happy with Galois/Counter Mode and AES-128.

I was most interested in hashing, and came away disappointed; the conclusion is that the SHA-2 and SHA-3 families simply require too much state (and RAM) and they make no recommendation, leaving you to pick among less-known functions: check out PHOTON or SPONGENT, and they’re still being actively researched.

If you think small-device security is easy, read through the 22-question checklist that starts on page twelve. And if you’re looking for a good starting point to read up on the state of the art, the bibliography is extensive.

Your tax dollars at work. Thanks, NIST!

And thanks [acs] for the tip!

Hackaday Prize Entry: Secure Storage on SD Cards

Here’s a puzzler for you: how do you securely send data from one airgapped computer to another? Sending it over a network is right out, because that’s the entire point of an airgap. A sneakernet is inherently insecure, and you shouldn’t overestimate the security of a station wagon filled with tapes. For his Hackaday Prize entry, [Nick Sayer] has a possible solution. It’s the Sankara Stones from Indiana Jones and the Temple of Doom, or a USB card reader that requires two cards. Either way, it’s an interesting experiment in physical security for data.

The idea behind the Orthrus, a secure RAID USB storage device for two SD cards, is to pair two SD cards. With both cards, you can read and write to this RAID drive without restriction. With only one, the data is irretrievable so they are safe during transit if shipped separately.

The design for this device is based around the ATXMega32A4U. It’s pretty much what you would expect from an ATMega, but this has a built-in full speed USB interface and hardware AES support. The USB is great for presenting two SD cards as a single drive, and the AES port is used to encrypt the data with a key that is stored in a key storage block on each card.

For the intended use case, it’s a good design. You can only get the data off of these SD cards if you have both of them. However, [Nick] is well aware of Schneier’s Law — anyone can design a cryptosystem that they themselves can’t break. That’s why he’s looking for volunteers to crack the Orthrus. It’s an interesting challenge, and one we’d love to see broken.

33C3: How Can You Trust Your Random Numbers?

One of the standout talks at the 33rd Chaos Communications Congress concerned pseudo-random-number generators (PRNGs). [Vladimir Klebanov] (right) and [Felix Dörre] (left) provided a framework for making sure that PRNGs are doing what they should. Along the way, they discovered a flaw in Libgcrypt/GNUPG, which they got fixed. Woot.

mpv-shot0012-zoomCryptographically secure random numbers actually matter, a lot. If you’re old enough to remember the Debian OpenSSL debacle of 2008, essentially every Internet service was backdoorable due to bad random numbers. So they matter. [Vladimir] makes the case that writing good random number generators is very, very hard. Consequently, it’s very important that their output be tested very, very well.

So how can we test them? [Vladimir] warns against our first instinct, running a statistical test suite like DIEHARD. He points out (correctly) that running any algorithm through a good enough hash function will pass statistical tests, but that doesn’t mean it’s good for cryptography.
Continue reading “33C3: How Can You Trust Your Random Numbers?”

33C3: Chris Gerlinsky Cracks Pay TV

People who have incredible competence in a wide range of fields are rare, and it can appear deceptively simple when they present their work. [Chris Gerlinksy]’s talk on breaking the encryption used on satellite and cable pay TV set-top boxes was like that. (Download the slides, as PDF.) The end result of his work is that he gets to watch anything on pay TV, but getting to watch free wrestling matches is hardly the point of an epic hack like this.

The talk spans hardware reverse engineering of the set-top box itself, chip decapping, visual ROM recovery, software reverse analysis, chip glitching, creation of custom glitching hardware, several levels of crypto, and a lot of very educated guessing. Along the way, you’ll learn everything there is to know about how broadcast streams are encrypted and delivered. Watch this talk now.

Some of the coolest bits:

  • Reading out the masked ROM from looking at it with a microscope never fails to amaze us.
  • A custom chip-glitcher rig was built, and is shown in a few iterations, finally ending up in a “fancy” project box. But it’s the kind of thing you could build at home: a microcontroller controlling a switch on a breadboard.
  • The encoder chip stores its memory in RAM: [Chris] uses a beautiful home-brew method of desoldering the power pins, connecting them up to a battery, and desoldering the chip from the board for further analysis.
  • The chip runs entirely in RAM, forcing [Chris] to re-glitch the chip and insert his payload code every time it resets. And it resets a lot, because the designers added reset vectors between the bytes of the desired keys. Very sneaky.
  • All of this was done by sacrificing only one truckload of set-top boxes.

Our jaw dropped repeatedly during this presentation. Go watch it now.

Prime Numbers are Stranger than You Thought

If you’ve spent any time around prime numbers, you know they’re a pretty odd bunch. (Get it?) But it turns out that they’re even stranger than we knew — until recently. According to this very readable writeup of brand-new research by [Kannan Soundararajan] and [Robert Lemkein], the final digits of prime numbers repel each other.

More straightforwardly stated, if you pick any given prime number, the last digit of the next-largest prime number is disproportionately unlikely to match the final digit of your prime. Even stranger, they seem to have preferences. For instance, if your prime ends in 3, it’s more likely that the next prime will end in 9 than in 1 or 7. Whoah!

Even spookier? The finding holds up in many different bases. It was actually first noticed in base-three. The original paper is up on Arxiv, so go check it out.

This is a brand-new finding that’s been hiding under people’s noses essentially forever. The going assumption was that primes were distributed essentially randomly, and now we have empirical evidence that it’s not true. What this means for cryptology or mathematics? Nobody knows, yet. Anyone up for wild speculation? That’s what the comments section is for.

(Headline photo of researchers Kannan Soundararajan and Robert Lemke: Waheeda Khalfan)

Shmoocon 2016: Computing In A Post Quantum World

There’s nothing more dangerous, so the cryptoheads say, than quantum computing. Instead of using the state of a transistor to hold the value of a bit as in traditional computers, quantum computers use qubits, or quantum information like the polarization of a photon. According to people who know nothing about quantum computers, they are the beginning of the end, the breaking of all cryptography, and the Rise of the Machines. Lucky for us, [Jean-Philippe Aumasson] actually knows a thing or two about quantum computers and was able to teach us a few things at his Shmoocon talk this weekend, “Crypto and Quantum and Post Quantum”

This talk is the continuation of [Jean-Philippe]’s DEF CON 23 talk that covered the basics of quantum computing (PDF) In short, quantum computers are not fast – they’re just coprocessors for very, very specialized algorithms. Quantum computers do not say P=NP, and can not be used on NP-hard problems, anyway. The only thing quantum computers have going for them is the ability to completely destroy public key cryptography. Any form of cryptography that uses RSA, Diffie-Hellman, Elliptic curves is completely and totally broken. With quantum computers, we’re doomed. That’s okay, according to the DEF CON talk – true quantum computers may never be built.

The astute reader would question the fact that quantum computers may never be built. After all, D-Wave is selling quantum computers to Google, Lockheed, and NASA. These are not true quantum computers. Even if they’re 100 Million times faster than a PC, they’re only faster for one very specific algorithm. These computers cannot simulate a universal quantum computer. They cannot execute Shor’s algorithm, an algorithm that finds the prime factors of an integer. They are not scalable, they are not fault-tolerant, and they are not universal quantum computers.

As far as true quantum computers go, the largest that has every been manufactured only contain a handful of qubits. To crack RSA and the rest of cryptography, millions of qubits are needed. Some algorithms require quantum RAM, which nobody knows how to build. Why then is quantum computing so scary? RSA, ECC, Diffie-Hellman, PGP, SSH and Bitcoin would die overnight if quantum computers existed. That’s a far scarier proposition to someone hijacking your self-driving car or changing the display on a smart, Internet-connected thermostat from Fahrenheit to Celsius.

What is the verdict on quantum computers? Not too great, if you ask [Jean-Philippe]. In his opinion, it will be 100 years until we have a quantum computer. Until then, crypto is safe, and the NSA isn’t going to break your codez if you use a long-enough key.

Random Parcel Launches Steganographic Compulsion

A mysterious CD arrives in the mail with a weird handwritten code on it. What should you do? Put it in the computer and play the thing, of course!

Some might be screaming at their screens right now… this is how modern horror films start and before you know it the undead are lurking behind you waiting to strike. Seasonal thrills aside, this is turning into an involved community effort to solve the puzzle. [Johny] published the video and posted a thread on reddit.

We ran a similar augmented reality game to launch the 2014 Hackaday Prize solved by a dedicated group of hackers. It’s really hard to design puzzles that won’t be immediately solved but can eventually be solved with technology and a few mental leaps. When we come across one of these extremely clever puzzles, we take note.

This has all the hallmarks of a good time. The audio spectrogram shows hidden data embedded in the file — a technique known as steganography. There are some real contortions to make meaning from this. When you’re looking for a solution any little hit of a pattern feels like you’ve found something. But searching for the decrypted string yields a YouTube video with the same name; we wonder if they’ve tried to recover steganographic data from that source?

[Johny] mentions that this parcel was unsolicited and that people have suggested it’s a threat or something non-sensical in its entirety. We’re hoping it’s a publicity stunt and we’re all disappointed in the end, because solving the thing is the best part and publicity wouldn’t work if there was no solution.

The bright minds of the Hackaday community should be the ones who actually solve this. So get to work and let us know what you figure out!