 Hello everyone, I am Mohamed Eskin and in this talk I'm going to present our PKC 2022 paper. In this work we introduce a new cryptographic primitive that we call verifiable partial decryptable commitments. And we have an instantiation of this primitive from lattices and we have an application of this lattice based instantiation in the blockchain private payment setting. And this is a joint work with Ron Steinfeld and Raymond Zaw from Monash University. Okay, so let me start with the outline. So I'm first going to talk about these two features accountability and auditability which are the motivations for the introduction of this primitive that I mentioned before. And I'm going to very briefly talk about the commitment schemes and uninterrupted remote proofs or NISC proofs for short. This will be very brief discussion. And I'm going to introduce this new primitive that we abbreviate as VPDC. And then I'm going to talk about our lattice based instantiation. So our instantiation is based on a commonly used lattice based commitment scheme that we call hashed message commitment. And then finally I'll talk about our application in this private blockchain payment setting where we construct an auditable protocol that we call matrix A. Okay, I'm sure everyone knows what a multi-part protocol is, not just a recap. So we have a bunch of parties in this simplest setting we have two parties, Alice and Bob. So in this multi-part protocol, they might be exchanging some messages, they might run some internal computations, and maybe at the end of the protocol, they might output some messages. Okay, and here, as you can see, Alice knows who Bob is, Bob knows who Alice is, and everyone else can see the exchange messages and can also see who is exchanging these messages. Okay, so of course, from a cryptographic perspective, this is not very desirable because we might be leaking out of secret information, for example, M01 and so on, might be containing some secret information, or leaking the user identities that are involved in the protocol might also be not desirable. And from a cryptographic point of view, we often want what's called a privacy cruiser in protocol. In this setting, we again have Alice and Bob, but they kind of have a shield, a cryptographic shield that protects their identities from the outside world, or they may also not even know each other's identities, and also the messages that are encrypted, sort of the messages that are exchanged between Alice and Bob, they are also somehow hidden from the outside world. Okay, and to achieve these privacy goals, there are common tools employed, such as commitment schemes, zero-knowledge proofs, encryption schemes, and so on. But even though this setting of privacy prison protocols are very desirable from a cryptographic perspective, it also leads to issues in practice. And in particular, for example, Bob may be malicious, and he might be actually exploiting these privacy features to hide, for example, his illegal activities. Okay, what could it be? For example, just a simple example, he might, for example, be injecting Alice's computer with a ransomware, and he might be asking for a ransom, say something like, pay me $1 million in Monero, or I'm going to destroy all of your files. And Monero is a privacy prison cryptocurrency protocol that the user identities and the transaction history is hidden from the rest of the world. So to hide his, for example, illegal financial activities, Bob, who is the adversary in this case, might be exploiting this privacy features that are used in the Monero cryptocurrency. And we actually already know that this is happening with many cryptocurrencies that are used today. Okay, so to kind of circumvent this problem in practical applications, what we may actually want is an auditable privacy prison protocol where we are going to introduce this authority into the picture. Now this authority will have special powers, and in particular, he will be able to kind of break through this anonymity shield, and he will be able to say, okay, that's actually Bob who is misbehaving or who is kind of conducting some illegal transactions. Okay, and in particular, this authority will have a secret trapdoor, and we'll use that trapdoor to be able to kind of break this anonymity or privacy features that are implanted in the protocol. Okay. And this authority might also be able to see the exchange messages. So he might do either or both of them together. Okay, and it's important to note here that only the authority is able to do this, and the ordinary users cannot actually break the anonymity or the confidentiality of the protocol. Okay, and there are actually many examples where this accountability or auditability feature is needed. So I already mentioned about blockchain and cryptocurrency protocols, and this is the application that we focus on in this work. There are also already cryptographic schemes that have this anonymity, sorry, that has accountable anonymity features already inside them, such as like accountable ring signatures and group signatures. And there are further higher level protocols like fair exchange, e-boarding and so on, where we would want this accountability or auditability feature. Okay. And many existing protocols are actually built on these commitment schemes that I already mentioned that is used to hide secret protocol information. And usually these commitment schemes have a compression feature, and they don't have a decryption feature in general. Okay, which stems from the compression. So by default, there is no way to recover partial secret information, even if you want to have this or enable this auditability or accountability feature that I mentioned before. Because you cannot, I mean, once you commit to something, you cannot actually reveal some secret information about that, due to the lack of this decryption feature. Okay. Of course, we do know a primitive that has a decryption feature, which is an encryption scheme. And why don't we just switch to an encryption. And the main reason, so there are multiple reasons that I'm just going to mention the main one here, is because many existing protocols require commitment to a very long auxiliary message that is actually not necessary to be recovered in decryption. So if you want to switch to an encryption, this will mean that you will need to encrypt a very long high end for the message using an encryption scheme, which cannot provide a compression. And this will lead to a significant communication overhead. Okay. And this is precisely the problem that you're trying to solve in our work. And our goal is to enable partial decryption in a verifiable manner. And this one, we will be decrypting partial decrypting a commitment scheme and not switching to a full encryption. Okay. And verifiable in this setting means very similar to this verifiable encryption that you may have heard of, which basically says that users cannot just simply avoid decryption, because we will ask them to kind of prove that the commitments are well formed. And then the decryptors will always be able to decrypt a verifiable encrypted message. Okay. Okay, so let me then summarize our contributions in this work. So as I mentioned, we first formalize this VPDC notion, verifiable partial decryptable commitment notion. So this is an extension of a commitment scheme that has a matching NIST proof. And we want to provide partial decryption. And then we have generalized analysis of decryption feasibility for relaxed NIST proofs. I'm not really going to talk too much about what a relaxed proof is or what an exact proof is. But our results are built upon results from Lubashevsky and Neven from Eurocrypt 17. And effectively, what our results say is a kind of like a lifting term that says that if you can decrypt in the non-relex case, then you can also extend this to the relaxed case. And this result applies to a wide class of Fiat-Chemir protocols. And then the next thing, which is kind of like one of the core parts of our paper, is a novel decryption for this lattice-based commitment scheme that I mentioned before, hash message commitment. And here you will be utilizing a gadget vector to enable or against that decryption in this compression, in this commitment scheme that compression happens. In general, I'll talk about, sorry, the final part of our paper is about an application in this so-called ring CT approach that is employed by Monero cryptocurrency. And this will be the introduction of matrix AU that extends this matrix protocol from CCS 2019. So in this talk, I'm not going to talk about relaxed proofs, and I'm not going to talk about, therefore, the generalized decryption feasibility results, and I'm going to refer you to the paper for that. Okay, so let's discuss a bit about this VPEDC primitive. This will be an informal discussion. Let's start with an ordinary commitment scheme and quickly recall how it works. So it has three functions, a keyjam function that outputs a commitment key. We can commit to messages where this commit function outputs a commitment capital C, along with an opening of this commitment that we call O. And then we have an open function that checks whether that opening is valid for a commitment or not. And two core properties of a commitment scheme is binding and hiding. So binding basically says that you cannot open the commitment with two distinct messages. This is computationally hard, and hiding basically means that the commitment does not leak information about the committed message. In many protocols, we also want a homomorphism property, which says that we have these two operations, multiplication, and addition. So this is O plus and O times, where we can take a scalar alpha and then two commitments C1 and C2. And we want this to be equal to the commitment of alpha times the message of the first commitment M1 plus the message of the second commitment M2. Okay, so these are the standard things or common things or commitment schemes. We're not really going to talk about or defined NISC proofs and non-interacted randomness proofs. And we are basically just going to assume the existence of a matching NISC for the relation that is given here. And this relation is a standard commitment opening relation that says that the prover knows an opening O for a given public commitment C, such that C and O, when given as an input to the CO function, returns true. Okay, so this is a very standard NISC proof. And this NISC we will satisfy the standard properties of completeness, soundness, and zero-knowledge. Okay, let's now really look into how we now extend the commitment scheme to the VPDC. Okay, so as I mentioned, we will assume that there is a matching NISC that's accompanying the commitment scheme. And we will actually, as a first step, we'll be splitting the message space of the commitment scheme into two parts. So M will be product of D and U, capital D and U. And D will be denoting the decryptable message space where U will denote non-decryptable or the auxiliary message space. Okay, and as I mentioned before, in many practical protocols, the entropy of this U space, this auxiliary message space, is much higher than the entropy of the decryptable part where you want to recover in decryption. Okay, so as an additional function, we will have a trapdoor function, which will basically just take a commitment scheme and embed a trapdoor into it. And then we will, of course, have a decryption function, which will partially decrypt the commitment given commitment C to recover a message in this D space. Okay, so it's only a subset of M, so we are not recalling the full message of the commitment scheme, but we are just recalling a part or a portion of the full input message. Okay, so this partial decryption as opposed to full decryption is really a feature in this setting and not a drawback that will allow us to compress the auxiliary message part. Okay, because we all know that if you compress the message, then we cannot fully recover that in decryption. Okay, so that's why we will get both compression as well as decryptability in a single primitive. Okay, let's now look at the actual properties of a VPDC. So we will first have a succinctness, which will say that the bit length of the commitment scheme, sort of a commitment output, will only depend on the bit length of the auxiliary message in a polylogarithmic fashion. Okay, so it will not grow linearly with the bit length of the auxiliary message. Okay, and this is literally the main property that distinguishes VPDC from a verifiable encryption or a proof of plaintext knowledge. If you know them, because in an encryption setting, so these two things, very hard encryption and proof of plaintext knowledge are built upon encryption schemes, which means that you cannot get this succinct notion, even for the auxiliary message if you want to do it. Because you cannot compress the message at all in the encryption case. And we have this, what we call a small integer decryptable message space property, which basically says that this D space that we defined before this decryptable message space will basically just consist of integers. Okay, and this is really the case for our application and that's why we are introducing this property. And we actually have more generalized decryption we show in the paper that it's actually possible even without this restriction. And then we have this key in this new issue with property, which says that the trapdoor commitment key is computationally indistinguishable from an ordinary commitment key of the commitment scheme. And then we have a stronger binding property that we call trapdoor binding, which says that even when the adversary is given access to the trapdoor, still the binding property holds with respect to the trapdoor commitment key. And this is really important for our application because we really want that authorities not be achieving in the protocol, because we prevent authorities from cheating, even though they have access to trapdoor. And we have a decryption soundness property, which kind of effectively says that the decryption function returns the same message used to construct a commitment. And we have a decryption feasibility property that roughly says that the decryption function runs in reasonable time. Okay, again, since I'm not talking about this relaxed zero knowledge proofs in this talk, this notion of reasonable, it will be a way in this talk and I'll refer you to the paper for the concrete definition for that. So let's just know that in the case of relaxed proofs, there are further complications arising and we show how to solve them in our paper that you can have a look at. So let's now see how we construct this VPDZ primitive from lattices and we will be building upon this HMC commitment scheme. So let's first look at how HMC works. So we have two matrices, two random public matrices, or a polynomial ring that we denote by R2 with a variable X. Okay, if you want to commit to a message M, which needs to have small coefficients, then we are going to sample a randomness with again small coefficients and just compute A times R plus B times M. And this output mod Q will be equal to the commitment. So this is, as I mentioned, is a very standard commitment scheme used in many lattice-based protocols and its security can be easily shown from module C and module LWE problems. And as the first step, so this picture, as you might see, doesn't fully capture our setting in the VPDZ where we split the message into two parts. So to make it more clear, we will slightly shift the view and we will split this B matrix into two parts, B and C, and also this message into M and U. Okay, so M will be decryptable message, which often has very low entropy, and this U will be the auxiliary message, which often has very high entropy. Okay, but still, the randomness decryptable message and auxiliary message, they all have small coefficients. Okay, and there are already existing standard opening proofs for this HMC component, so we don't need to construct them from scratch. And so they are kind of like very standard protocols. Okay, so first we need to add a tractor into the commitment key, and let's see how we do this. So first we are going to assume for the simplicity in this talk that M is just a bunch of bits. Okay, this M matrix, sort of M vector that we want to recover in decryption. Okay, so the U part, the auxiliary part can have much more entropy, so it doesn't have to be binary, but the decryptable one we are for now assuming that it's binary. Okay, in the paper, you also show a generalization where M is not necessarily binary. Okay, so for tractor embedding, we are going to update the last rows of these ABC matrices. Okay, so let's assume that A prime, B prime and C prime are the parts of ABC where the last rows are removed. Okay, and the last rows we are going to kind of generate them in a specific manner. Okay, and in particular, they will just be LWE vectors. Okay, in particular, we take the matrix, this random matrix A prime, multiply it with a secret vector S prime, and then we add some loads. Okay, in particular for V0 be it, E0 and then E1 and then E2 for the other. Okay, but with only one difference, where the second one is W1 will also have this additional term, that is T bar times a gadget vector G. Okay, so T bar is this parameter that's also used in regular encryption, which is Q divided by T for a parameter T that defines the message space. Okay, and this gadget vector is this power of two vector like one, two, four up to a power of two and then X2, X4, X, and so on. Okay, since we are working over a polynomial ring, we have this multiplication by X and X2, X3 and so on. Okay, so this T bar times G part will be important for us, so that will allow us to recover the message. So if you are a bit confused with this picture, don't worry about it. So what we really want to do is to set a trapdoor S, which will just be simply this minus S prime. That is the secret for the LWE, concatenate with one. Okay, so that's the trapdoor S. And we just want that S times this trapdoor commitment key is almost equal to or approximately equal to a bunch of zeros for the first part. And then T bar times G for the second part, and then follow up by zeros again. Okay, so that the randomness gets multiplied by zeros, the message gets multiplied by the gadget vector, and then again the auxiliary message gets multiplied by zeros as well, roughly. Okay, so this is how we embed the trapdoor into the commitment key. And then let's now see how we do the decryption. If we now have a commitment, let's say H, under trapdoor commitment key. And if you multiply this commitment or we compute an inner product of this commitment with S, then we are going to get, so as we just showed before. So in this picture here, so we will see that this A and C parts will be cancelled out and they will just contribute to an error term, which will have small coefficients. And then the message will get multiplied by the G matrix. Okay, so we will get something of the form T bar times G times M plus E for E with small coefficients mod Q. Okay, so as in the usual regular style decryption, we can just round off this short error E. Okay, and recall that T bar was equal to Q divided by T, so it's large so we can just round off the error. We are going to end up with something of the form T bar times GM. Okay, we can just divide it by T bar to get something that only depends on the gadget vector and the message M. Okay, and this will just be a polynomial in RT. Okay, recall that G is specifically constructed and M is binary. So this multiplication will make sure that this is a polynomial with coefficients that does not exceed T. Okay, that's how we specifically constructed this gadget vector. Okay, and in particular, the bits of the coefficients of this polynomial F will simply be representing the message. Okay, due to the construction of the gadget matrix, which we can easily recover in decryption. Okay, so this is how we do partial decryption for this HMC-based VPDC in our setting. And of course, this is not just all that we show in the paper. We extend this decryption method to work with relaxed and open improves. And in particular, we make use of our generalized decryption feasibility results to do the formal analysis of this extension. And then we formally prove the aforementioned VPDC properties like the soundness against relaxed proofs and the succinctness property that we discussed before. And we also have a more generalized decryption algorithm where the message does not need to be binary necessarily. It still needs to be short relative to Q, the module of the system module of Q, but it doesn't have to be binary. Okay, so as the last part, let's discuss about our matrix AU application, which will be an audible version of this matrix protocol. And for this, let us first recall how this matrix protocol worked. Very briefly, I'm not going to get into the technical details at all. So this matrix protocol is a private blockchain payment protocol that is based on the so-called ring CT approach. And the string CT approach is used in Monero cryptocurrency that I mentioned before. And matrix is a lattice-based instantiation of the string CT framework. It hides the payer and payee identities and the transaction amount. And then in particular, to hide the real payer among end users, it makes use of a ring signature or a one-out-of-end disproof. And then in this one-out-of-end proof, it uses an HMC commitment to encode the real payer's index that we can denote by L. And this encoding is just done by committing to the unitary representation of L, which means that you're just coming to a sequence of bits that represents this index L. And moreover, the same commitment also encodes the bits of the output amounts. And the reason that we are committing to these bits is to hide the transaction amount. So we have this one commitment that's encoding the user index as well as the transaction amount in binary format, which exactly matches what we had just seen in our decryption assumption. So the message was binary and we assumed that the user was using an HMC commitment. And there is already an opening proof and valve from this proof as part of this matches protocol, which means that the protocol already proves that this commitment contains a bunch of bits and it is valve for it. And then already the protocol has kind of like the NISC proofs that we want to have as the matching NISCs. So all we need to do is to replace this ordinary HMC user matrix with this VPDC, HMC base VPDC, we already constructed in the previous part. And then this will effectively extend the ring signature in matrix to an accountable ring signature or a group signature where an authority can decrypt or can de-anonymize users. And as I mentioned, we don't need to modify the NISC at all thanks to the this VPDC properties like key mis-negotiability and trapdoor binding and so on. And we only need to do very minor modifications to the protocol descriptions and as well as the protocol parameters. And we can very efficiently run decryption for a very large message space of more than 2 to the 128 elements. And we can also apply our techniques to the newer version of this matrix protocol that is called matrix to plus. So that's a more efficient version of matrix. So we can make that protocol auditable as well, formally auditable. And we have nice additional features in terms of auditability. For example, we can have multiple auditors that can audit the same transaction without revealing their individual trapdoors. And we can also allow each user to choose their own auditor or some users may choose to be not audited at all. And we can also let the system enforce auditing so that people cannot avoid auditability. And in this case, we just need to make sure that the verification checks that the non-auditable transactions failed in verification. And basically this is just done by checking this commitment key, whether it's the trapdoor one or the ordinary one. And here is a comparison of matrix and matrix AU in terms of communication. So this is for a different anonymity levels and for a different number of inputs and outputs in the protocol. So we can look at the proof size first, and we see that in all the settings, there's a very little overhead, just about 30%. And in terms of the system parameters, the public key size remains exactly the same. And only one of the system moduli is increased by two bits, about two bits. Again, for computation, there is very little overhead. So the key gen and transaction gen and verification functions have very little overheads. And this new function is trapdoor generation and audit, where also one run very fast. Okay, so that's all I wanted to say. So here is some references that I mentioned during the talk. And the full version of our work is available on IECR's e-print that you can have a look. The source code of this matrix AU application is also available in this link. And if you have any questions, please do not hesitate to email me. Thank you.