Entries Tagged "cryptography"

Page 48 of 56

New Timing Attack Against RSA

A new paper describes a timing attack against RSA, one that bypasses existing security measures against these sorts of attacks. The attack described is optimized for the Pentium 4, and is particularly suited for applications like DRM.

Meta moral: If Alice controls the device, and Bob wants to control secrets inside the device, Bob has a very difficult security problem. These “side-channel” attacks—timing, power, radiation, etc.—allow Alice to mount some very devastating attacks against Bob’s secrets.

I’m going to write more about this for Wired next week, but for now you can read the paper, the Slashdot thread, and the essay I wrote in 1998 about side-channel attacks (also this academic paper).

Posted on November 21, 2006 at 7:24 AM • View Comments

Classical Crypto with Lasers

I simply don’t have the physics background to evaluate this:

Scheuer and Yariv’s concept for key distribution involves establishing a laser oscillation between the two users, who each decide how to reflect the light at their end by choosing one of three mirrors that peak at different frequencies.

Before a key is exchanged, the users reset the system by using the first mirror. Then they both randomly select a bit (either 1 or 0) and choose the corresponding mirror out of the other two, causing the lasing properties (wavelength and intensity) to shift in accordance with the mirror they chose. Because each user knows his or her own bit, they can determine the value of each other’s bits; but an eavesdropper, who doesn’t know either bit, could only figure out the correlation between bits, but not the bits themselves. Similar to quantum key distribution systems, the bit exchange is successful in about 50% of the cases.

“For a nice analogy, consider a very large ‘justice scale’ where Alice is at one side and Bob is at the other,” said Scheuer. “Both Alice and Bob have a set of two weights (say one pound representing ‘0’ and two pounds representing ‘1’). To exchange a bit, Alice and Bob randomly select a bit and put the corresponding weight on the scales. If they pick different bits, the scales will tilt toward the heavy weight, thus indicating who picked ‘1’ and who picked ‘0.’ If however, they choose the same bit, the scales will remain balanced, regardless whether they (both) picked ‘0’ or ‘1.’ These bits can be used for the key because Eve, who in this analogy can only observe the tilt of the scales, cannot deduce the exchanged bit (in the previous case, Eve could deduce the bits). Of course, there are some differences between the laser concept and the scales analogy: in the laser system, the successful bit exchanges occur when Alice and Bob pick opposite bits, and not identical; also, there is the third state needed for resetting the laser, etc. But the underlying concept is the same: the system uses some symmetry properties to ‘calculate’ the correlation between the bits selected in each side, and it reveals only the correlation. For Alice and Bob, this is enough—but not for Eve.”

But this quote gives me pause:

Although users can’t easily detect an eavesdropper here, the system increases the difficulty of eavesdropping “almost arbitrarily,” making detecting eavesdroppers almost unnecessary.

EDITED TO ADD (11/6): Here’s the paper.

Posted on November 6, 2006 at 7:49 AM • View Comments

Bureau of Industry and Security Hacked

The BIS is the part of the U.S. Department of Commerce responsible for export control. If you have a dual-use technology that you need special approval in order to export outside the U.S., or to export it to specific countries, BIS is what you submit the paperwork to.

It’s been hacked by “hackers working through Chinese servers,” and has been shut down. This may very well have been a targeted attack.

Manufacturers of hardware crypto devices—mass-market software is exempted—must submit detailed design information to BIS in order to get an export license. There’s a lot of detailed information on crypto products in the BIS computers.

Of course, I have no way of knowing if this information was breached or if that’s what the hackers were after, but it is interesting. On the other hand, any crypto product that relied on this information being secret doesn’t deserve to be on the market anyway.

Posted on October 11, 2006 at 7:16 AM • View Comments

FairUse4WM News

A couple of weeks I ago I wrote about the battle between Microsoft’s DRM system and FairUse4WM, which breaks it. The news for this week is that Microsoft has patched their security against FairUseWM 1.2 and filed a lawsuit against the program’s anonymous authors, and those same anonymous authors have released FairUse4WM 1.3, which breaks the latest Microsoft patch.

