 Okay, thanks. I'll talk about what NIST is doing about the possible deployment of quantum computers in the next couple of decades. Okay, so the problem is that large quantum computers, they would break most of our public key crypto. That includes our SAID, if you have an elliptic curve crypto. Symmetric crypto would not be affected. It's surprising the number of meetings I go where people tell me that AES is gone after quantum computers. That's not the case, but we will need to make keys longer. Full transition to alternatives takes a long time. Judging from the history of these things, we could easily claim about 20 years. I suspect that there may be a greater sense of urgency with respect to the advent of quantum computing. So I'm thinking maybe about 10 years or more. So the time to worry about this is now. This doesn't see enough attention from my point of view. There are long-term privacy and security implications which affect us now. From the privacy perspective, there are things that are being stored now by agencies and possibly industry, which will later, which can't be opened now, but will be maybe opened if quantum computers are built. You have kids or grandchildren, their DNA profiles may be stored in ways that are maybe opened in the future. But I think it's a severe threat that we're facing now, not when quantum computers are built, but now. Something similar with respect to security implications, I think if quantum computers are built and they are deployed, we will see many years, possibly decades, during which we're going to be discovering all kinds of things being protected by pre-quantum keys. To get that stuff out of all of our applications is going to be a very difficult task. Okay, so NIST has a post-quantum cryptography project that's been going on for about five years now. Our goal is to monitor progress in quantum computers and quantum algorithms to find and standardize quantum-resistant alternatives for public key encryption, key agreement, and digital signatures, and to ensure the transparency of the process and the integrity of the outcome. This is especially important after the Snowden revelations. This is not a competition. I keep saying this over and over and over again, and people keep coming to me and say, hey, how about the NIST competition? I hope that we will develop significant community consensus at the end of the day that NIST will basically serve as a sounding board, and eventually we'll have to make a decision, but hopefully the decision will really be made by the community. It's not necessarily true that we'll standardize just one candidate for each of the applications. We may standardize several. The evaluation criteria, when we have a competition, the evaluation criteria needs to be written in stone because later, if we start changing things later in the game, people cry foul. Now, be warned that this is not written in stone. We know too little about quantum computers right now. We know too little about the actual complexity of candidates to be writing these things in stone and saying we're not going to change it no matter what happens through the next seven years. So criteria hopefully will evolve, and it will reflect our gaining knowledge of the situation. There's a call for proposals, which is out. This is the link where they may be submitted. The deadline is November 30 of this year. The discussion about this is through the PQC forum. The current wording of the call for proposals follows public discussion in this forum. Sometimes very loud public discussion, and that's the way we like it, I guess. And this is also in this forum where the submissions and germane issues will be discussed. Evaluation criteria is one of those issues that needs to stay in the discussion table. To join this mailing list, just send mail to this link here. Okay, so we are agnostic about what techniques look the best right now. We choose to be agnostic. We want to have an open mind with respect to all the possible ways that people may want to solve this problem. But I'll give you a rough listing of what we see out there now. So for signatures, we see hash-based signatures, code-based, lattice-based, and multivariate-based signatures. The dot-dot-dot means that I'm not going to be held to this being an exhaustive list in any of these. For public encryption, we see lattice-based, code-based, multivariate. There are others, braid groups and things like that. For key agreement, one can decide that key agreement is not a real topic because once you solve PKE, you have key agreement. No, we chose not to. We want to call it a separate problem. But it can be solving the public encryption problem. But there are lattice-based and estrogen-based and other types of dedicated key agreement protocols out there. With respect to what will change in terms of speed and sizes of things, speed looks good. That's surprising to me anyhow. Some of these systems look blindly fast. Key sizes are not so good. They may increase significantly. Some signature sizes look big, not terribly big, but they look big. We'll have to collectively decide if that's okay or not. There may be a significant increase in ciphertext size for short plaintexts. I really have no idea how industry feels about that, what that might do to applications. We really do need to have an impact assessment by industry, especially by industry, but also by the community at large. We need to have that impact assessment now as soon as possible because once there are very few candidates left, two or three clear candidates are likely to win this thing to end up being the standard, then the impact assessments get all muddled by the fact that people will be advancing their favorite candidates. If we can do it now, that would be very useful. What's public discussion? There's this ongoing discussion. If you've seen the PQC forum, you'll see that there's been this rather strident disagreement about this measure of security that's in the call for proposals. My position about this is that in this security levels, to really answer the specific wording of the call for proposals, it looks like you need to decide how many quantum gates that are required to break your candidate. On the other hand, some of us, I feel that no candidate should have to be, no proposer should have to be an expert on quantum computation in order to put it in a submission. If you have any problems with putting a number to this number of quantum gates question, contact us or contact the forum. This is as open as it can be in this process. Contact us. We'll sort it out. Are we just the arm of the NSA? I guess I can't blame the community. I have another project which is dear to my heart, which is the NIST, Randomness Beacon. Sometimes I Google that beacon and it says the NIST NSA beacon. There's pictures of me with horns and things. So this committee, this PQC project is a committee of eight people. There's a report out that spelled out our understanding of this about eight months ago or so. That report contains the names of seven of the eight current members of this team. There's no secrecy there. There's just eight members of NIST right now. We sit at the table. The NSA has no seat at that table. However, times are a little scary right now. So keep watching us. We need that. You protect us by demanding our transparency. Another topic that has been making the rounds is demands that future standards make bad implementations harder. I suspect this would be very hard to do in the abstract. For us NIST to agree that we're going to include in the standards this requirement that if you say develop AES-2, it will have all kinds of tests to check for possible bad implementations. I think that's just not going to fly. I may be wrong. So if you feel strongly about that, please argue with respect to the candidates in the post-quantum cryptography competition, please make your views be heard in the NIST forum. On the other hand, I think that some of these, I don't know, prophylactics can be put in place at the end of the game. At the end of this process, five years, six years from now, it looks like we're really going to do this, standardize this particular algorithm and you have a good idea of a way to standardize it to make it more resilient to bad implementations and that's probably the time to argue for those things. If you try to argue for them as a general rule for standards, I think that's not going to fly. What am I doing here? Okay, the timeline. Formal call is out. November 30 is the deadline for the submissions. During 2018, we'll have a workshop and then that will be followed by three to five years of analysis. We'll report the findings and one to two workshops in this phase and hopefully two years after that we'll have the standards ready. So this is seven years. This process may take a good seven years from now. Thank you. I have to ask in the call, there was no like for signatures. There was no specification on whether you're looking for stateless or stateful signatures. Any opinions on that? I think we're, first, we are going to take both, candidates for both, whether so stateful have this private key size problem which is gigantic. So if there are advantages, people can argue for advantages that make us wanting to do that, despite that, then we'll definitely consider them. So both are in play. Okay, it was my understanding that NIST had publicly said that they were not interested in hash-based signatures. You are counter-addicting that? Yes, I don't know who said that. I was wondering, you mentioned industry impact assessments. So I'm wondering if any federal agency is doing their own impact assessment that would serve as a model for that. And if not, whether they were, the federal government would be interested in stimulating any industry activity around that? Oh boy. I think that question, the second part of that question is about my pay grade. I can certainly pass that suggestion on with respect to what is being done by a federal agency, other than the NSA, which is not going to tell us, I wouldn't trust the assessment that any of these agencies including NIST can do. I think it's beyond our capabilities. Thank you anyway. I also wanted to clarify, you said it's a panel of eight people, seven of which are public, and one of which is... It just hired them. That's why he's not in the... Everybody's name is public. The eighth person who was hired after this report was public. So I'll see that the list of people who sit at this table is put out somewhere. Yeah, last question. You mentioned making bad implementations harder and perhaps delaying that consideration a little. Perhaps another way of putting it is that you want to make correct implementations easier. And certainly that could perhaps be prioritized early. So instead of trying to place landmines for bad implementations, we certainly avoid putting in complexities that make good implementations less likely. And that perhaps is a good consideration earlier on. That should be in the minds of everybody who plans to submit this. Yeah, so take that as a suggestion to your submissions. Great, thanks a lot.