 Daniel Lange and TGB, or Daniel Bernstein, came from the Elliptic Curve. I'm going to talk today also about the McElie's Crypto, where they took us. They're both in the steering committee for the PQ Crypt, and I've talked to other people in the community, and they said, especially about Tanya, she's the one that brings practice and reality into all this theoretical mass stuff. So let's please have full hand for Daniel Lange and Daniel Bernstein. Okay, am I on? Apparently I'm. Welcome to the Late Night Show with Dan and Tanya. There's a lot of crypto talks out there where you'll get the idea that crypto has problems. Crypto has massive usability problems, has performance problems, has pitfalls for implementers, crazy complexity and implementation, stupid standards, millions of lines of unauditable code, and then all of these problems are combined into a grand unified clusterfuck called transport layer security. But actually, the situation is worse. Because of what's coming, namely quantum computers. These typical talks will give you the idea that the core of crypto, the basic cryptographic primitives like elliptic curve crypto, ECC, that those are just fine and all the problems are integration into applications. That's where the security problems happen. But quantum computers will break ECC. This has been known since the 1990s. For people who don't recognize the picture here, this is a mathematician named Peter Shore. Twenty years ago, he wrote a paper saying that a big quantum computer would be able to factor big integers in polynomial time. Now, if you like doing attacks and you hear about something like this, then your first thought is, ooh, I want a quantum computer. I want a big quantum computer so I can run this attack. And where is it? Does anybody have one? Can anybody give me one? Oh, it isn't there yet? Well, what's the progress? Are we there yet? Can I have one, please? And well, in the news, you now hear about this D-wave quantum computer, which, okay, there's some very good quantum engineering that goes into this machine. It's pretty clear that it's quantum. I mean, it's actually doing the quantum stuff they say it does. And there's some fantastic marketing in this machine. But unfortunately, it's not actually useful. So the D-wave quantum computer doesn't do the basic things that we expect a universal quantum computer to do. It can only do very limited kinds of quantum computations. It cannot maintain qubits, do error correction on qubits for a while, hold on to them to be able to do basic qubit computations. It can't even do those computations, even if it could hold on to the qubits. It can't do Schor's algorithm. It can't factor big numbers. It can't do other quantum algorithms that we care about. Now, the D-wave company says that's not the point. There's some other computations that we designed this machine to do. But they cherry-picked a computation for this machine, saying basically, here is the problem of simulating this machine, simulating the quantum thing that it's doing. And of course, the machine is very good at simulating itself by just running. It's a normal laptop. They compared to a sort of standard program on a normal laptop and the latest results 10 to the 8 times faster, except, well, there's a much more optimized program that somebody put out last year, which basically is the same speed as a D-wave machine and like 10,000 times cheaper. So the D-wave machine is not, for the moment, something useful. Well, if this makes you kind of comfortable, so no Schor monster coming, there is progress. There will be a universal quantum computer, so something that can run Schor's algorithm and there's a lot of research effort going into this. So if you track like spending on crypto and if you spend a track spending on quantum computers, that is a lot of money. There are lots of institutions and companies and, of course, governments all over the world building stuff. And we do see progress, so we're keeping track on this and, well, quoting the Wikipedia page here. So we see over the last few years a huge progress in a stability of qubits. So these things usually forget what they had. They decay, but they get more stable. There is better error correction and there is better communication. So the latest was that even silicon-based qubits can communicate. So something is happening. IBM is on the record with Mark Ketchum, who is their CEO, saying, we're actually doing the things that make us think like, well, hey, this isn't 50 years off. This is maybe just 10 or 15 years off. It's within reach. So IBM is leaning out the window and saying, yep, we're going to be there pretty damn soon. They said this in 2012. So let's fast forward by 10 to 15 years. So it's now 2022 or 2027. And so there is a universal quantum computer. The fact this has on the internet crypto is that RSA, which is still the majority of all your connections to the internet. RSA is broken. RSA is dead. Discrete log and find fields. You might have heard a lot about it earlier this year about logjam. But logjam just breaks the very small one. This is breaking any big one. So discrete log and find fields is totally dead as well. Elliptic curves then already mentioned, ECC is dead. So this breaks all public key crypto on the internet. There's another algorithm to do to Grover, which is somewhat better under control, somewhat less scary for crypto. But it still has quite an effect. So if you believe in the security of AS and go like, well, AS128 seems just fine, has been not getting any big progress in crypto analysis. But it halves the security. So AS128 bits keys are only 64 bits secure. However, you can go to 256 bits. Okay, so the AS situation not so bad, but all this public key stuff is broken. So what do we do? Well, you could bury your head in the sand. You could hope that quantum computers don't come along. You could deploy physically secure crypto. You could take a locked briefcase and chain it to your wrist, or you could do quantum key distribution. Now these things obviously are very, very expensive. This is crypto information protection for rich people. Or quantum key distribution is crypto for even richer people. You obviously aren't going to be able to democratically give this to everybody who has a laptop. But well, okay, imagine that you have enough money that you don't mind this. There's a bigger problem with physical cryptography, which is the security. Now these things are always advertised as provably secure, guaranteed secure. Nobody can get into this briefcase. Nobody can get into this quantum key distribution system, assuming of course, blah, blah, blah. And then you look at the assumptions and you start saying, wait a minute, is that actually true? And then it turns out that when people try attacking these systems, the assumptions are not true. And the systems get broken again and again and again for very reasonable attack costs. Okay, even if you have a system where you think it's secure, which nobody's managed to build yet, even if you had that, the design of these physical security systems is incredibly difficult to audit. And it's something where if somebody wants to slip in a backdoor, it's really easy. But there's an even worse problem with physical cryptography, which is that it doesn't do very much crypto. Typically, these systems do about the same thing that AES does. You start with a shared secret, and then from that shared secret, you can authenticate more secrets that you transmit through this physically secure communications mechanism. For instance, quantum key distribution starts with some way, some pre-existing way of authenticating. But that's just like AES starts with a secret key, which you then use to generate more and more secret data. And quantum key distribution says, well, it's provably secure under certain assumptions, instead of AES, which, well, we just heard AES is maybe a little affected by quantum computers, but AES 256 is not broken. Nobody has any idea how to break it. So this physical cryptography isn't actually serving the needs that we want. Imagine trying to distribute operating system updates through locked briefcases. It's just not going to happen. Microsoft is sending out billions of locked briefcases to all of its customers. If you think that's realistic, or if you think that just lasers are cool, then there's a talk about quantum crypto tomorrow, I believe. Back in the real world, we obviously need to do something better with crypto. All right, so let me take a momentarily slightly more optimistic perspective. Is there any hope? Yes. So the title of this talk, the next comes from post-quantum crypto, and that's the term that Dan coined back in 2003, for crypto that remains secure even if the adversary has a quantum computer. So you, the normal people, me, him, the normal people, the internet, all the connections, we have normal computers. The adversary has a quantum computer. We today encrypt something the adversary has all the time in the world to build the quantum computer, break us now, break us in the future. So I took off, and there's been the first workshop on post-quantum crypto called P-Crypto in 2006, and then there's been a series of workshops you can see here. This is the attendees of the last edition, which was in Waterloo. It's more than 100 people going, like, yes, this is an important topic. Let's do some research on it. So something is happening. If you're curious what's happening next, there's a workshop in Japan in February, and then in the Netherlands in 2017. And we also got a project through from the EU to support research on post-quantum. So something is happening. Actually, did I forget somebody? Yes. The NSA is also saying, let's do something. So on August 11, the NSA posted on their Suite B page saying the Information Assurance Directorate, so IID recognizes that there will be a move in the not-distant future to a quantum-resistant algorithm suite. Oh, my God, somebody is doing something. The public has realized we have to do something. Quick, quick, let's put out a press release. Looks like they kind of realized it was embarrassing. So eight days later, they put out a new release saying IID will initiate a transition to quantum-resistant algorithms in the not-distant future. So NSA will lead us to a bright and glorious future. America, fuck yeah. But if you thought that so far this was bad, it actually takes a lot of time to build crypto. Whether it's the NSA or us, the researchers, if you have some idea of what could be secure against a quantum computer, say AS-256, the reason that we have confidence in it is that we had more than 10 years of people trying to break it, trying all kinds of approaches and not getting anywhere. It takes a lot of time to explore the space of crypto systems. Once you have figured out what could be actually doable, you want to figure out what the best attacks are. You want to focus on the secure systems. You want to figure out how to implement them securely. There's a whole lot of work that needs to be done before you can say, well, this is actually practical. We can actually use this. Or sometimes this is as practical as we can get it. And then you have this tiny little crypto primitive. And then you have to build the hooks and connections to get it into TLS. Then we're saying at the beginning that, well, maybe you believe that the cute little crypto cores are all secure and it's just the connections with the TLS and other world. That is a problem. That still needs to be done for post-quantum as well. And there are side-channel attacks. There's, as an example, ECC was introduced back in 1985. And now 30 years later, we're seeing that ECC is actually getting deployed on the internet. There's now the ITF having calls for having other elliptic crypto because people start saying, yes, we would like to use this. So we cannot wait till there's a quantum computer in order to start research on it. If you remember what 85 looked like, that's a while ago. Now, if that sounded bad, it's actually worse. It's not just that in 15 years from now, whatever you send then will be broken. There's some indication that some entities might be recording your traffic. We're given a talk like this in 2012, which was crypto feather paranoid that everybody in the audience was like, you're crazy. Now it's like, well, there might be an entity and everybody goes like, yeah. So let's assume that this entity has a record of audio connections. And that in 10 years, you're gonna be an interesting person. Maybe you're a politician. Maybe you've become rich. Maybe you've associated with the wrong people, or so they think. And so suddenly they go back to the 27th of December 2015 and figure out what you were e-mailing during the talks because they have all the connection data. So they can go back in time just by the metadata and of course the real data. From the metadata, they can decrypt it because this metadata is using RSA or ECC, which are broken. And then they get the same key that you're currently using with your other side to communicate. And so they can go and decrypt this. So it's not only that we can't wait for quantum computers to come. We might already be too late. Well, on the next slide, here's a bunch of people who are getting together in this EU project and we have come up with what we currently thinking are good recommendations. We think it's necessary for people who really care about the security of the connections. And when I say people, I include myself, I care about the security of my connections. We would like to have something that we believe is secure for the next 100 years. And so we put out a list of recommendations. So for symmetric, it's relatively easy. You want something which has at least the 256-bit key and is sufficiently well understood. So there we have Salsa20 and we have AS256. Then for authentication in symmetric, there we don't actually have any decrease from a quantum computer because these are already information that is secure. So these are the nice part. These two top items is where we go like, we might be okay on those. We can do better. We can have nice research and get something which is even better protected, even faster under the new scenarios, but it's not so dire. The bottom two, these are the public key systems. That's public key encryption and public key signatures. And that's what we're going to focus on in this talk. So for public key encryption, we're recommending the McLeese crypto system with copper codes for a certain parameter size. And then for signatures, the recommendation is to use hash-based. Okay, so let me dive into the hash-based part of this. This is something which goes back to the 1970s. Lamport said, here's a way to use hashes to do one-time signatures, which we'll see in a few-minute signatures that you can use to sign one message under a given key. And then, well, that's a little bit inconvenient that you can't sign more messages. So then Merkel came along and said you can sign more messages by modifying the system. And we'll also take a look at that. The only thing you need for these public key signature systems is a good hash function. And okay, that's something where historically some hash functions designed in, like, 1991 had trouble, but now we have some good hash functions. So, for instance, SHA-3 has some great hash functions, even SHA-2, there's no sign of trouble of those things being broken. And then after these original systems from Lamport and Merkel, there's lots and lots of improvements, but all of these hash-based systems, it's really easy to understand the security. It's something where the basic idea is really, really simple and the security analysis also ends up being very straightforward. You have to be careful about some things, but when you're careful about those, and there's nothing subtle about it, nothing tricky, and we understand exactly what security we get from these. So let's dive into a signature scheme that can only sign empty messages. Now, this sounds kind of like, wait a minute, what do you mean? It can only sign empty messages. There's only one empty string, and that's the only thing you can sign. But imagine that you want to have a panic button, like your revocation key. You want to be able to say, here's a message that says, my computer's been compromised, don't trust anything from this anymore. It's this one message that you want to sign under a certain key. If anybody has that public key, then they should be able to verify that you've sent that message, and nobody should be able to forge that because it's really bad if somebody can forge your panic message. So being able to sign just one message that says, okay, let's look at some Python stuff here. Simple SHA-3 you can get online under Ubuntu or Debian to install Python PIP and Python Dev because it's a C library, actually, and then PIP install simple SHA-3. That'll give you SHA-3 256. And then to generate a key pair in this empty message signature system, all you do is you make 32 bytes of random data and just hash it again, in case uRandom is not too well reviewed. I mean, we should trust uRandom, but it's really cheap to put an extra hash on it. So that's your secret key is a 32 byte hash. And then the public key is hash that secret again. So the public key is simply a hash of the secret key. And then return the public key and the secret key. Of course, the public key will get published and the secret key you keep for yourself. As an example of doing this, well, you just get random looking data of your secret key right at the bottom and public key above that. And you can check that one of them is a hash of the other. If you know the secret key, you can hash it to get the public key. Okay, now how do you sign a message? Well, this is maybe sort of spelled out in more steps than it has to be. The API here, this is, I would say, getting to be a pretty popular API for signatures and for verification where you include the signature and the message together as a signed message. And I emphasize that there's a return signed message from the signed function. Now, the signed message will be later on verified and you get the message out of it where the only possible message to be signed is the empty string. And you can see that the top there of the signatures is checking if the message is anything other than the empty string then you're not allowed to sign it. If you have the empty string coming in, then the signature is simply your secret key. And the whole idea of hash-based crypto is that somebody can publicly check the hashes of something that you reveal to sign, in this case, the empty message. And we'll see later how you can use the same idea to sign lots more. And then, okay, verification, you simply check that signed message which is supposed to be the secret key, check its hash, and see if that matches the public key. What would somebody have to do to attack this? They would have to, if you haven't actually signed a message, the message, then they would have to figure out some string that when you hash it gives this public key. And, well, that public key, this is a pre-image problem inverting the hash function. The hash is supposed to be one way if the input were low entropy then this would be doable. But the input was a 32-byte random string so nobody will be able to guess that or find any other string that passes this. And then you return the message. And you can try this out and see that it works. All right, let's move on. We've managed to sign empty messages. How about signing 0 or 1? So now we'll make a signature system where your key can sign 0 and your key can sign 1. And, well, this is going to be kind of stupid. What you do is you make two keys, one of them is signing 0 and the other one is signing 1. You can see how complicated this hash-based signature stuff is. Okay, you put two keys together. One key that'll sign 0, one key that'll sign 1, concatenate the public keys, concatenate the secret keys, the P0 plus P1 is 0 plus S1. And then if you want to sign, then, well, if you're signing 0, now the message is being signed, your integer is now instead of the empty string. If you want to sign 0, then the signed message will be the string 0 followed by the 32-bytes, well, this is again more complicated than it has to be, but think of this as signing the empty message with the empty signature system, which is just copying the 32-bytes of the secret key. And then if you want to sign message 1, then you do that with the other 32-bytes of the secret key. And then to verify it's, well, just whether the sign message is 0 or 1, just do the obvious thing, maybe I should emphasize this code was written in just for this talk. It has not been reviewed, and you should audit everything. You might feel like six lines of code, you can't possibly screw it up, you can't use code like that in crypto. So this is just to understand what the system is doing. This has not passed review, but I like to think it would pass review. Okay, and if you try signing the 1 message, for example, and take the signed 1 message and open that signed message, you do get the integer 1 back. And if you try forging, you're again faced with this problem of coming up with some 32-bytes string that hashes to a particular result. So let's do the 4-bit messages. So I promise I won't do every possible length. But 4 bits, this will make an important point that you don't see from 1 bit. Let's try to sign a 4-bit message by signing each of the 4 bits. And this will scale up to signing 1,000 bits if you want. So, okay, let's make 4 signed-bit key pairs where each of those was 2 32-byte hashes. I mean, each secret key is 2 32-byte random strings that uses the hashes of those 32-byte random strings. Make 4 of those pairs and concatenate them to make some new public keys and secret keys. All right, and now to sign a message, well, you look at the message and check is it an integer between 0 and 15 and reject otherwise and then sign each bit of the message. You can see m shifted right by 0, 1, 2, 3, extract the bottom bit of each of those and then sign each of those bits and then concatenate the signatures of the 4 bits of the message. And then verification works the way you expect and I'll just skip past this. All right, this has a problem that if you use this signature system to sign 2 different messages, then you might actually allow forgeries. So, let's look, for example, suppose you sign 11 and you sign 7. Now, what is that signature of 11? Uh-oh, I have to do 11 in binary now. So, 11 sounds like 8 plus 2 plus 1 and you sign 7, which is 4 plus 2 plus 1. So, what have you revealed now? You've revealed a signature on that 8, so the third bit, you've revealed a signature saying the third bit is 1 as part of the signature of 11. But as part of the signature of 7, you've revealed you've signed a message saying the third bit is 0. And now you can just mix and match those messages, wherever the bits were different. So, for instance, if you take the top bit from the 11 and the bottom 3 bits from the 7, then you end up signing 15. So, the signature system, it's totally safe if you're signing one message, but if you think about the data flow, what does it mean to sign the individual bits of 2 different messages, then you can get in big trouble. So, this is a one-time signature system. All right, here's how Lamport's signature system works for one-time signatures of any length of message. First of all, you scale that 4 bits up to 256 bits, and then if you want to sign whatever length of message, you just hash the message to 256 bits. And the code for it is very simple. This is not quite the state of the art for one-time signatures. There's fancier things you can do. You can sign with winter knit signatures and get, instead of something like 256 or 512 hash values, you can compress that down to like 50 or even fewer hash values. There's all sorts of tricks to trade space for time in these systems, but it's totally feasible to deploy Lamport signatures. And, well, winter knit makes it even more practical. All right. What about this one-time restriction? So, these last the 4 bit and this Lamport bigger message system, these are only usable for, you can only use your key to sign one message. And this was fixed by Merkel. So, what Merkel said was, you make 8 Lamport for example, 8. It can be any number. Here's how we'll make a public key that can sign 8 different messages. You make, well, 8 different Lamport keys and you concatenate them together and you use each one just once. But it's actually more space efficient than that sounds. So, here's what you send along. You make 8 S's there. Those are the secret Lamport keys that are able to each sign one message. And then you have 8 corresponding public keys, P1 through P8 and then you hash together in a tree, you hash together P1 and P2 and P3 and P4 to form P9 and P10 and hash those together to get P13 and same over here to get a final public key, P15. So, just one hash value, that's your whole public key. And then you have to remember lots of secrets but, okay, nobody has to see those secrets. You just keep them on your computer. And now what does it look like to hash one message? Well, here's what it looks like signing the first message. That's when you use S1. And once you've used S1, you cross it out and you never use it again. You kill those secrets. You sign your message with S1 and somebody can verify it if they see the public key P1 for Lamport signatures or whatever one time signature system you put at the top. But, well, your public key and Merkel system is P15. And how does somebody verify that P1 and P15 are related? Well, you show them the P2 and the P10 and the P14 that they need to hash together with P1 to get your public key, P15. All right. And that's as complicated as the Merkel signature system gets. If you want to be able to sign a million messages and you have to have a million secrets, but, again, you just put it on your local hard drive. You're not worried about the space. It takes a few moments to generate the key, but that's also not a problem. Okay. Good things about hash-based signatures and a few bad things. Good things. It's post-quantum secure. We totally understand what hash function security looks like after quantum computers and before quantum computers. All you need is a good hash function and there's lots of hash functions which have been thoroughly studied, so we're confident they're secure. Shot 3 was a result of a long competition with lots of people bashing on it and it really has no problems. The public key is very small, just one hash value. Security, as I said, is well understood. All the computations are very fast and you can already find standard proposals for this system. This is going to be the first standardized and the first deployed post-quantum public key system. On the other hand, if you look at the signature size, it's kind of big and then the more scary thing is the statefulness that you can only use S1 once and then you have to cross it out. What if you clone your VM? What if you have a backup and restore? Oops, you've forgotten that you used S2 and then you use it again and then somebody can forge messages just like I was saying before. All right, so state is a problem. Actually, some of you, I'm sure we're in Rutkowski's talk earlier today, you also heard that state is harmful there and the solution eliminates the state. I think I only have about three minutes left for this section, while this slide, but let me try to briefly say the idea for getting rid of the state is you have, instead of signatures, you have certificate chains. So you have a whole chain of CAs, like as a signer you build a whole bunch of CAs. You build, say, two to the 256 certificate authorities. Now that's too much computation to do, but you do it on the fly as you need them. So you say, I'm going to sign one of these bottom level certificate authorities. That'll sign my actual message. And now, you don't have to know anything about any of the others. You just pick one and use that to sign your message. And then it has to be signed by the parent CA and that's signed by the next parent and so on up the tree to the top level, only 256 levels. And then, okay, you have your certificate chain. How do you manufacture these certificate authorities? Well, a certificate authority is just a whole bunch of code. So you have a whole bunch of CAs, you have a whole bunch of code on disk, that's what real CAs are like, and you do the same thing signing. And those bites of code you can instead of storing the CA as a program and a configuration file on disk, you just generate it on the fly when you need it by taking the position of the CA within this huge tree and then hashing that together with some long-term secret. That one is going to have some huge tree and have them sign certificates for each other only looking at a few CAs that you need for the particular signature that you want. And the reason for having this big tree is that then you're never going to randomly use the same CAs at the bottom twice. So the problem of having one-time signatures is no longer a problem. Each CA will only sign one message. Okay, and this is something where the original proposal from the CAs, if you use good one-time signatures, winter nits and all that stuff, you get something like 0.6 megs for a signature. Now that's a little bit inconvenient. For comparison, if you do an OS update, you look at the average Debian package size, then it's 1.2 megs. And then there's some number of signatures with each update and some number of packages. It's not inconceivable to send 0.6 megs for each one-time signature. And then if you look at, well, web pages, say the Alexa top million web page, that average is 1.8 megs. And again, there's several signatures on a web page depending how many sites are providing graphics for it and so on. So 0.6 megs is maybe a problem. But okay, we took a look at this and a bunch of people made the signatures a lot smaller. 0.041 megabytes. Signature sounds small. Only 0.041 megabytes for a Sphinx. 2 to the 128 post quantum secure signature system. If you're interested in more about what Sphinx does, go to Sphinx.cr.yp.to. All right. So now we have some idea of how we can do signatures. And signatures is the thing that quantum crypto really, really can't do. I mean, also log briefcases, how do you trust that this is actually your log briefcase? But also public key crypto is a problem. So the one that we recommend is code-based cryptography and code in this context is not like code as in writing a program, but it comes from error correcting codes. So when you think about, say, your computer you have RAM in there and this RAM might get cosmic radiation or just a bump somewhere, might forget something. Or more trivially you can't do that. So you can't do that. So you can't do that. For example, if you order a book or nowadays order any media and has an ISBN number, this last digit is dependent on the previous digits. So they can figure out whether any of the digits before was mistransmitted. And then they go like, hm, that number doesn't exist, try again. With your ECC RAM it's actually 64 bits. But it stores these 64 bits with some redundancy. Internally it has some extra check bits. It stores eight extra bits. And those eight extra bits allow you to recover the 64 that you're interested in in case there was some error. Not in case of a massive error, not in case somebody took a screwdriver and hit it, but if there was just one random bit flip you can recover it. So you can at least figure out that there was something and raise a flag. So the common scenario in error correction is that we have a certain number, say K bits that we care about. And then in order to be able to recover those, to correct those, we add some redundancy. So we encapsulate, we encode those K bits into N bits. Now we would like to have those N bits being too much larger than K. We call those the parity check. So this is like from the old days where you check those two add up to 0, 0, 0, 0, 0, 0. Oops, there's one. There must have been one bit flip. So parity as in it has to be an even number at the end. If you're talking about more positions then it's obviously more than just the parity, but it's parity of some more complicated equations. So if no error occurred, if those 64 bits in your ECC RAM are just fine, then all those extra N minus K checks will be okay. If there was an error, then something will fail, raise the flag 1, 2, 3 of those will not be satisfied and depend on this error pattern. You will be able to recover what was going on wrong in those bits. It might actually be that it was your parity check bits. It might be that one of those 8 extra bits flipped. In which case your 64 bits were just fine. But you don't know this when you get the error message. And if you have a good code, so the kind of code that coding theorists study, then you would like to have your K pretty large, the N not too much larger. Because that's the amount of storage you actually have to afford for just getting this much data out of it. Now we get some guarantees when we design these. There's a guarantee of getting T errors. But for most of the codes that we know, the guarantees are actually worse than we can get in practice. So if something guarantees you 100 errors, most of the time you can actually correct 100, 203. To get a little bit further, we actually need to represent those equations with matrix. Well, not quite this one. Sorry. So here's our equations. So small example, we would like to encode four bits, KS 4, and we're adding three extra bits. That's not very efficient, but it's a very nice example that one can see. So those rows there are our parity equations. So let's assume we have those seven bits which add redundancy to it, then let's translate this first row which is 1, 0, 0, 1, 1, 0, 1. That means we take the first bit, skip the second and third, so have B 0, and then B 3, then the next bit is set, so B 4, and then B 6. Second row similarly, we skip the first one, so there's no B 0, there's a B 1, no B 2, there's a B 3, it was a 1, 1, 0 column, and then B 5 and B 6, and similarly. We have a nice diagonal on the left-hand side, and then the rest is determined by these equations. Now let's assume that something went wrong. So we have our seven bits here and a few hours later we come back and want to look at those seven bits. We check whether anything went wrong, we run them through this parity check program, and we actually get a failure pattern. If everything was fine, we would have gotten 0, 0, 0, but we're getting 1, 0, 1. So the first equation doesn't hold, the second one does hold, and the third one does not hold. Okay. Where could this come from? We're pretty sure that B 1 is okay because otherwise the second equation would be wrong because B 1 only appears there, and we're also making the promise that it will be only one error. If you have two errors, three errors, the other combinations could occur, but it's much more likely that one bit flipped than that a whole bunch of bits flipped at once. Okay. So tracing this a little bit further, yes, so the B 3 would get the first equation B 4. Yes, B 4 actually would get that the first and the third equation are false. So by seeing the error pattern 101, we know it was B 4. Now this is a very nice and small example which doesn't even cover like the ECC RAM, but it's just an idea of how to try it. On the other hand, it also gives you the idea that you need to do kind of brute force search it. So for just n equals 7, you have to try up to 7 times. If you now have two errors, I would need to try every combination of 2 out of those n. If I have a n which is like 2,000 bits, read it long, and I tell you there's 100 errors. So you would need to try every combination of 100 positions in there. So that would be a huge number. That's obviously not a good way of error correction and that's certainly not how DVDs and whatever else works. Oh yeah, one bit of math notation. So we call these things apprentices up there matrix and in order to have a shorthand because I can't quite put my 2,000 bits times 5 times 1,000 bits matrix on the page I call this thing H and boldface B is such a bit vector. So boldface B is my bits that I'm storing and the combination of applying this matrix wherever it is 1, I take the variable, wherever it is 0, I don't write it. That I write as 8 times B. So in math if you have seen this, this is just the matrix times vector multiplication, otherwise just take this as the combination of evaluating this each row as a set of equations. All right, so to give you some names and coding we call C the code word. So that's an element which is not compromised, which will give you 0. Then there might be an error vector that's the bits that flip and so when we retrieve the memory or when we have a transmission we call this the received word and that might be from the previous slide. We do like to save on space so when there is this diagonal which has all zeros down there we just skip it. So instead of writing as 7 by 3 we just write 4 columns and 3 rows. Now there's lots of stuff happening in coding theory, it's a 65 years old topic and we can go up to very large matrices and for some special codes these are the ones that coding theories come up with we actually have efficient methods much nicer than taking every combination of 100 positions out of 2000 positions. Of course if you get too many errors you can't correct you can only correct up to whatever the promise is plus maybe a little bit later but if you don't know any of the structure if you don't know what the coding theories put into it or if this H matrix gets somewhat pertubed by me giving you slightly different representation oh I don't call this B1 anymore I call it now B17 and let's flip those and so on suddenly it doesn't look like the code that you're used to if it's a random matrix the best attacks are not quite as bad as picking 100 out of 2000 but there are close to that, they're pretty slow attacks it's an exponential time algorithm if you have a random matrix and so what we're doing in code-based crypto is to use this difference for encryption now going back again to the 70s so basically yes the stuff that we're really confident in that it will last another 100 years is the stuff from the 70s that lots of people have looked at so Macalese in 1978 so just a year after RSA came up with a system which is using encoding as encryption so your method is you just encode a vector your message and then you add some errors to it and if the other side doesn't have an efficient algorithm to decode they actually can't break it they're using a special code in there so there's a code from GOPA from a few years earlier than that and that code so far nobody has found any way to take the per tube this complicated way of representing it and coming up with the efficient decoding algorithm in 1986 Niederheider came up with a version of Macalese which is smaller the code size is smaller the public key size is smaller and we have a similar thing to what you've seen before so we have this H matrix we skip the diagonal we just represent this H as our public key as the remaining part of the matrix the secret key that's the algorithm that only I know it's a GOPA code but it's a GOPA code and there's many many GOPA codes of the same size so that's something where GOPA says well if you want to have GOPA code with 2,000 bits that can correct 200 errors here's how you set it up but there's lots lots lots of choices in there and your encryption is just take an error vector with a fixed number of bits and send me the error pattern of it so the outcome of multiplying H by this E and then we want to use this hash of this to encrypt it Dan, Peter Schwaber and Tung Shu, our PhD student wrote a very efficient implementation of this called MacBits so if you want to have more details on how you could really use this in practice then go to that URL but let me talk a little bit about why we are confident in this code-based crypto is less obvious than hash-based, I mean with hash-based it's like the all we're doing is hash, a hash function by definition is one way for this code-based crypto you need to think a little you need to have people studying it to figure out why this actually can be secure now the attacks, if I may say so started before the crypto system was proposed so it was another hard problem the coding theorists were studying naturally and then MacLeese said hey we have this hard problem here the coding E, random code is not easy well actually afterwards if you have a really random code even finding out whether there is a small code word is NP-hard and then once it was a crypto system so Umura, Debra Kellner all of those come after it was proposed for crypto there are some which have an extra parenthetical comment those are papers which study the security of MacLeese if the attacker has a quantum computer so there has been lots and lots of work for studying it against a classical computer and there has been some work studying it against quantum computer it's pretty clear that we can't use short but we can use Grover and it's not so easily obvious how much Grover can give us however, the best that Grover can do is basically half the bit size so we have this AS128 leading to 64 bit security so if you're conservative if you want to be like really really on the secure side then let's assume that we want to go for pre-quantum security at least 256 and also get post-quantum security 128 so here is some key sizes so if you're okay with a 1000 kilobyte then you're getting something which is at least 138 31 post-quantum secure and that's actually very conservative most likely we can go much down on the key size but that's where more researchers need it if you need something we can get a guarantee of 100 year security take this one it's not small it's fast but it's not small and hopefully in five years, less than five years we can give you something which is smaller and still as secure okay there are lots of possibilities for what the smaller things might be for instance there's something called QCMDPC there's actually lots and lots of variations of McLeese that people have proposed and some of those variations have held up and some of them haven't QCMDPC is something that has held up so far but how many people have looked at it and what's going to happen when more attacks get optimized you can't be trusting something which is new or hasn't been studied enough or hasn't been studied in the right directions you always have to be skeptical about crypto there's lots of proposals QCMDPC looks like one of the most interesting ones that nobody's been able to see pre-quantum security which is not very good but just as an example they have 0.6 kilobytes 600 bytes for the public key that's very reasonable size for public key, not as small as ECC but it's quite tolerable lattice based crypto that's been around since the 1990s and maybe that's enough time to start getting confidence but again there's lattice based systems that get proposed and broken for instance there's a system from Frecaltron in 2009 that was well it's not broken pre-quantum but it was shown in 2014-2015 some follow-up papers to be broken in polynomial time by a quantum computer so it's a lattice based system which sounded good at the beginning but it's definitely not going to be part of post-quantum cryptography there's multivariate quadratics now those have the interesting feature that the signatures they provide can be very very small like you can have 100 bit signatures and some reasonable security that nobody knows how to break these well there's lots and lots of these proposals and some of them are broken some of them HFEV minus that's a multivariate quadratic system that's been unbroken for 20 years maybe it'll continue holding up but well how many people have looked you have to make sure enough people look at these things the reason we like these simple systems from the 70s is enough people have looked but maybe if you've got more serious performance constraints trying to figure out what's secure and how well we can actually choose among all these different possibilities something else just last mentioned here is isogenic base this is for people who like elliptic curves that there is maybe a way to use elliptic curves post-quantum and this has the interesting feature that it does exactly the same data flow as Diffie-Hellman so everything you're used to doing with Diffie-Hellman and having like a secret key over here and a public key over there agree on a shared secret that you can also do with these isogenic base systems but only a few people have studied the security and maybe these also get broken so lots more work lots more possibilities last slide if you're interested in more information here are a few places to look first of all you can go to pqcrypto.org so this is our first survey site for post-quantum cryptography and the biggest chunk of information there is bibliography and if anybody has newer papers if you happen to write papers on post-quantum crypto and you'd like us to add those then just let us know and then well we also have on the front page things like pointers to all of the pqcrypto conferences that's the main place to look go to pqcrypto.org and follow links to for instance the February Japan conference then pqcrypto.eu.org that's the main page for the EU project that Tanya mentioned which is putting out as it progresses well it just started this year but it's coming out soon free libraries software libraries for actually doing post-quantum cryptography and benchmarking results that you can actually say I've got the following performance constraints here's what I'm able to use and then 2017 there's going to be workshop in a summer school maybe it'll be a spring school we'll see if you're interested in the Twitter feed for that then twitter.com slash pqc underscore EU and final resource on the slide is you you have the responsibility if you care about crypto then you have to get used to this stuff you have to learn about hash base code base maybe lattice based multivariate quadratics these are the things which will be the future of crypto in the future all of crypto will be post-quantum crypto because eventually the attackers will have quantum computers if you want to adapt to that future then well take a look at these systems and see maybe find improvements and cool then let us know and you know publish papers and then we'll be able to use them into real applications networking applications implement the things that aren't implemented speed them up there's lots of work that still has to be done that's it thank you for your attention Wow now we'll have some short questions please because we're a bit late on time questions go right ahead there's a mic there talk into it please can we have mic one oh okay I think there's a graph graph isomorphism has a quasi polynomial time algorithm they're not really knowing the subject at all there's some very very superficial similarities like they're that is a hidden subgroup problem basically is there going to be any like is there any indication that the methods he used and that proved for relevant to breaking weakening NTRU or things like this that's a good question so the graph isomorphism advanced now is basically saying so graph isomorphism is a problem which was famous as being not known to be solvable in polynomial or even like you said quasi polynomial time except there was some really good software and algorithms which would solve most cases of it really quickly there were just some really weird highly symmetric cases that were hard to solve and that's what Bob I managed to completely kill now so he's handled all the cases but we try to stay away from problems like that in crypto so an example that's very closely analogous to that is what's called support splitting which is a certain type of attack strategy against code-based crypto if somebody gives away lots of information from the legitimate user and that's something where the support splitting algorithm works in most cases but it kind of fails in some corner cases and well we try to stay away from thinking about this anyway because you just don't want to give somebody that extra information but if you did then maybe Bob I's techniques could be useful there thank you this talk is not over if you're leaving which is okay please be silent next question number three no number one hello thank you for the talk how are the chances to have something like forward secrecy was that I recognized the last algorithm had the chance to reuse Diffie Helman is that possibly the only one so if you're thinking that forward secrecy means the Diffie Helman you can have forward secrecy from normal encryption algorithm at the expense of generating new key each time you can have forward secrecy with RSA if Alice talking to Bob starts by saying okay this is my one time RSA key and I sent this to Bob with the request to encrypt to this method to this key if Alice never reuses this key then this method is forward secure and similar to how you can do this with RSA keys you can also do this with McLeese keys at the moment there is a difficulty that the keys are very large it is inconvenient when you want to start talking hey I'm a client hello server please talk to me and the first thing to do is transmit a megabyte of key on the other hand you can do it it just requires you to engineer your protocol to expect yes you have to send a few packages and then it has all the forward secrecy that you want away without transferring the key like Diffie Helman but Diffie Helman is transferring a key I mean you basically transferring the first part of a discrete log part if Alice sends A times P and A is a one time key she's sending a public key it's just that the method of how those two public keys interact is slightly different from how RSA encryption works okay thank you thank you do we have an internet message question? actually we do there are two questions that are somehow related the first one is given that there is an actual working quantum computer how do you start developing a crypto algorithm where do you start, how do you design it how do you test it is there a way to prove that it's secure and the second question it's related the whole thing is based on the property of the hash functions being one way how does one know that there is no quantum algorithm that breaks this property can you prove this? okay for both of these questions the technique that the community goes through, that we all go through is crypt analysis so we have as many smart people as we can find focusing on these problems and saying can you find an algorithm which is breaking these problems better than any previous algorithms can and we put as many incentives as we can so that we try to get as many smart people to stay ahead of the bad guys and hopefully find the best algorithms but there's no guarantees in this and you do always have to be skeptical whether people have actually looked at for instance quantum algorithms to attack systems and there is that extra difficulty that the first part of the question at the beginning was saying that we don't have a quantum computer so if we're trying to verify quantum algorithms that we're developing we don't get to experiment with those that's the usual procedure for making sure your algorithms work and state of the art crypt analysis like the number field sieve for factoring that does not have a proof that it works at any particular we think it works at from experiments so experiments are really important because we don't have proofs for state of the art crypt analysis and that's something where it's actually really tough for quantum computers of course eventually we'll all have quantum computers and there's ideas for simulating quantum algorithms which have had some success at verifying that algorithms work even though we can't actually run them yet that we're actually able to verify a simulation of those algorithms let me do a second part of this when we use quantum analysis for estimates we usually go for the worst case estimate so we say well megalese at worst gets broken to half the security level most likely it won't be that fast but staying on the side where we're very confident if I understood correctly that was also the part of the question how can we test the algorithms if this is for the constructive algorithms then all the algorithms we analyze both for post quantum crypto are algorithms that you can run on your normal computer so you can test those, you can run those we have benchmarking numbers from those on our current hardware will do two more questions please number one yeah I got a question on the practicality of the attacks so if we assume there is a quantum computer how much time will it take in practice order of magnitude to break 1048 bit key is it on order of hours, weeks, months, years done okay thanks that was easy number three talking to the mic please thank you so it's very nice to have well post quantum safe encryption and signing but do you know anything about some other cryptographic primitives such as is there a knowledge proofs I mean your knowledge proofs are basically which is non interactive so if you have something which is primitive for signature it's usually very closely related to zero knowledge proofs so there is work going on we are focusing on the most important things that we see on the internet but that shouldn't mean that people shouldn't do research on it please do research on zero knowledge proofs okay last question number one so why do you put so much emphasis on small key sizes and on performance and encryption especially in a delicate topic like post quantum computing why can't we just use one megabyte keys and why can't we just use a few seconds of middle seconds to compute those so what's the problem here we are suggesting to use a key of one megabyte so our recommendation that we have out on the internet on the pgkypto.eu.org page are precisely using this system which has a one megabyte key the nice thing is that actually encryption and decryption are very efficient but that was not our main goal our main goal was to get something which is very secure and where we have a high confidence that we actually understand the attack and then well once you have the system then you try to optimize how to implement it and the implementation where we quote the numbers is actually faster than elliptic curve implementations except for the size so you get a very nice speed even though it was not our target of optimization okay this is it thank you very much let's have a final hand for Tanja Lange and DGB Bernstein