We asked Viodentia about Redmond’s accusation that he and/or his associates broke into its systems in order to obtain the IP necessary to crack PlaysForSure; Vio replied that he’s “utterly shocked” by the charge. “I didn’t use any Microsoft source code. However, I believe that this lawsuit is a fishing expedition to get identity information, which can then be used to either bring more targeted lawsuits, or to cause other trouble.” We’re sure Microsoft would like its partners and the public to think that its DRM is generally infallible and could only be cracked by stealing its IP, so Viodentia’s conclusion about its legal tactics seems pretty fair, obvious, and logical to us.

What’s interesting about this continuing saga is how different it is from the normal find-vulnerability-then-patch sequence. The authors of FairUse4WM aren’t finding bugs and figuring out how to exploit them, forcing Microsoft to patch them. This is a sequence of crack, fix, re-crack, re-fix, etc.

The reason we’re seeing this—and this is going to be the norm for DRM systems—is that DRM is fundamentally an impossible problem. Making it work at all involves tricks, and breaking DRM is akin to “fixing” the software so the tricks don’t work. Anyone looking for a demonstation that technical DRM is doomed should watch this story unfold. (If Microsoft has any chance of winning at all, it’s via the legal route.)

Posted on September 28, 2006 at 12:55 PM • View Comments

Notes from the Hash Function Workshop

Last month, NIST hosted the Second Hash Workshop, primarily as a vehicle for discussing a replacement strategy for SHA-1. (I liveblogged NIST’s first Cryptographic Hash Workshop here, here, here, here, and here.)

As I’ve written about before, there are some impressive cryptanalytic results against SHA-1. These attacks are still not practical, and the hash function is still operationally secure, but it makes sense for NIST to start looking at replacement strategies—before these attacks get worse.

The conference covered a wide variety of topics (see the agenda for details) on hash function design, hash function attacks, hash function features, and so on.

Perhaps the most interesting part was a panel discussion called “SHA-256 Today and Maybe Something Else in a Few Years: Effects on Research and Design.” Moderated by Paul Hoffman (VPN Consortium) and Arjen Lenstra (Ecole Polytechnique Federale de Lausanne), the panel consisted of Niels Ferguson (Microsoft), Antoine Joux (Universite de Versailles-Saint-Quentin-en-Yvelines), Bart Preneel (Katholieke Universiteit Leuven), Ron Rivest (MIT), and Adi Shamir (Weismann Institute of Science).

Paul Hoffman has posted a composite set of notes from the panel discussion. If you’re interested in the current state of hash function research, it’s well worth reading.

My opinion is that we need a new hash function, and that a NIST-sponsored contest is a great way to stimulate research in the area. I think we need one function and one function only, because users won’t know how to choose between different functions. (It would be smart to design the function with a couple of parameters that can be easily changed to increase security—increase the number of rounds, for example—but it shouldn’t be a variable that users have to decide whether or not to change.) And I think it needs to be secure in the broadest definitions we can come up with: hash functions are the workhorse of cryptographic protocols, and they’re used in all sorts of places for all sorts of reasons in all sorts of applications. We can’t limit the use of hash functions, so we can’t put one out there that’s only secure if used in a certain way.

Posted on September 11, 2006 at 3:30 PM • View Comments

Media Sanitization and Encryption

Last week NIST released Special Publication 800-88, Guidelines for Media Sanitization.

There is a new paragraph in this document (page 7) that was not in the draft version:

Encryption is not a generally accepted means of sanitization. The increasing power of computers decreases the time needed to crack cipher text and therefore the inability to recover the encrypted data can not be assured.

I have to admit that this doesn’t make any sense to me. If the encryption is done properly, and if the key is properly chosen, then erasing the key—and all copies—is equivalent to erasing the files. And if you’re using full-disk encryption, then erasing the key is equivalent to sanitizing the drive. For that not to be true means that the encryption program isn’t secure.

I think NIST is just confused.

Posted on September 11, 2006 at 11:43 AM • View Comments

1 … 46 47 48 49 50 … 56

Sidebar photo of Bruce Schneier by Joe MacInnis.