 Hello everyone, my name's Amit and I'm going to be giving this talk on lattice-based eCache. So this is all based on joint work by myself, Benoit, Koa and Olivier. To give a brief outline, I'll begin with definitions and motivations for eCache in general, followed by problems with previous schemes, in particular, issues that arise in their exculpability proofs. And finally, I'll present to you a provably secure scheme from lattice assumptions. Okay, so the high-level idea of eCache is that we want to reproduce the privacy of cash payments in a digital world. So in order to take money out of its account, a user you engages in a withdrawal protocol with a bank and at the end of this protocol it obtains a bank-certified wallet that allows it to spend up to n coins. In particular, the user is known to the bank at this stage and this phase is entirely analogous to an ATM withdrawal. Next, when the user wants to make a purchase, it engages in a spend protocol with a merchant and at the end of this protocol, the merchant obtains a coin. Much like traditional cash payments, we require that the coin cannot be traced back to the user in an eCache system. Finally, the merchant can deposit this coin into its account by means of running a deposit protocol with a bank. Once again, at this phase, the merchant is known to the bank in order for it to make this deposit successfully. Another key property of traditional cash payments is that they can be done offline. In particular, the merchant doesn't have to connect to the bank every time it wishes to accept a traditional cash payment. Instead, what happens is that under the assumption that it's hard to convincingly clone physical cash, the merchant can inspect the bank note and then decide whether to accept or reject the payment. However, this on-clone ability assumption does not hold in the digital world. As there's nothing that stops a user from making many copies of its wallet and then spending it, spending the same coins at different merchants. Therefore, in order to get over this stumbling block, eCache systems introduce an identification mechanism, where if a user double spends a coin, the bank can then de-anonymize them and punish them suitably. So to motivate eCache further, we can look to this recent report published by the European Central Bank on its plans for a digital euro, and what we see is many desirable properties highlighted. So guided by this extract, it's interesting to compare the properties of eCache with the properties that cryptocurrencies tend to give you. So a first point of comparison would be to ask whether offline payments are supported. So for eCache, the answer is yes, as I just described, whereas for cryptocurrencies, merchants tend to need to connect to some central ledger in order to accept payment. On the other hand, we can ask whether the system is decentralized. Well, for eCache, the answer is no. So there is a single bank or a single central authority overseeing the system, whereas for cryptocurrencies, well, these can be decentralized and many of them in fact are. Next, in terms of anonymity, eCache comes with anonymity built in by definition, whereas cryptocurrencies tend to offer varying degrees of anonymity, some of which are just simply pseudonymous, whereas others give stronger guarantees. However, it can be the case that there's some extra leakage given by transactions published on the central ledger, in the case of cryptocurrencies. And finally, we have the question of compliance with legislation. So as I mentioned before, eCache shares a transaction flow with traditional cash. In particular, the bank knows who users and merchants are at the point of withdrawal and deposits. Whereas for cryptocurrencies, the model is slightly different and it's not clear at all whether that you get the same compliance guarantees in the cryptocurrency setting, particularly in the privacy-preserving ones. Okay, so before we move on to the definition, I'll overview the literature. Starting from the seminal work of the Kaminish et al in from Eurocrypt 2005, many eCache schemes essentially borrow and extend techniques to to build eCache schemes with perhaps more flexible properties. But the main point I want to make in this overview is that following the work of Bors et al from Asiacrypt 2019, which I'll refer to as BPS19, all of these proofs have an issue in the proof of exculpability. So the exculpability property for these all of these eCache systems doesn't provably hold. So BPS19 actually fixed all of these schemes by proposing a new a new sort of eCache formulation. However, their construction is only shown to be instantiable in the sort of number theoretic and pairings setting, leaving the question of provably secure lattice eCache open. All right, so next we're going to go into the security definitions, but first I want to highlight the structure of a coin and the syntax of the identify algorithm as it will help better explain the security definitions. So for a coin, we're going to have four components, the first of which is a serial number or a unique identifier for the coin. So essentially, if two coins share the same serial number, we're going to view this as a double spending. The second component of the coin is the double spending tag, which allows for the identification of double spenders. Next we have transaction information, which just allows a merchant to differentiate between different transactions. And finally, we have Pi, which is a proof of knowledge that the coin is certified by the bank and that it's properly computed. As for the identify algorithm, well, this takes as input two coins. If the two coins share the same serial number, but have different transaction information, then a public key is output by the identify algorithm. And the idea is that the user, the owner of this public key is the one being accused of double spending with respect to coins one and two. Okay, so to move on to the security notions, the first and potentially most obvious one is that of anonymity. And this essentially asks that when a user spends a coin, the user may remain anonymous even when interacting with malicious banks and merchants. So to semi-formally define this, we're going to introduce four oracles. And at this point, I'll remind you that the adversary is playing the role of banks and merchants throughout this game. So first of all, we have this add user oracle on input i. This instantiates the ith user and publishes its public key. Next, we have the withdrawal oracle on input i. This plays the ith user's role in the withdrawal protocol, leaving the adversary to play the bank's side of the protocol. Next, we have the spend protocol, which takes as input four things, the first two of which are i and j. And essentially what this spend protocol does is it plays the ith user's role in the spend protocol using the jth wallet belonging to that ith user. And furthermore, the transaction information and the merchant public key are are left up to the adversary to decide. Finally, we have the simulated spend oracle, which takes the same inputs as the spend oracle but ignores the user and wallet identifies i and j. So essentially the simulated spend oracle acts independently of the user and the wallet. Now, essentially the anonymity requirement asks that these real-world and simulated worlds are indistinguishable. Or in other words, informally, no efficient adversary can distinguish between a spend oracle and a simulated spend oracle. Next, we have the notion of exculpability, which essentially asks that an honest user that does not double spend cannot be accused of double spending convincingly. In other words, an honest user is the only one who can spend its coin. Once again, we have the adversary playing the roles of a coalition of malicious banks and merchants. So we have the same oracles available to the adversary. However, we introduce two lists. The first one is the list of enrolled users. And the second is the list of double spendings. In particular, it's the list of serial numbers tied to double spendings. So in order to trigger a double spending, an adversary just has to to query the spend oracle on a fixed i and j enough times so that the internal wallet counter of the jth wallet of the ith user gets reset to its original state. At which point any further spendings are seen as double spendings, as the serial numbers will be repeated at that stage. So the security game goes as follows. The adversary gets some public parameters and outputs a bank public key. It then interacts with the three oracles and outputs two coins. We say that the adversary wins if the identifier algorithm on input the two coins points to an enrolled user. But the serial number isn't in the list of double spendings. So in other words, the adversary has successfully framed one of the users of double spending. And it importantly, it didn't use the coins that it obtained in spend queries. Okay, so finally we have the notions of traceability and clearing. Traceability ensures that double spenders can always be identified, whereas clearing ensures that an honest merchant is the only person who can deposit the coins it receives. Okay, so now we're going to move on to the issues in previous schemes. In order to do so, we're going to use the example of the lattice based e-cash scheme from Asia Crypt 2017 where the serial numbers take the form of a PRF evaluation on some wallet counter J and the security tag associated to the serial number is the public key of the user, additively blinded by transaction information multiplied by a secondary PRF evaluation. And note that the two PRF evaluations involved here share the same input, but have different PRF keys. So the identify algorithm from the scheme essentially outputs a linear function of the two security tags, the idea being that if two security tags share the same PRF evaluation and public key, then identify essentially solves the system of linear equations and returns the public key. Unfortunately, this this identification mechanism is somehow flawed and the issue is that just because two coins share the same serial number does not imply that the two tags share the same public key and PRF evaluation, implying that the identification algorithm doesn't exactly work as intended. Okay, so to see this concretely, suppose we have two coins in the exculpability game that are output by the adversary and suppose further that there is a collision in the PRF with respect to the common serial number. In particular, there's two inputs, J and J prime, such that the PRF evaluates to the same value with respect to potentially different PRF keys. Now, the problem here is that coin one may be computed with respect to J, whereas coin two may be computed with respect to J prime, in which case T one and T two may be totally independent. In particular, their PRF evaluations underlying the tags will may be independent, in which case we can't use correctness of the identification mechanism in our exculpability proof. So this problem was highlighted at AsiaCrip 19 by this BPS 19 paper. And furthermore, they propose a fix to the issue. And the fix is to adapt the serial number and tag construction and use collision resistant PRFs. But unfortunately, it's not known whether the zero knowledge compatible lattice PRFs satisfy these collision resistance properties. So a natural question is to ask whether there's some alternative construction of eCache where security can be based on lattice assumptions. So this is what we investigated, and I'm going to now present the secure alternative. So we're going to be using the this primitive of lossy trapdoor functions or LTFs. For the purposes of our talk, all LTFs allows to do is sample matrices in two different modes, the first of which is lossy mode. And the idea of lossy mode is that a lossy matrix A essentially compresses the input. So when you multiply it, when you do A times the input space, you get a much smaller space. In other words, multiplication by a lossy matrix is many to one. Whereas in injective mode, what you end up getting is a matrix along with a trapdoor tau. And what this trapdoor tau allows you to do is it allows you to invert matrix multiplication by an injective matrix. And importantly, LTFs ask that lossy matrices are independent, sorry, indistinguishable from injective matrices. So we're also going to use the leftover hash lemma. And in the traditional lattice setting, this essentially states that a wide uniform matrix U multiplied by a uniform binary vector X is statistically close to uniform. And what's more, the generalized leftover hash lemma says that even if you reveal some lossy leakage on X in the form of A times X, where A is lossy, we still get that U times X is statistically close to uniform. In other words, leftover hash lemma holds even when given lossy leakage on the vector X. So now we're ready to describe our new coins. And each coin is going to use a single PRF evaluation denoted by Y. Serial numbers are going to have two components now. The first component is going to be A times Y, where A is a global public matrix. The second component is going to be the public key of the spender, additively blinded by U times Y, where U is a wide global matrix. So U is also part of the public parameters. And finally, the security tag is going to be the public key of the spender, additively blinded by the product of the transaction information and U prime times Y, where U prime is also a wide matrix and is part of the public parameters. The idea behind this construction is that if the lossy trapdoor function matrix is sampled in injective mode, then we have the guarantee that collisions in serial numbers imply collisions in the PRF value and the public key. To see why, simply invert the first component of the serial number to find Y, then use this to recover the public key from the second component of the serial number. So in other words, if two serial numbers collide, then the two security tags have the same PRF evaluation and public key. So now I'm going to overview the exculpability proof. And in order to, before getting into this, we need to discuss what public keys look like. Well, secret keys are going to be uniform binary vectors and public keys are simply going to be some public matrix F times a secret key, modulo key. So the exculpability proof essentially says, if there's an efficient adversary winning the exculpability game, then we can solve this efficiently. So suppose our sys input is F, where we're going to place F in the public parameters and sample the public matrix A in injective mode. Then we're going to easily simulate, easily and perfectly simulate the add user withdrawal and spend articles for the adversary up to the point at which it returns two coins to us. And let's suppose that the two coins are are consistent with A winning the exculpability game. In particular, they share the same serial number, which means that the same public key and PRF evaluation underlies the two security tags. And in turn, this means that the identification procedure returns that public key underlying both security tags. Now, since this public key belongs to an enrolled user, we know a secret key underlying it. So let's call this this vector insta. Next, since the serial number was not in the double spending list, one of the coins is not the result of a spend oracle query. So let's suppose that coin one is not the the the result of a spend oracle query. Well, what we do next is we use a knowledge extractor on pi one to find a secondary secret key e prime underlying the public key. And essentially what we see is if e star and e prime are not equal, then we've solved the sys problem with respect to f. So formally, in order to complete the proof, we need to argue or use a lemma that states that public keys no public keys don't correspond uniquely to secret keys, i.e. there's more than one secret key for a public key. And that the proofs in the coins are witnessed indistinguishable. Okay, so to move on to the anonymity proof, recall that a definition asks that spend oracles are indistinguishable from simulated spend oracles. Or in other words, genuine coins are indistinguishable from simulated coins. So suppose we have in this starting hybrid h naught a genuine coin. Well, we're going to define our first hybrid sort of distribution by replacing zero knowledge proof with a simulated zero knowledge proof. And this simply uses this zero knowledge simulator. Next, we can replace the prf evaluation y with a truly uniform value. Then we replace the the matrix a with a lossy matrix a, which allows us to finally apply the generalized leftover hash lemma and replace the second component of the serial number and the security tag with the uniform values. At this point, as you can see, the coin is independent of the public key and the value y, the prf evaluation y, which means that the coin is independent of the user and the wallet as required by the anonymity definition. So before I finish a quick note on instantiations, well, we have the usual suspects for the prf and the LTF. And for the non-interactive zero knowledge proofs and knowledge, we have either the protocol of Yang et al or Buelans from Eurocryptus year. And essentially, we need to use these these proof systems because our zero knowledge statements are very complex. In particular, they require to show correctness of a prf evaluation and of a bank signature. So in order to use these without interaction or in order to achieve non-interactivity, we simply use the Fiat-Shamir transform, which essentially means our security proofs are in the random miracle model. So a final note here is that under a suitable choice of instantiation, all modular can be taken to be a low degree polynomial in the security parameter and all dimensions can be taken to be quasi linear in the security parameter. So to conclude, we constructed a secure eCache outside of this BPS framework. However, concrete efficiency for our scheme is still quite poor. So a natural question is whether we can improve this by making our zero knowledge statements shorter or making zero knowledge proofs more efficient. And finally, we have another open question asking whether we can instantiate the BPS 19 frameworks in the lattice setting. So in order to do this, we would need to come up with some zero knowledge compatible lattice prf that has strong collision resistance properties. So that's the end of the talk and thanks for listening.