 Last year at Real World Crypto 2017, a colleague of mine at Microsoft Research, Michael Narek, gave a talk on this very promising post-quantum cryptographic scheme called SuperSingular Assuming Difficult Monkey Exchange, or also known as SIDH. This talk today is a little bit like a continuation of that talk, but focused especially trying to summarize all our efforts to make not only this scheme and related schemes ready for the post-quantum competition that began a few weeks ago, but also try to make it as practical as possible. So, thank you to Melissa. I can keep most of the motivation part. So, I can say that we are going to focus on this talk on SIDH and also in a key encapsulation protocol that we recently designed and that we call SIDH. But before getting into the technical details, let me just give you a very quick timeline of the development of Isoini-based crypto. It all began in 1996 when Covenius described the first Isoini key exchange scheme. Years later, in 2006, after a series of papers by Rostoyev Stobunov, we had a key exchange using ordinary Isoinis. But the problem with all these schemes was that they were terribly expensive. They were impractical. It also was found out that they could be broken in quantum sub-exponential time. So, that was pretty bad. But this was solved, thankfully, to David Javan, look at the FAO, who looked at the problem and proposed a key exchange based on super-singular Isoinis. And that was in 2010. And this is the scheme that we know as SIDH. And with SIDH, we get much better performance. And also, we solve the problem of security because now the attack complexity runs in exponential time. And this is for quantum and also for the classical cases. Now, let's stop for a minute this timeline. Let me give you a very quick explanation of how SIDH works. Okay? So, in the setting of SIDH, what we have are elliptical subgroups. And these subgroups map to Isoinis. Okay? Now, a definition that helps us here is what we call a super-singular Isoini graph. So, in this graph, what we have are vertices, right? And these vertices are elliptic curves or, more precisely, isomorphic classes. And these vertices are connected to each other through edges. And these edges are the Isoinis, the ones that map one curve to the other one, right? Now, in this setting, we have a fixed Isoini class, right, for all these subgroups. And for security reasons, we need Isoinis that have a large degree, right? Another requirement that is important here is that we need these Isoinis to have a smooth degree. What this means is that if we are in the graph and want to walk through the graph to get to another curve, then we can do it as a small step at a time, right? So, to give you a concrete example, in practice, we instantiate these small steps in the graph using two Isoinis and three Isoinis. Okay? So, with this in mind, let me explain SADH at a very high level. We have a starting super singular curve, E dot. And then, at least, what needs to establish is an elliptic curve subgroup, in this case, using a secret essay. And this subgroup that we call it A here corresponds to an Isoini. With this Isoini, we can map the original curve to another curve that we call EA here. And this is actually E dot modulo subgroup A that we just defined. Bob, on the other side, does a similar computation to get to EB. And these two new curves are actually public, made public. They are exchanged between the parties, between Alice and Bob. It turns out that this information is not enough to complete a key exchange. We need extra information that I show here in this slide. We actually need a couple of evaluations on public points using these secret Isoinis. Okay? So, with this information at hand, then Alice can continue the computation taking the curve EB. And using a new subgroup also set up with the secret essay, then we get to a new Isoini that maps EB to a new curve, EBA. That is actually the curve EB modulo, this new subgroup A dash. Bob does a similar computation. And then what is interesting about these two new curves is that they are isomorphic. They actually correspond to this curve called here E dot modulo, the original subgroups A comma B. So, all these curves are isomorphic. That's great. Then we can use the J invariant of these curves as shared secrets. Okay. So, that's for the technical part of the SIDH scheme. Now, what is the problem here that is hard to compute? Well, let's look at these super singular curves in the setting, let's call them E1 and E2. They are defined over quadratic extension fields. Using a large prime P, we have the Isoini that maps E1 to E2. And as I said, the Isoini should have a large smooth degree. And then the super singular Isoini problem is the following. Given points PQ and the images of those two points, then the hard problem is to compute the morphism, the map, the Isoini map, right, here represented by phi. As I said, the best known attacks against this problem are running exponential time. We can see the complexities in the slides for the classical and quantum cases. And these are done through a generic low-finding algorithms. Now, at the time this was proposed, there were still two problems that remain. On one hand, the existing realizations were still very slow. They ran in the hundreds of milliseconds. And worse than that, they were unprotected against time in such an attack, which is a basic requirement nowadays to have a practical implementation. The second problem is that SIDH is not secure when keys are reused. So it's only recommended for ephemeral mode, right? So going back to our timeline, in 2016, we took a closer look at SIDH. This was a joint work with Greg Costello and Michael Naric at Microsoft Research, and we pushed harder on the performance issues to make it practical. So we proposed a new parameter set that we call SIDHP751, that targets the 128-bit quantum security level, and also proposed a series of optimization techniques that push the performance below 60 milliseconds. So that was a great improvement. And, moreover, the implementation ran in constant time as we wanted, right? So getting close to practice, to practical use, maybe for some applications, still not fast enough, and definitely still having the problem of static keys, right? So in 2017, we continued our efforts pushing hard on the performance issues and also looking at the issue of static keys, and that's why we designed this key encapsulation protocol that we now call SIDH. And the design of SIDH is due to Greg Costello, Luca DeFeo, David Yao, myself, Michael Naric, and Joe Srenes. This is a CCA-secure key encapsulation that uses a variant of the Huffman-Kill transform to transform a CPA-secure public key encryption to a CCA-secure key encapsulation mechanism, or KEP, right? And this transform is secured for both the classical and quantum random oracle models, which is good. Another observation is that we observed there is no performance loss when switching from SIDH to Psyche. This is specifically in the case where offline is computed, sorry, the key generation is computed offline. And, moreover, we also propose additional parameter sets, matching the brute force security of AES-128, 192, and 256. In the table in the slide show the details. The name for each parameter set is Syche, concatenated to the big length of the underlying prime. So we have Syche P503, P751, P964, and they correspond to the NIST security levels 1, 3, and 5, which are defined in the call for proposals from NIST. Now, let me give you a very brief explanation of how Syche works. First of all, we have a key generation stage. This can be seen as computed from Bob's side. So first of all, we have to establish a secret SB. And similar to the SIDH setting, that secret is used to establish an elliptic curve subgroup. And with this elliptic curve subgroup, we generate a public key that is called here PKB. And this public key is sent to the other party that performs the encapsulation process. This can be seen as computed from Alice's side. And Alice runs an encryption operation, right? It takes a message M, a new secret R, and then does similar computations to the previous operations, the previous processes, establish a new subgroup using this secret R, fixes, computes a new public key that is called here PKA. And similar to the SIDH setting, we arrive to a J invariant of the curve, in this case, EAB. And the secret here is the hashing of the message M with this cipher text. And now the cipher text is explicitly detailed here in the arrow that you see in the screen that is passed to the other party, back to the other party, that runs the decapsulation process. Now, the decapsulation proceeds to do the decryption and also a partial re-encryption in order to, well, to recover the public key PKA that was sent from the encapsulation party. And this one is compared with the original, the calculated one is compared to the original one in order to detect any, well, in order to make sure that the cipher text was well-formed. All right, if it is the case, then we should arrive to the same share key SS that we show here in the slide. And we instantiated hash functions in our case with Cshake 256. All right, so those were the details for Psyche. Let me just go through some other additional contributions that we have. We wrote a library that we call SIDH. We are at version 3.0 now and this version implements SIDH and Psyche, covers two security levels and contains a bunch of implementations, especially high-speed implementations for X64 and now for ARM V8 too. Also, there are no secret branches in the code, no secret memory accesses, so probably we can say that the code is protected against cache timing attacks on or probably not anymore. As always, the software countermeasures depend on the assumptions made in the hardware, and if the hardware fails, then there is little we can do about it. What we can say is that our assembly code, which has a very good chunk of the implementation, is not vulnerable to these attacks because there are no branches. For the C code parties, the things are more complicated. We have to make sure that we use the right countermeasures, but I'll let the Project Zero team explain it later with more details. We will hear about that today, I guess. But let me get to the timings, to the interesting part, to the practical part. As I said, we have the implementations of SIDH and Psyche, two security levels. I want to highlight in this table the nice numbers that we are obtaining after improving P751. You can see that the numbers for that security level are close to 30 milliseconds, so it's a nice improvement compared to the 60 milliseconds that we had before and even the hundreds of milliseconds that we had a few years ago. So we are steadily improving the performance, which is nice. And especially nice is that the version 503, the security, the parameter set 503 runs in about 10 milliseconds. So arguably, that makes these skins practical for many applications out there. We also have timings for ARM64 platforms, and this is thanks to an implementation by Matt Campania. And finally, let me point out that we have, we submitted Psyche to the NISPOS quantum competition that had a deadline a few weeks ago. The package can be found in this link. And here is the full Psyche team. A bunch of people working on theoretical aspects, hardware implementations, software implementations on different platforms. It's a multi-company, multi-university effort, a great team to work with. And I want to finish this presentation mentioning that in the last couple of years, we have seen a spike in the interest in SIDH and related schemes. That is great. We now see many, many works out there trying to improve several aspects of super-singular studies. So, for example, I can mention there are works on faster compression, making the public keys even smaller, which are, by the way, the smallest one among the most popular post-quantum candidates out there. We have optimized algorithms also and works on signatures, which is great. And I want to, you know, ask the community to continue putting effort on making super-singular studies even greater. So thank you for your attention.