 Test, test. There we go. Test, test. Hello? Okay. I should be expecting questions on my schedule, right? I mean, but 10 minutes is the 10 minutes of the 40, not 10 minutes of the 30. Okay, in that 30 minutes you'll show me the 10 minutes sign. Yeah. Where's my scarf? Bob, Bob, brilliant. Just, you can just say Bob. Welcome, everyone. And here's three posters for you if you want. And please, when you come during the presentation, please close the door as quietly as possible. If you want, evaluate decisions on this link. And please tweet about this conference. Please close the door. About the conference. And please write a blog post about the conference. And I should promote Grand Finale today at 16.30 at the D105. You can win some great things. And now please welcome new presenter, Robert Ralea, and his presentation about quantum crypt on thing. Hello, I'm Bob Ralea, and I work in the security group in Red Hat Mountain View. And I'm going to talk about what we're going to do when the quantum computer apocalypse hits on us. So what I'm going to talk about today, I'm going to explain some quantum computer basics. We're going to explain how quantum computers can attack crypto systems. Then we're going to talk about the current state of quantum computers. And then I'm going to survey those algorithms that will survive. We're calling those the post-quantum crypto algorithms. So they don't run on quantum computers, they run on a regular computer. What I'm not going to talk about is I'm not going to get into the math behind quantum computer cryptos and how it does the attacks. And I'm not going to go into enough detail on these post-quantum crypto algorithms that you'll be able to implement them, but only just a basic overview. So quantum computers basically use entangled elementary particles to solve brute force mathematical problems pretty much instantly. It uses the laws of quantum physics to be able to try all the possible solutions to a problem basically at once. If there's more than one solution to the problem, then the quantum rules will say the probabilities of which answers will be returned and it could return different answers on different runs. But crypto problems basically have unique solutions and therefore they're actually perfectly targeted, quantum computers perfectly targeted for solving crypto problems. But quantum computers do have some limits. Quantum computers are based on gates, they aren't based on running a program like we're used to. So for instance there's not loops or iterations in the quantum computer. You can't build a quantum computer to do AES and then drop the quantum input in. So they can't be used directly against our crypto algorithms. Instead there are additional algorithms that can then be used to attack our actual crypto algorithms. Quantum computers are also all or nothing. If you have an 8-bit quantum computer, you can't get a little bit of advantage in trying to break a large key. You need to have the full size bit in order to be able to get the advantage of being able to try all those combinations. So quantum computers can break our crypto systems. Our public key systems are particularly vulnerable. There is a quantum algorithm called Quantum 4A Transform and that can be used to solve the hidden subgroup problem. These labels are sort of important because the hidden subgroup problem is the underlying problem that's actually common between RSA, DH, DSA and ECC. You may not realize but these were actually all underneath the covers can be reduced to this particular problem. That means quantum computers can break completely those algorithms. The QFT requires more QU bits than the key attack so the size of quantum computer will have to be bigger than the actual key sizes for these algorithms. But once that happens the algorithm is completely broken. There's another quantum algorithm called Grover's algorithm. This also uses QFT and it solves the generalized search problem. That is given some function, given the output of that function, find the input that produced that output. That's basically our hash functions and symmetric algorithms. Fortunately Grover's algorithm doesn't completely break them. It just reduces their strength so we'll have to double the key sizes to get the same strength that we had before. But the algorithms themselves aren't broken. What have quantum computers actually been able to demonstrate to date? It's really not that impressive. We can factor numbers that are trivial to factor normally. Where it says shore algorithm, shore is a special case of the quantum 4A transform. The interesting things are these last two here where the sizes are starting to get large and the algorithm isn't QFT but a minimization function. I'm going to talk about that a little later in the talk. Google's been using quantum computers and recently published a paper on how they are getting actual speed ups by using the quantum computers. It's not just running classically. Just this week during the talk the NSA is published a paper. Basically it's a call to action saying that we need to start replacing our algorithms to ensure quantum computers don't break them. TOR has also been interested in the dangers of quantum computers and they are moving towards using one of the post-quantum algorithms in their network. They're worried about people recording the sessions and then waiting for quantum computers to come along to be able to break those sessions. Are we in immediate trouble? Researchers can factor a 16-bit number in something as small as 4QU bits of a quantum computer which is pretty small. On the other hand this is a special case. The factors only differ by two bits and we knew they differed by two bits. The big question here is will we be able to expand that particular attack to the more generalized case of the RSA keys? D-Wave builds a commercial quantum computer that's quite large. A thousand QU bits. But it's a very special purpose one. It cannot do QFT. It's not a general purpose quantum computer. It can only solve the minimization problem. On the other hand minimization problem is exactly that problem that we used above to solve the 16-bit number. So it is something we still need to look at. As I mentioned before Google announced that there are getting speed-ups from their quantum computers. They have a D-Wave computer but their speed-ups are only two to the eighth not two to the hundred thousand. So there's still some coherence issues in those large quantum computers where you're not getting the full benefit of all those quantum bits. Researchers expect QFTs within the next ten years. It's probably optimistic. We might actually see it sooner. Optimistic meaning we hope it's longer because if we want a crypto system it's the last longer. But people who secure data for a long time already need to start worrying about this. This is why you see both the NSA and Tor two organizations that couldn't be more different from each other worried about this same problem. The last thing is small key sizes that is ECC are likely to fall first. Okay, so what are these new algorithms that are out there? They're not really new but what are those algorithms out there that will survive quantum crypto that we can replace our public key systems with? So the first one I will explain a little more completely because it's actually quite simple. It's called hash-based encryption and it works on a fairly simple principle that you can't reverse a hash. So create a public key. You pick the size of the thing you want to sign. So usually that's the hash output of the hash function from the signing operation. And you create a vector of a bunch of random numbers that you generate. Those random numbers one represents a zero bit, one represents a one bit and then you have one for every bit in the thing that you want to sign. And then the size of those are the base hash function you're using for signing. Then you hash those and produce your public key. So the public key is the hash of those secret values that you generated on the fly. Then to sign something you simply publish that private value that you had for each of the bits in the signature. So for bit one if it's one you publish x1 of zero and if it's zero you publish x1 of one and if it's zero you publish x1 of zero. And you do that for each of those bits. And in the verify all you have, the verifier all he has to do is walk through and hash what you produced and make sure it matches the corresponding bits in that public key. Now there is a fairly obvious limitation here. I've just published half of my private key. That means if I try to sign again I'm going to publish more of it and now the private key is out and people can use it. So this is a one-time signature. Once you've used the private public key you can't use it again. This is pretty much a very strong limitation being we'll use in our crypto systems. But this has been around since 1975. So we invented Merkel trees exactly to solve this problem. So what you do with the Merkel tree is you generate two to the n where n is like 32 bits. So you have two to the n signing operations you can do on this key now. So you have one for each time you want to sign. You go ahead and generate all your private keys and then build the public keys from them. And then you hash all the public keys. And so you have a hash for each of those public keys and then they come up and you take each pair and hash them again to the next node. And then you hash each node to the next node and you continue to do that till you get a single node at the top. That top node becomes your public key. And then when you sign something you go ahead and publish your signature and you publish the actual public key for that signature. And you publish the hash of the one next to it and up the chain. So if you use two to 32 there'll be 30 of these things plus the public key. And then the verifier can construct all the hashes and verify that it matches your top hash so he knows that that public key fit this infrastructure. And if you generate your private keys using a PRNG with a specific seed you can keep that seed and regenerate them. So with very little storage you actually can get two to the 32 or 64 however many of these you want to generate, signing operations on that key. So hash-based encryptions. The key sizes are large. For shot 256 the key size is roughly, not roughly exactly, 16 kilobytes and it's single use. If you use Merkle-based the public key is much smaller but the signatures are still two to the 16 plus a little bit more, I mean 16 kilobytes plus a little bit more. And then the signing operation is fairly expensive because you've got to regenerate that whole tree again or you have to store that whole tree then it's expensive in storage not in CPU. This is only a signing algorithm that does not give you key exchange but it's not patent-encumbered. Okay code-based crypto. The idea of code-based crypto is to use error correction systems to be able to do some encryption. So you pick a matrix that introduces some error correction code into a vector and then you create a function that will correct any errors that come back based on that matrix. You pick some invertible matrixes S and P to scramble the bits in G so that the attacker can't actually generate DG himself. And then your public key is simply the matrix multiply of all those matrices. And your private key is the inverse of those matrices you use plus the error correction function. And then to encrypt you take your message multiply it by the error correction matrix and then add some error to it. And that's your ciphertext. And then to decrypt you simply pull out P and then run it through your error correction code and correct the error that you introduced or remove the error that you introduced and then remove the rest of the matrix to get your message. Okay the original scheme that was proposed in 1975 used Gopah or Gopah correction error codes and they seem secure. Other codes have been used with this system and they have been broken. This provides encryption so you can do it for key exchange. A signing system that was originally introduced was actually broken. There's a new signing system that was introduced in 2001 which seemed secure. The key sizes are fairly large so for 61 bits of what we currently call 61 bits of strength it takes 72 kilobytes for the public key. The encryption is not patent encumbered because it was published in 1975. I do not know whether or not there's patents covering the signing. Lattice space. This is one that's got a fair amount of interest because one of the algorithms that has actually been implemented and used is Lattice space function. Lattice are uniform sets of points in space and in dimensional space and they're generated from a set of vectors called the base. And there's two hard problems in Lattice space. One is finding the smallest vector that's in the lattice and the other one is finding the distance between an arbitrary vector that's not in the lattice with a vector that's in the lattice. Some bases make these, just like you would expect, some bases make these hard problems actually easy and these are called easy bases. Others makes it difficult and to transfer from one base to another is a well-known problem in the lattice space and they're considered equivalent lattices. So your public key, your private key becomes the easy base, your public key becomes a hard base. And then there's a number of proposals for how you make these problems turn into a crypto system. I won't go through the specifics of any of them, but here's some of the three-lettered acronyms for the different systems. The original one that was proposed for Lattice, the GGH, is the simplest but it's already been broken. NTRU is the one that actually, there's actually standards on this, there's implementations, it's being used today on the web. It appears to be practical, it has key sizes about the same as RSA, but it doesn't have any security proofs and it is patent encumbered. LWE has provable security but it has megabyte size, key sizes. Lattice space has been around initially since the end of the 20th century. It supports both encryption and signing and there's still research needed to get confidence that lattice-based systems are actually quantum safe or even safe against classical attacks as well. So like GGH has been broken from a classical sense. Multi-variant base crypto. These are based on the hardness of solving non-linear equations in finite fields. So your public key PX is a set of quadratic equations and it's constructed from a bunch of mapping functions. Your private key is those mapping functions that were used to construct P of X. Your encryption is you pass your message in to your set of quadratics and outcomes crypto text. To decrypt you apply the inverse of those mapping functions to C and you wind up with M. Now there's several schemes proposed how these mapping functions work and the parameters for that. Key sizes vary. The smallest for an 80-bit key strength is 22 kilobytes. These have also been proposed since the end of the 20th century. They support both signing and encryption and they also need more research to have confidence whether or not these systems really are secure. So in conclusion, quantum computers are looking more real every day. Our traditional ciphers look like traditional public key ciphers look like they're ready to fall. The high-bit size RSA, DSA and DH will hold off quantum computers before ECC because the quantum computers have to get to the size to be able to factor those large numbers. The caveat is if we ever get direct factoring algorithms from quantum computers using minimization, RSA may become vulnerable soon. So hold off on your rapid conversion to ECC that we told you to do two years ago. Or I told you to do two years ago in my talk two years ago. And if you're in crypto, you need to start studying lattice, multivariate quadratics and air-code systems. We also need to start looking at our protocols. It looks like we're going to have to start handling these very large key sizes in our protocols for going to get through this in a soon period, especially since the systems that look like they will hold, that we don't need more research on are all basically large key size systems. And that's it. Feedback is on here and I'm open for questions now. Yes? On what? That's right. The reason they went back on... I'm sorry. Recently the NSA went back on their suite B recommendations and the reason for that is exactly here. They're expecting ECC to fall because ECC has smaller bit sizes. So the first quantum computers that will likely break a crypto system will be a smaller one that will break ECC, not one that will break RSA or ECDSA. So what they've recommended is hold off on implementing ECC, continue to use RSA and DSA and crank up those bit sizes as much as possible because the larger the bit size, the longer it takes before we have a quantum computer that has enough bits to be able to break the larger bit sizes. There are no... I'm sorry. Thank you. The question is, are there any current moves to standardize systems with these larger key sizes? The answer is there currently isn't. It's something I think people have now sort of gotten flat footed on, but I would expect to see in the next year people start having proposals. And I think some of the people in this room should probably be driving some of those proposals. Yes, Steve? Okay, thanks. I was going to say that I was speaking to the technical director of the cryptographic module validation program and he said that they're going to move to 4096, 8192, and 16440 sized keys in the very near future to put this off. So we'll probably be seeing that in the next round of standards coming out in this. Yes, Sima? Is there any quantum-based crypto that is being also explored to use the quantum map? There is quantum-based schemes, but those schemes obviously require quantum computers and they don't really have key exchanges. What your key is is a quantum particle that you've exchanged back and forth. We're not looking at that to solve these problems because quantum computers are going to be available before they're going to be generally available to people, so we need to be able to live through that period. Yeah. Okay, thank you for your presentation. If I got some point correctly, you said that the quantum computer to be successful, it needs to have a lot of quabbits. I'm sorry, what was the question? The quantum computer to be successful, to decrypt something, it needs to have a lot of quabbits. Yes, it needs to have a number of qubits in order to solve it. The first one that breaks something like EC256 is going to need to be bigger than 256 because the QFT requires something larger than what you're actually attacking. My question would be how difficult are qubits? Would it be a question of money or technology? So we can only go by what sort of the people in research are saying. They're having problems as you get more and more qubits trying to keep the air and trying to keep them coherent, and you can see that with the D-Wave, even though they have 1,000 qubits in a non-general purpose, they're not able to use that whole 1,000 qubits in their system. Otherwise, Google would be getting much larger speed-ups than they're actually seeing. So it's not known how long it's going to take. You saw the quantum computers that actually did work are all very, very small. They're 8 qubits for something general. Steve was just telling me the other day that some people have actually generated some quantum gates, and once those start coming into place, we might start seeing more of these and actually see things built to do generalize the QFT. Okay, thank you. So you didn't really mention symmetric algorithms and how they are vulnerable or not vulnerable to quantum computers? There was a very quick slide on symmetric. The effect on symmetric is the same as the effect on hashes, which is we have to double our key sizes because the Grover algorithm is a general case algorithm. It doesn't really matter what the underlying crypto is. It's a generalized search algorithm, and it can actually come up and be able to come out with output based on input in a much quicker way than we used to be able to do with our normal search algorithms. So it's going to be really great if you're a database search thing because your speed-ups will be amazing, but it also means that our crypto systems are inherently going to need to use twice as many bits to be just as secure as they used to be. You mentioned you're not looking at quantum-based distribution systems, but the quantum telecommunications research is moving actually at an even faster pace than the quantum computing itself. There are even commercially available solutions already from companies like Quantique for the private keys distribution where you use the quantum entanglement and the statistics associated with it to detect eavesdropping. So you could essentially guarantee the private nature of those distributed keys. Why is this not being looked into? It's because the systems that we're trying to secure don't fit that model. We're talking about what happens when you encrypt on your disk, what happens in a normal person, and also we need to have these algorithms running today because the data that we're trying to secure, we want to be secure 10 years from now when quantum computers come out. So we basically need systems that run on classical systems. Quantum encryption is interesting, and I'm sure we'll have to add it to some of our systems, but the fact is we're still working on classical computers and will be for quite some time, and we need systems that run on classical computers and are safe against quantum computers. Hello. I have a question. There is an encryption technique called one-time path, and it basically says that you generate random data and absorb it with your message. The only problem is the distribution of the keys. Is this vulnerable to quantum computers or not? I think it's not, but... One-time pads are one of those rare cases where if it really is a one-time pad, it's provably secure because there is no way of determining what the key bits are. You can pick any ciphertext you want and find a set of bits that will produce that ciphertext output. Therefore, there's no way to actually attack a truly one-time pad. The problem is one-time pads are notoriously difficult, and we don't actually implement them in any of our systems. Hello. The idea is that we need more Q-bits than bits, only in the case of QFT algorithm. Has it been proved that this is the best case ever? In general, is there the chance that any other algorithm will be able to be better than this? No, it has not been proved. Even worse, it's not been proved that these quantum-safe algorithms are quantum-safe. That's why we're needing more research. It's just that we today don't know any quantum algorithms that can break the ones that we've given. But if you look at the table of the kinds of things that have been broken by quantum computers, things like lattice looks dangerous because they're in that set of everything around it's broken, but not them. That's part of the reason that the NSA isn't jumping on Intrude. The other problem is that Intrude was patent encumbered. They went that way with ECC and know what headache said is. But I think part of it is they're not sure that tomorrow somebody's not going to publish a paper on how you can break Intrude with a quantum computer. So there are no proofs yet regarding these algorithms? There's security proofs, but there's no proofs that say the hard problem is not solvable on quantum computers. There's no algorithm that has that. I think I'm over time. So this is the last one, Thomas. Okay, this is not a question, but some kind of advertisement. If you want to see something also interesting as Bob's presentation, there was a very nice presentation on post-quantum crypto in Kaos Computer Congress, 32C3, and it's recorded. It's a presentation by Daniel Bernstein and Daniel Ang. And they showed very nicely how, for example, hashing trees work and so on. Okay, thank you, everyone. If you have any more questions, you can grab me afterwards. Or Steve. One minute. I showed who does it lose. Yeah, if you have all something it requires, 201 bits. You don't get any quantum, you don't get anything. So that's why cranking level... Nice. Yeah. I spent all the time with wheels. My part of the slide. Okay. Testing, testing. Can everybody hear me? Yeah.