 The next slide is a lupac, an asymmetric pack of particles cured against pre-computation attacks by Stanislaw Ciecki, who crashed it in Yau-Chu and Yau is going to do it. OK, so good morning. I am Stanislaw Ciecki, an international. In this book, we present OPEC, which has a male password authenticated in a strange protocol with some science companies. So this is going to work with Stanislaw Ciecki and Yau-Chu, who are working at IBM Research and by the way, I am Stanislaw Ciecki and Yau-Chu. So let me introduce that one first. So this book is in the context of the problem of password authentication. It is very clear that passwords have become the prevalent tool for authentication on the internet, she says. But on the other hand, passwords have some passwords that are vulnerable to virus attacks. So for one thing, it must be for a memorabilia, which means that it cannot have very high entropy. Another thing is that people tend to use the same password, or at least highly correlated passwords for different accounts, which means that it's the adversary that somehow updates the password for one account that is very easy to obtain other passwords for the same users' different accounts. So these are passwords disadvantages. So in the critical language, password authentication is usually modeled as a password authenticated case and all paid. So as introduced in the previous book, so in the paid protocol, two parties who share the same password interact with each other and at the end of their interactions, they all have the same random set of key denoted as a case. So this is called symmetric because the two parties share the same password. One thing to stress is that this is in the password only setting, which means that the only information shared by the two parties is the password. And in particular, there is no public key infrastructure needed. So this is reviewing the purpose of here's something new. So consider a type in a client server setting. So one party is a client and another party is a server. And what is here is an adversary who breaks into or compromises the server. Well, it's very clear that then the adversary will learn the password straight away and all security guarantee is lost. So how to modify this paid protocol such that it is resilient to server compromise? Well, it is the topic of a symmetric or augmented pay or API. So the idea is that instead of storing the password itself, the server should store a hand of the password and it's got a password file. So now, if the adversary compromises the server, what it learns is the password file, not the password itself. And of course, the adversary can allow an offline dictionary attempt over the password file, which means that because password has gone into me, so basically the adversary can compute the hash value for all connected passwords and then compare it with the password file. In this way, the adversary can learn the password but the time complexity should be around the size of the dictionary. But wait, so what if the adversary does this? So actually, the adversary can compute the hash of the password prior to compromising the server. And if the adversary does this, then after compromising the server, the adversary simply checks the password file against the precomputed password hash value and then it can learn the password almost immediately. So this is the so-called precomputation attack. So in the precomputation attack, after compromising the server, the adversary only needs around a lot of the size of the dictionary time because it only needs to perform a vital research. So a very natural question is how to force the adversary to perform full offline dictionary attack, which takes size of the dictionary time after the server compromised in a paid protocol. Well, so the basic idea is that the server should store a private running cell as long as the hash of the password and the private running cell. So in this way, precomputation attacks are eliminated because the adversary doesn't know the private running cell before compromising the server. So this is called strong A-page, which is exactly the topic of our paper. So again, a strong A-page is an A-page which is secure against precomputation attacks of A-page. There has been some formal definitions of A-page many years ago in both gateway settings and UC settings. So UC stands for universally impossible, not the University of California. Make sure that you don't get confused. But actually, very few A-page protocols are proven secure in either definition. And furthermore, all these protocols A-page allow for the aforementioned precomputation attack. We believe that this is a very serious flaw of all existing A-page, to the extent that they don't quite meet the motivation behind the definition of an A-page. Because a page which is resilient to server compromise should mean that the adversary, upon compromising the server, should still perform full offline dictionary attacks. But this is not the case, as we have seen, due to the precomputation attacks. So in practice, actually A-page rarely do. And for password authentication, it's usually done by password over TRS. So the client sends a password over TRS channel and the server, upon receiving the client's message, decrypts and gets the password, and then checks the password over the stored password file. So this is the approach of password over TRS. So let's compare these two approaches. So first of all, we know that A-page is in the password-only setting. Again, it means that there's a client and the server only knows the password and password file. And in particular, there's no PKI needed. But if password over TRS is clear, that it needs a secure channel. Another thing is that in an A-page protocol, the server actually never sees the password in the clip. On the other hand, if password over TRS, the server, upon receiving the client's message, has to decrypt and see the password in the clip. So these are the disadvantages of password over TRS. But password over TRS was involved, which is it can store private ones themselves in the server. Therefore, the adversary is required to perform full offline dictionary attacks upon server compromise. But on the other hand, in A-page, as we have seen, it allows for pre-invitation attacks. On the strong A-page combines the goodness of both of the two approaches, which is green tabs. So as in the password only setting, the server never sees the password in the clip and does not allow for pre-invitation attacks. First of all, we present the first definition of a strong A-page in the UC settings. So in password photography, UC settings has various advantages of goodness definition as listed here. And secondly, we propose two highly efficient realizations of strong A-page in the random auto model and we prove them secure in the UC settings in our UC definition. This picture is the UC A-page functionality as defined in the crypto 2006 paper. So if we take a look at the functionality, the gray tabs actually artificially allow for pre-invitation attacks. So the gray tabs is exactly what the adversary does in a pre-invitation attack. So our UC strong A-page functionality is exactly the same with theirs, their A-page functionality, with the exception that the gray tabs is omitting. So in this way, we don't allow pre-invitation attacks. So this is our definition. Here's our constructions. So both of our constructions use a critical tool called our previous pseudo-random function, or all BRF. So this is a way of computing a BRF value. So the client will host an input interactive server called the PRS key, and the client learns the PRS output without knowing the key. Of course, we present a very efficient UC-OPRF called DH-OPRF. So DH stands for David Hellman. And here's our strong A-page construction, the first one. So it is a compiler from any UC-OPRF and any UC-A-page to a UC strong A-page. So the client and the server first engage in an OPRF with the client using the password as the OPRF input. As it onwards, the PRS value is called R-double for randomized password. And in the second state, the client and the server exactly do an A-page, except that the password is replaced by this R-double, a randomized password. So why is this a strong A-page? Well, you know, if you have any UC-groups, UC-groups are always complicated, but the idea behind the group is actually very, very simple. So why does the server perform greater rotation time than normal A-page? Well, because the password has low entropy, and essentially, it's the adversary that moves forward over the password listener. But here, thanks to the PRS-TK, the randomized password is random to the adversary with high entropy. Therefore, the adversary also can perform current rotation time on the password and cannot do the same thing on this randomized password which is still in the A-page. So in this way, we eliminate the current rotation attacks. So this is our first construction. Our second construction is a compiler from a UC-OPRF and a UC-authenticated TX-Train to a UC-strong A-page. So again, in the first stage, the process is the same as in the first construction, the client computes the randomized password R-double, and then, so because in an authenticated TX-Train, we require that the full package holds a private key and runs a new key. But here, we are in the password-only stage, so the client cannot hold its key. So we select the server store a ciphertext of the client's keys under the randomized password R-double as part of this password file. And after the OPRF stage, the server sends the ciphertext to the client and the client who has already computed an R-double can decrypt the ciphertext and get the identity. And then the client and server just run a normal authenticated TX-Train and obtain the security. And the sign-on is that for the authenticated TX-Train, we would require a specific property called ecompromised impersonation of KCI. So actually, it's a compiler from any OPRF and any AKE-PCI to a strong event. So OPRF is the practical instantiation of the set of construction. So it can be very efficient with the OPRF instantiated with DH-OPRF. And that AKE part can be instantiated using virus protocols. We note that actually, very similar protocols have been studied before in virus papers, but we believe that we are the first one to analyze that protocol as an event, let alone a strong event. Okay, so here's a complete instantiation of OPRF with H-A-Q-V as authenticated TX-Train. So as you can see here, this alpha and beta values are messages sent in OPRF. And that capital S and capital Y are the messages sent in authenticated TX-Train H-A-Q-V. So the key point here is that the OPRF and H-A-Q-V can be integrated. So in this way, this OPRF can be done in only one run of OPRF with H-A-Q-V. As I just said, it can be done in a single run because these two runs can be done simultaneously. So the computational cost is comparable to the most efficient excessive attack protocol as you can see here. So although the number of explanations per user is a little bit high, the number of explanations per server is actually the least among all the protocols showing it. Some features of our OPRF protocol. So first of all, as we have seen, it's highly efficient and it's provenly secure. Again, it's a UC setting. And our UC protocol is modular, which means that it works for any UC OPRF and any UC authenticated TX-Train with the ACI property. And secondly, as shown in the previous slide, it combines good properties of both passwords over TRS and H-A-Q-V. So first of all, it requires no property infrastructure if password only. Secondly, the server never sees the password in the clear. And finally, it eliminates all pre-computation attacks. This is the only such protocol in the non-PKI setting. And furthermore, it supports TRS integration. So recall that this opening, the strong opening is in password only setting and it doesn't actually require TRS. But if we have access to TRS, then the cybernet sends from the server to the client. So I can still remember that. It is the cybernet of the client's keys under the randomized password. But the cybernet actually contains the client's other sequence. Say it can be the client's Bitcoin wallet or more relevant, it can be the client's TRS signature key. So if we do this, then the key exchange part of OPEI can reuse the key exchange of TRS. So these two can be combined. We only need one key exchange instead of two. So in this way, we protect the TRS using a strong opening protocol which is compressed to the password over TRS where the TRS channel protects the password. So finally, there are some possible extensions of OPEI. So first of all, by adding only one message, it can support explicit authentication which basically means that the two parties simply abort if they don't get the same key. Another thing is that thanks to a recent result of a sort of threshold OPEI life, it is very easy to extend our strong OPEI to a threshold implementation which means that the adversary, so there are not one server but one server and the adversary in order to perform an offline dictionary attempt has to compromise a certain threshold, say T, out of the N server. So if the adversary fails to compromise T servers, say only compromise T-1 servers, then it cannot even perform an offline dictionary attempt. So in summary, we present the definition, the UT definition of a strong OPEI and then we realize this definition using full construction and both of them are highly efficient and they can be integrated with PLS and this is the end of my talk. Thank you very much. Do we need to use the key OPEI life later for authentication? Sorry, can you just say that? So I'm asking about the key, the OPEI life key. Okay, that's small key, right? Yes. So the question is, is the same key for every user or is it like? Well, so this small key is used only in OPEI life, so it's not used elsewhere. Okay, but do you have to store it on the server? Because if it's not used elsewhere, so they compute RW, so then the server just needs RW. Okay, why does he need the I's? Okay, so he needs the key to compute it. So if the client wants to compute RW using this OPEI life, so this OPEI life requires that the server stores the priority which is denoted as OPEI. Does the key has to be the same for every user, so it could be different for every user? Well, so this key can be the same for different users. Yeah.