A – If you can, overnight, switch to a quantum-resistant code, and if you don’t have to provide long-term security, then yes, you can wait and see. But in most applications they are not ready for that change; they don’t know what the replacement would be and it takes years and years, even decades, to deploy them.

So, if it’s going to take you decades to deploy a quantum-resistant alternative, then you’d better hope you don’t have quantum computers within that time.

But it’s not just that. For some people, their security guarantee is just a few seconds. Like, if somebody is just authenticating your identity to me, they just do it now and once it’s done, it’s over; you’re not concerned about somebody breaking that code in the future, because who cares? It’s done.

But, in other cases, you need that information to be secure for a year, 10 years, and in some cases 100 years. For example, with health information, people really do want their information to be private as long as they live, if not longer.

If you need to provide decades of security, you’re already being reckless if you’re not switching over to quantum-resistant tools.

There’s no way you’re guaranteeing that we’re not going to have quantum computers for decades. How many years will it take you to switch to something that’s secure? Changing the infrastructure takes years. So that’s why we can’t wait.

Q – What are the main threats to the predominant cryptography systems in use today?

A –I like to partition information security into three pillars. One is trust; you have to trust your IT administrator, you have to trust your certificate authority; your browser has all these certificates on them.

When you open an e-mail from somebody, assuming it was from them, you trust them enough to open up that e-mail, because if you open it and run their software you might install some kind of worm or virus on your system.

You can encrypt your private data with an unbreakable code and send it to somebody and it goes to that right person, but if they’re not trustworthy, then your privacy’s gone.

Second, there’s physical security. I can have an unbreakable code, I can have it in the house of somebody I trust, but then if people can just look in the window and look at my screen – I mean, you always have to have some physical space that you’re assuming is not being accessed by adversaries.

The third pillar is cryptographic systems. These are mathematical tools that allow you to scramble information, and once it’s scrambled, you can take it out of this physical safe haven, put it out into the cloud where you assume anybody can look at it, and yet it’s still protected. That’s an amazing thing.

And you can have access structures, where only people who can prove their credentials can access the information; only the doctors in hospitals or whoever can access that information.

I could keep it locked in my basement, but then nobody can access it, so you want to make it accessible to only the right people. And that’s where cryptography becomes critical.

These three things, together, can achieve something that the other two can’t do on their own.

I would say the predominant threats today, in practice, would be bad trust assumptions and user errors.

Probably the next predominant threat is bad implementation. We might have an unbreakable protocol or a good system in theory, and then you go implement it and you might take some shortcuts, or you just might make a mistake, or your physical security is just not up to snuff.

Any new system will have something that somebody overlooked, so it takes a few years of people attacking the physical device and realizing, ‘Oh, look, there’s a side channel,’ or that your screens radiate information and you have to lower the intensity of the radiation so you’re not giving away secrets unintentionally.

Then there are bad protocols. And it’s hard; you start getting these really complicated multi-party protocols, and how do you prove they’re secure? You prove they’re secure in some abstract, idealized model, but does it capture the essence of the real protocol? Sometimes yes, sometimes no.

In recent weeks there’s been another break through SSL (Secure Sockets Layer) and so on, where there was a protocol flaw. You can look back and say ‘it shouldn’t have been there,’ but it was.

Sort of at the bottom of the list now is bad cryptography, or breaking an actual cryptographic primitive. A primitive is a very fundamental tool, like an encryption function, or an authentication code. It’s a way of taking a message, plus your identity, and putting a small signature which people use to verify that that message was really sent by you. These types of primitives are then used in a more complicated system or protocol.

When you authenticate yourself to Amazon, you’re gluing together all sorts of little cryptographic primitives.

Occasionally, people break the actual primitive, but today, the real practical problems that security experts will tell you about are these higher-level things that don’t have to do with cryptography.

So, that’s one of the reasons they don’t pay a lot of attention to the cryptography layer that we’ve been talking about. It’s because today, it’s sort of the least of their worries.

We’re trying to get on their radar screen and say, ‘Look, the whole infrastructure’s built; cryptography is not just some esoteric part of the infrastructure.’

continue reading…