"Responsible Behavior"
This one is pretty funny, too.
Entries Tagged "cryptography"
Page 44 of 55
PGP and the 5th Amendment
A Vermont federal judge has ruled that a person cannot be compelled by police to divulge his PGP key. This is by no means the end of the legal debate (Orin Kerr comments), but it’s certainly good news.
EDITED TO ADD (1/16): The case is being moved to Federal court.
Dual_EC_DRBG Added to Windows Vista
Microsoft has added the random-number generator Dual_EC-DRBG to Windows Vista, as part of SP1. Yes, this is the same RNG that could have an NSA backdoor.
It’s not enabled by default, and my advice is to never enable it. Ever.
EDITED TO ADD (12/18): I should make this clear that the algorithm is available as a program call. It is not something that the user can enable or disable.
Handbook of Applied Cryptography Online
The Handbook of Applied Cryptography is now available online—legitimately. This is a good book, and well worth downloading.
How to Secure Your Computer, Disks, and Portable Drives
Computer security is hard. Software, computer and network security are all ongoing battles between attacker and defender. And in many cases the attacker has an inherent advantage: He only has to find one network flaw, while the defender has to find and fix every flaw.
Cryptography is an exception. As long as you don’t write your own algorithm, secure encryption is easy. And the defender has an inherent mathematical advantage: Longer keys increase the amount of work the defender has to do linearly, while geometrically increasing the amount of work the attacker has to do.
Unfortunately, cryptography can’t solve most computer-security problems. The one problem cryptography can solve is the security of data when it’s not in use. Encrypting files, archives—even entire disks—is easy.
All of this makes it even more amazing that Her Majesty’s Revenue & Customs in the United Kingdom lost two disks with personal data on 25 million British citizens, including dates of birth, addresses, bank-account information and national insurance numbers. On the one hand, this is no bigger a deal than any of the thousands of other exposures of personal data we’ve read about in recent years—the U.S. Veteran’s Administration loss of personal data of 26 million American veterans is an obvious similar event. But this has turned into Britain’s privacy Chernobyl.
Perhaps encryption isn’t so easy after all, and some people could use a little primer. This is how I protect my laptop.
There are several whole-disk encryption products on the market. I use PGP Disk’s Whole Disk Encryption tool for two reasons. It’s easy, and I trust both the company and the developers to write it securely. (Disclosure: I’m also on PGP Corp.’s Technical Advisory Board.)
Setup only takes a few minutes. After that, the program runs in the background. Everything works like before, and the performance degradation is negligible. Just make sure you choose a secure password—PGP’s encouragement of passphrases makes this much easier—and you’re secure against leaving your laptop in the airport or having it stolen out of your hotel room.
The reason you encrypt your entire disk, and not just key files, is so you don’t have to worry about swap files, temp files, hibernation files, erased files, browser cookies or whatever. You don’t need to enforce a complex policy about which files are important enough to be encrypted. And you have an easy answer to your boss or to the press if the computer is stolen: no problem; the laptop is encrypted.
PGP Disk can also encrypt external disks, which means you can also secure that USB memory device you’ve been using to transfer data from computer to computer. When I travel, I use a portable USB drive for backup. Those devices are getting physically smaller—but larger in capacity—every year, and by encrypting I don’t have to worry about losing them.
I recommend one more complication. Whole-disk encryption means that anyone at your computer has access to everything: someone at your unattended computer, a Trojan that infected your computer and so on. To deal with these and similar threats I recommend a two-tier encryption strategy. Encrypt anything you don’t need access to regularly—archived documents, old e-mail, whatever—separately, with a different password. I like to use PGP Disk’s encrypted zip files, because it also makes secure backup easier (and lets you secure those files before you burn them on a DVD and mail them across the country), but you can also use the program’s virtual-encrypted-disk feature to create a separately encrypted volume. Both options are easy to set up and use.
There are still two scenarios you aren’t secure against, though. You’re not secure against someone snatching your laptop out of your hands as you’re typing away at the local coffee shop. And you’re not secure against the authorities telling you to decrypt your data for them.
The latter threat is becoming more real. I have long been worried that someday, at a border crossing, a customs official will open my laptop and ask me to type in my password. Of course I could refuse, but the consequences might be severe—and permanent. And some countries—the United Kingdom, Singapore, Malaysia—have passed laws giving police the authority to demand that you divulge your passwords and encryption keys.
To defend against both of these threats, minimize the amount of data on your laptop. Do you really need 10 years of old e-mails? Does everyone in the company really need to carry around the entire customer database? One of the most incredible things about the Revenue & Customs story is that a low-level government employee mailed a copy of the entire national child database to the National Audit Office in London. Did he have to? Doubtful. The best defense against data loss is to not have the data in the first place.
Failing that, you can try to convince the authorities that you don’t have the encryption key. This works better if it’s a zipped archive than the whole disk. You can argue that you’re transporting the files for your boss, or that you forgot the key long ago. Make sure the time stamp on the files matches your claim, though.
There are other encryption programs out there. If you’re a Windows Vista user, you might consider BitLocker. This program, embedded in the operating system, also encrypts the computer’s entire drive. But it only works on the C: drive, so it won’t help with external disks or USB tokens. And it can’t be used to make encrypted zip files. But it’s easy to use, and it’s free.
This essay previously appeared on Wired.com.
EDITED TO ADD (12/14): Lots of people have pointed out that the free and open-source program TrueCrypt is a good alternative to PGP Disk. I haven’t used or reviewed the program at all.
College Cryptography Course Online
“Practical Aspects of Modern Cryptography,” taught by Josh Benaloh, Brian LaMacchia, and John Manferdelli at the University of Washington. The page includes links to lecture notes and video of the classes.
Colossus Has Been Rebuilt
The World War II factoring machine, Colossus, is back online.
Not surprisingly, a modern PC is faster.
The Strange Story of Dual_EC_DRBG
Random numbers are critical for cryptography: for encryption keys, random authentication challenges, initialization vectors, nonces, key-agreement schemes, generating prime numbers and so on. Break the random-number generator, and most of the time you break the entire security system. Which is why you should worry about a new random-number standard that includes an algorithm that is slow, badly designed and just might contain a backdoor for the National Security Agency.
Generating random numbers isn’t easy, and researchers have discovered lots of problems and attacks over the years. A recent paper found a flaw in the Windows 2000 random-number generator. Another paper found flaws in the Linux random-number generator. Back in 1996, an early version of SSL was broken because of flaws in its random-number generator. With John Kelsey and Niels Ferguson in 1999, I co-authored Yarrow, a random-number generator based on our own cryptanalysis work. I improved this design four years later—and renamed it Fortuna—in the book Practical Cryptography, which I co-authored with Ferguson.
The U.S. government released a new official standard for random-number generators this year, and it will likely be followed by software and hardware developers around the world. Called NIST Special Publication 800-90 (.pdf), the 130-page document contains four different approved techniques, called DRBGs, or “Deterministic Random Bit Generators.” All four are based on existing cryptographic primitives. One is based on hash functions, one on HMAC, one on block ciphers and one on elliptic curves. It’s smart cryptographic design to use only a few well-trusted cryptographic primitives, so building a random-number generator out of existing parts is a good thing.
But one of those generators—the one based on elliptic curves—is not like the others. Called Dual_EC_DRBG, not only is it a mouthful to say, it’s also three orders of magnitude slower than its peers. It’s in the standard only because it’s been championed by the NSA, which first proposed it years ago in a related standardization project at the American National Standards Institute.
The NSA has always been intimately involved in U.S. cryptography standards—it is, after all, expert in making and breaking secret codes. So the agency’s participation in the NIST (the U.S. Commerce Department’s National Institute of Standards and Technology) standard is not sinister in itself. It’s only when you look under the hood at the NSA’s contribution that questions arise.
Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn’t large enough to make the algorithm unusable—and Appendix E of the NIST standard describes an optional work-around to avoid the issue—but it’s cause for concern. Cryptographers are a conservative bunch: We don’t like to use algorithms that have even a whiff of a problem.
But today there’s an even bigger stink brewing around Dual_EC_DRBG. In an informal presentation (.pdf) at the CRYPTO 2007 conference in August, Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described as a backdoor.
This is how it works: There are a bunch of constants—fixed numbers—in the standard used to define the algorithm’s elliptic curve. These constants are listed in Appendix A of the NIST publication, but nowhere is it explained where they came from.
What Shumow and Ferguson showed is that these numbers have a relationship with a second, secret set of numbers that can act as a kind of skeleton key. If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. To put that in real terms, you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG.
The researchers don’t know what the secret numbers are. But because of the way the algorithm works, the person who produced the constants might know; he had the mathematical opportunity to produce the constants and the secret numbers in tandem.
Of course, we have no way of knowing whether the NSA knows the secret numbers that break Dual_EC-DRBG. We have no way of knowing whether an NSA employee working on his own came up with the constants—and has the secret numbers. We don’t know if someone from NIST, or someone in the ANSI working group, has them. Maybe nobody does.
We don’t know where the constants came from in the first place. We only know that whoever came up with them could have the key to this backdoor. And we know there’s no way for NIST—or anyone else—to prove otherwise.
This is scary stuff indeed.
Even if no one knows the secret numbers, the fact that the backdoor is present makes Dual_EC_DRBG very fragile. If someone were to solve just one instance of the algorithm’s elliptic-curve problem, he would effectively have the keys to the kingdom. He could then use it for whatever nefarious purpose he wanted. Or he could publish his result, and render every implementation of the random-number generator completely insecure.
It’s possible to implement Dual_EC_DRBG in such a way as to protect it against this backdoor, by generating new constants with another secure random-number generator and then publishing the seed. This method is even in the NIST document, in Appendix A. But the procedure is optional, and my guess is that most implementations of the Dual_EC_DRBG won’t bother.
If this story leaves you confused, join the club. I don’t understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It’s public, and rather obvious. It makes no sense from an engineering perspective: It’s too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.
My recommendation, if you’re in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.
In the meantime, both NIST and the NSA have some explaining to do.
This essay originally appeared on Wired.com.
UK Police Can Now Demand Encryption Keys
Under a new law that went into effect this month, it is now a crime to refuse to turn a decryption key over to the police.
I’m not sure of the point of this law. Certainly it will have the effect of spooking businesses, who now have to worry about the police demanding their encryption keys and exposing their entire operations.
Cambridge University security expert Richard Clayton said in May of 2006 that such laws would only encourage businesses to house their cryptography operations out of the reach of UK investigators, potentially harming the country’s economy. “The controversy here [lies in] seizing keys, not in forcing people to decrypt. The power to seize encryption keys is spooking big business,” Clayton said.
“The notion that international bankers would be wary of bringing master keys into UK if they could be seized as part of legitimate police operations, or by a corrupt chief constable, has quite a lot of traction,” he added. “With the appropriate paperwork, keys can be seized. If you’re an international banker you’ll plonk your headquarters in Zurich.”
But if you’re guilty of something that can only be proved by the decrypted data, you might be better off refusing to divulge the key (and facing the maximum five-year penalty the statue provides) instead of being convicted for whatever more serious charge you’re actually guilty of.
I think this is just another skirmish in the “war on encryption” that has been going on for the past fifteen years. (Anyone remember the Clipper chip?) The police have long maintained that encryption is an insurmountable obstacle to law and order:
The Home Office has steadfastly proclaimed that the law is aimed at catching terrorists, pedophiles, and hardened criminals—all parties which the UK government contents are rather adept at using encryption to cover up their activities.
We heard the same thing from FBI Director Louis Freeh in 1993. I called them “The Four Horsemen of the Information Apocalypse“—terrorists, drug dealers, kidnappers, and child pornographers—and have been used to justify all sorts of new police powers.
Sidebar photo of Bruce Schneier by Joe MacInnis.