Entries Tagged "cryptography"

Page 53 of 55

SHA Cryptanalysis Paper Online

In February, I wrote about a group of Chinese researchers who broke the SHA-1 hash function. That posting was based on short notice from the researchers. Since then, many people have written me asking about the research and the actual paper, some questioning the validity of the research because of the lack of documentation.

The paper did exist; I saw a copy. They will present it at the Crypto conference in August. I believe they didn’t post it because Crypto requires that submitted papers not be previously published, and they misunderstood that to mean that it couldn’t be widely distributed in any way.

Now there’s a copy of the paper on the web. You can read “Finding Collisions in the Full SHA-1,” by Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu, here.

Posted on June 24, 2005 at 12:46 PMView Comments

Password Safe

Password Safe is a free Windows password-storage utility. These days, anyone who is on the Web regularly needs too many passwords, and it’s impossible to remember them all. I have long advocated writing them all down on a piece of paper and putting it in your wallet.

I designed Password Safe as another solution. It’s a small program that encrypts all of your passwords using one passphrase. The program is easy to use, and isn’t bogged down by lots of unnecessary features. Security through simplicity.

Password Safe 2.11 is now available.

Currently, Password Safe is an open source project at SourceForge, and is run by Rony Shapiro. Thank you to him and to all the other programmers who worked on the project.

Note that my Password Safe is not the same as this, this, this, or this PasswordSafe. (I should have picked a more obscure name for the program.)

It is the same as this, for the PocketPC.

Posted on June 15, 2005 at 1:35 PMView Comments

Attack on the Bluetooth Pairing Process

There’s a new cryptographic result against Bluetooth. Yaniv Shaked and Avishai Wool of Tel Aviv University in Israel have figured out how to recover the PIN by eavesdropping on the pairing process.

Pairing is an important part of Bluetooth. It’s how two devices—a phone and a headset, for example—associate themselves with one another. They generate a shared secret that they use for all future communication. Pairing is why, when on a crowded subway, your Bluetooth devices don’t link up with all the other Bluetooth devices carried by everyone else.

According to the Bluetooth specification, PINs can be 8-128 bits long. Unfortunately, most manufacturers have standardized on a four decimal-digit PIN. This attack can crack that 4-digit PIN in less than 0.3 sec on an old Pentium III 450MHz computer, and in 0.06 sec on a Pentium IV 3Ghz HT computer.

At first glance, this attack isn’t a big deal. It only works if you can eavesdrop on the pairing process. Pairing is something that occurs rarely, and generally in the safety of your home or office. But the authors have figured out how to force a pair of Bluetooth devices to repeat the pairing process, allowing them to eavesdrop on it. They pretend to be one of the two devices, and send a message to the other claiming to have forgotten the link key. This prompts the other device to discard the key, and the two then begin a new pairing session.

Taken together, this is an impressive result. I can’t be sure, but I believe it would allow an attacker to take control of someone’s Bluetooth devices. Certainly it allows an attacker to eavesdrop on someone’s Bluetooth network.

News story here.

Posted on June 3, 2005 at 10:19 AMView Comments

Eric Schmidt on Secrecy and Security

From Information Week:

InformationWeek: What about security? Have you been paying as much attention to security as, say Microsoft—you can debate whether or not they’ve been successful, but they’ve poured a lot of resources into it.

Schmidt: More people to a bad architecture does not necessarily make a more secure system. Why don’t you define security so I can answer your question better?

InformationWeek: I suppose it’s an issue of making the technology transparent enough that people can deploy it with confidence.

Schmidt: Transparency is not necessarily the only way you achieve security. For example, part of the encryption algorithms are not typically made available to the open source community, because you don’t want people discovering flaws in the encryption.

Actually, he’s wrong. Everything about an encryption algorithm should always be made available to everyone, because otherwise you’ll invariably have exploitable flaws in your encryption.

My essay on the topic is here.

Posted on May 31, 2005 at 1:09 PMView Comments

AES Timing Attack

Nice timing attack against AES.

For those of you who don’t know, timing attacks are an example of side-channel cryptanalysis: cryptanalysis using additional information about the inner workings of the cryptographic algorithm. I wrote about them here.

What’s the big idea here?

There are two ways to look at a cryptographic primitive: block cipher, digital signature function, whatever. The first is as a chunk of math. The second is a physical (or software) implementation of that math.

Traditionally, cryptanalysis has been directed solely against the math. Differential and linear cryptanalysis are good examples of this: high-powered mathematical tools that can be used to break different block ciphers.

On the other hand, timing attacks, power analysis, and fault analysis all makes assumptions about implementation, and uses additional information garnered from attacking those implementations. Failure analysis assumes a one-bit feedback from the implementation—was the message successfully decrypted—in order to break the underlying cryptographic primitive. Timing attacks assumes that an attacker knows how long a particular encryption operation takes.

Posted on May 17, 2005 at 10:05 AMView Comments

The Potential for an SSH Worm

SSH, or secure shell, is the standard protocol for remotely accessing UNIX systems. It’s used everywhere: universities, laboratories, and corporations (particularly in data-intensive back office services). Thanks to SSH, administrators can stack hundreds of computers close together into air-conditioned rooms and administer them from the comfort of their desks.

When a user’s SSH client first establishes a connection to a remote server, it stores the name of the server and its public key in a known_hosts database. This database of names and keys allows the client to more easily identify the server in the future.

There are risks to this database, though. If an attacker compromises the user’s account, the database can be used as a hit-list of follow-on targets. And if the attacker knows the username, password, and key credentials of the user, these follow-on targets are likely to accept them as well.

A new paper from MIT explores the potential for a worm to use this infection mechanism to propagate across the Internet. Already attackers are exploiting this database after cracking passwords. The paper also warns that a worm that spreads via SSH is likely to evade detection by the bulk of techniques currently coming out of the worm detection community.

While a worm of this type has not been seen since the first Internet worm of 1988, attacks have been growing in sophistication and most of the tools required are already in use by attackers. It’s only a matter of time before someone writes a worm like this.

One of the countermeasures proposed in the paper is to store hashes of host names in the database, rather than the names themselves. This is similar to the way hashes of passwords are stored in password databases, so that security need not rely entirely on the secrecy of the database.

The authors of the paper have worked with the open source community, and version 4.0 of OpenSSH has the option of hashing the known-hosts database. There is also a patch for OpenSSH 3.9 that does the same thing.

The authors are also looking for more data to judge the extent of the problem. Details about the research, the patch, data collection, and whatever else thay have going on can be found here.

Posted on May 10, 2005 at 9:06 AMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.