Academic cryptographers versus commercial cryptographers

Last night I was asked why I distinguish between academic cryptographers and commercial cryptographers. Here’s roughly what I said.

Academic cryptographers invent things. Some examples of these things are the Diffie-Hellman key exchange, RSA encryption and Boneh-Franklin identity-based encryption. Academic cryptographers also invent ways to ensure that cryptographic schemes and protocols are secure. Practice-oriented Provable Security is an example of this.

Most of the creations of academic cryptographers aren’t really very interesting to most people, but that’s not a reflection on the academic cryptographers. Most academic work isn’t very interesting unless you’re a specialist in a very narrow field, and cryptography is just like other academic fields in this respect.

Academic cryptographers need to keep producing new ideas to keep their jobs.

Commercial cryptographers worry about practical implementations of the things that academic cryptographers invent. They turn what’s in the paper “Identity-based Encryption from the Weil Pairing” into Voltage SecureMail, for example. They understand the legal and regulatory environment of business and how cryptography fits into it. And they understand the real-world constraints that make some otherwise-interesting academic creations not very practical.

Commercial cryptographers need to keep producing things that are of value to someone else to keep their jobs.

One example of the difference between academic cryptographers and commercial cryptographers is in how they understand one particular aspect of identity-based encryption. Many academic cryptographers think that the fact that systems that implement IBE inherently have the ability to do key recovery is a bad thing because it makes it possible for a rogue administrator (some would even say the NSA) to decrypt their encrypted data. Commercial cryptographers think that the ability to do key recovery is a good thing because it’s absolutely necessary due to the legal and regulatory environment of business.

From the point of view of the academic cryptographers, they’re right. They don’t want anyone to be able to get access to any data that they might encrypt. Particularly the NSA. And from the point of view of commercial cryptographers, they’re also right. The market for encryption technology that doesn’t include the ability to do key recovery is extremely small. In the real world, CIOs get hit by buses and their replacement needs access to the data that their predecessor encrypted. Even more commonly, administrators need to recover keys for people who lost their keys or forgot the password that controls access to their keys.

But not everyone understands the difference between the two approaches to cryptography. Some people in the business world try to approach cryptography from the point of view of academic cryptographers, and when they do this, it almost always causes problems. I actually come across this fairly often.

I don’t have any firsthand experience with this, but I’ve heard stories of how people in the academic world who try to approach cryptography from the point of view of commercial cryptographers also encounter problems. The places where they work typically put more value on inventing new things, so practical implementations are often considered not as good as less practical, yet new, inventions. So it’s easy to imagine an academic cryptographer who spends his time creating a successful business having problems with his academic department because that’s not the sort of behavior that they want to see.

So the bottom line is that there are really two different approaches to cryptography. The specialized background needed for academic cryptography is too expensive for most of the commercial world to support and the practical approach of commercial cryptographers isn’t really suitable for academic environments. But we really need people working on both aspects of the field if we’re going to see useful progress in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *