 Okay. Hi, everybody. I'm Shofra Kuto. And I'm going to present implicit zero-knowledge arguments and their applications to the malicious setting. This is a joint work with Fabrice Ben-Amouda, David Pocheval, and Houtté Cui. So you all know what a cryptographic proof is, a proverb knowing some witness which allows to verify in polynomial time that some word X does belong to some NP language L, is interacting with a verifier. And at the end of the interactive protocol, the verifier should be convinced. Of the truth of the statement, X does belong to L. So the two security property we basically want from such a proof are its correctness and its soundness. And additionally, in the case of zero-knowledge proof, we're interested in another security property which is informally that no information leaks at all on the witness held by the proverb when he interacts with the verifier, except from the fact that the statement is true so that the witness exists. So more formally, this is stated by requiring the existence of an efficiency emulator which is indistinguishable from a non-sprover that it emulates, but which runs without the knowledge of the witness W. Zero-knowledge proof are various applications in cryptography. One of them being secure two-party computation. So in secure two-party computation, you have two players, Alice and Bob, who are interacting to compute a non-function of their joint input. So they are exchanging messages, like Alice could be sending some message MA which shall belong to some NP language LA, and then Bob should answer with some message NB which shall belong to some NP language LB. And then the protocol goes until both players learn the output of the protocol and nothing more about the input of their adversary. But it might be crucial for the security of the protocol that MA does indeed belong to LA. You can think, for example, as MA being an encryption of a bit, and when Bob receives a ciphertext, he cannot check whether this does indeed encrypt a bit or not, but he might be computing the next flow, MB, from this ciphertext, and if the ciphertext is not encrypting a bit, it might leak crucial information that should remain hidden. So to ensure that the protocol will remain secure against Malishu's adversaries, which might deviate arbitrarily from the specifications of the protocol to try to gain information that should remain hidden, the classical way is to use zero-knowledge proof. When Bob received Alice's flow, MA, he poses the protocol before sending his next flow. He asks for a proof of the statement MA does belong to LA. And this proof will have typically a three-move structure, like commitment, then Bob sends a challenge, and then Alice sends a response. And only when Bob checks a response, it can continue the protocol without compromising the security of its input. So this encrypts a blow-up in the round efficiency of the protocol, a blow-up in its interactivity by a factor of at least three, and it can be more in general protocol. But the good side of zero-knowledge proof is that they can be based on a wide variety of assumptions, and in particular, widely studied assumptions such as DDH or Delina. On the other hand, if we are looking for more round efficiency because interactivity is a concern in reality, and it's a major bottleneck for the time efficiency of the protocol, one can settle for non-interactive zero-knowledge proof. So both players are playing in the common reference string model. And now in this model, Alice can construct a proof which consists of a single flow from the prover to the verifier, and she can append this flow to her flow MA. And Bob just checks the flow and can directly send the next message. And so there is no loss in the interactivity. An en-route semi-honest protocol becomes an en-route protocol secure against malicious adversaries. The downside of non-interactive zero-knowledge proof is that they require stronger assumptions than classical zero-knowledge proof. You will have to work with the random oracle model which provides only a heuristic level of security or to use pairing-based assumptions. And pairing-based assumptions imply that you need to work on elliptic curves equipped with a pairing. And so you have stronger assumptions and you might lose inefficiency because the best elliptic curves with a pairing in such a curve, computing an expansion is like three times slower than computing an expansion in the best non-elliptic curve without a pairing. And that is the fact that pairing themselves are very costly operations. So in this work, we are trying to get the best of both worlds by constructing a new kind of zero-knowledge proof, which is called implicit zero-knowledge proof, which have the very good round efficiency of non-interactive zero-knowledge proof, while requiring only very widely-studied assumptions, such as the DDH assumption. And so an implicit zero-knowledge proof will be a key encapsulation mechanism. So after Alice sends some public IPK, Bob computes some key K, and he uses this key to mask his next flow MB. And he also sends some encapsulation of the key which is constructed from the IPK on the flow of Alice, MA. So the security property of the IZK will state that if MA is indeed an element of LA, then Alice can recover the key K from the encapsulation. So she will be able to unmask the message MB sent by Bob, and then to continue the protocol, while if MA does not belong to LA, then we require that the encapsulation does statistically mask K so that what Alice receives is only a completely random-looking tuple of elements. So the zero-knowledge property is implicit in the sense that Bob does not know whether Alice tried to cheat or not, but if Alice tried to cheat, then he is sure that she will only see random elements, and then she won't learn any crucial information. So our tool to build those implicit zero-knowledge arguments are smooth-prolative hash functions. Smooth-prolative hash functions were introduced under the name hash-proof system by Cramer on Shoves as a tool to convert NCPA encryption skins into NCCA encryption skins. And as you will see, they really look like what we would like to use, but we cannot use them directly. So we have four algorithms. One of them gives us a hashing key that you can think of as a secret key. And another algorithm will give us a projection key that you can see as some public key. And we have two functions to compute a hash value from a word which should belong to some language L. So first function hash takes as input the word and the hashing key. The second function projash takes as input the projection key, which is sort of a public key, the word and the witness, which ensures that the word does indeed belong to L. And our security requirement is that if M does indeed belong to L, then the two hash functions will provide us the same result, will give the same hash value when computed on M. While if M does not belong to L, then there is no such witness W. And it is required that the hash value computed from HK does look completely random from the viewpoint of an adversary, even an adversary who knows the projection key HP. So this looks like what we're looking for because we could think we could use the hash value as our key K to mask our flow Mb. And we could use the HP, the projection key, as our encapsulation. However, this does not work. And to illustrate this, we will look at some simple example. So I mentioned earlier the simple case that you can think of the message M as being an algorithm encryption of a bit B. So the witness, which ensures that M is indeed an algorithm encryption of a bit, is the randomness R used in the encryption and the bit B. So your hashing key will be only a tuple of random elements here. And the projection key is a tuple of group elements constructed from the hashing key. And you have the two functions that give the hash and the projash. And if we do the mask by looking at the projash value, in the exponent, when we compute the projash, you will have some terms related to T3 and T4, which are elements of the hashing key that do not appear in the hash value, times B times B minus 1. So if B is indeed a bit, B times B minus 1 is 0. And all those terms related to T3 and T4 will disappear. And then you will only be left with U to the T1 times E to the T2, which is exactly the hash value that you're trying to compute. Else, if B times B minus 1 is not a bit, which means that M is not an element of the language of encryption of bits, then you will have something which is completely random, even if you know, compared with the hash value. So even by knowing the projection key HP, you get absolutely no information statistically on hash. However, this is not enough to ensure security against malicious adversaries in a semi-honest protocol because smooth-trative hash function does not have the zero-knowledge properties that we want. Let's look at what happens if now the verifier, instead of sending a correctly bit projection key HP, sends correctly the first element, and then two uniformly random elements, row 1 and row 2. Then look at the project value. The two last random elements are raised to an exponent depending on B. So if the prover is being honest, and if B is zero, then the two random elements are raised to the power of zero and they just disappear, and we have exactly the same case in the honest example. So everything goes as expected in the protocol. But if B is not zero, then you have, when you compute the project, you have two completely random elements that makes the project value completely random. So you just cannot unmask the flow, you cannot recover the hash value. And the verifier could just wait during the rest of the protocol to check to see whether it looks like the prover is just manipulating random stuff that might be seen, it depends on the particle or protocol, or if it is playing the protocol correctly. So a malicious verifier can actually learn the exact value of the bit, which is part of the witness, who shall remain hidden. This attack shows that the smooth-portive hash function is not zero-knowledge. In particular, we cannot construct a simulator which could simulate all the elements of the smooth-portive hash function without knowing the witness RB. But it will still be our base to construct implicit zero-knowledge arguments. And before I describe the full construction, I will give some algebraic framework. So the algebraic framework can be seen as a restricted case of a more general algebraic framework, which is called Diva's Group, which was introduced by Cramer and Schupp. And in this framework, we introduce some new operation, Ballet, which you can see, which is a scalar product in the exponent. And the language is now defined by some matrix, which depends on the word M, and we extend the word on the witness to some tuple. And as you can see, all the elements of our smooth-portive hash function can be simply computed as a scalar product in the exponent between those elements. So this equips us with nice algebraic property for smooth-portive hash function. And the advantage is that most, if not any, every non-smooth-portive hash function do indeed fit in this framework. So, now let us take some language on which we will construct some implicit zero-knowledge arguments. We have a matrix, gamma, which defines a language. The first thing we need to do is to ensure that a simulator, which does not know the witness W, which ensures that the word M does belong to the language L, this simulator shall be still able to simulate. So this is done by transforming our first matrix into a new larger matrix, which corresponds to a new language, LT, which is the language either M does belong to L or the ICRS, G prime, H prime, U prime, E prime, which is given here, is a DDH tuple. So when ICRS is not a DDH tuple, which is a normal setting, then LT is exactly the same language than L. But in the trapdoor setting where the ICRS is replaced by a DDH tuple, which is indistinguishable from the normal setting under the DDH assumption. And now the matrix gamma, the language LT, is a full language. Every word fit in this language and the witness is just R prime. So with this R prime, our simulator is now equipped with a witness to simulate the implicit zero-knowledge proof. But this still doesn't prevent the attack of a malicious verifier trying to maliciously build our project as a projection key, HPT. And we will make sure that the verifier will construct it correctly, but we cannot use the zero-knowledge proof to do so because we will lose a round efficiency that we are trying to get. Instead, we take the second equation, which define HPT, and we transpose everything. And now you can see that HPT does really look like the first equation. We have some word, HPT transposed, which is equal to some matrix, gamma T transpose, which define some language. But let some witness, which is HKT transposed. So with this new equation, which really looks like, which does immediately fit in the framework for smooth-pretty bash function, we can construct another smooth-pretty bash function in the other direction. And with those two interwoven smooth-pretty bash functions, it seems that with a new transpose predictive key and T hash and T projash, we could ensure that the word HP won't be maliciously constructed. However, doing so breaks the soundness of the first smooth-pretty bash function because you can, if you look at the T projash value, it leaks an additional information on HKT. Some information leaks from HPT with the second equation of the first column, but the soundness states that there is no problem. Everything remains statistically hidden. But with this new equation, then we can be screwed. Then the malicious prover called, try to maliciously build TPT, and we have like a circular problem. And this would leak information in the hashing key. But we can avoid this by relying on a two-universality trick. And with this two-universality trick, the size of everything is multiplied by two. And after the prover sent his first flow, the verifier picks value XI, uniformly at random, and the smooth-pretty bash function won't be based on the word M, but on an extended word M, which is an extended word, M comma C times M. And so it won't, it isn't, it is impossible for the prover to anticipate the word on which the smooth-pretty bash function will be based, even though it can still send the element related to this smooth-pretty bash function. So it cannot construct TPT in a malicious way with overwhelming probability. So if we combine all of this together, everything works, and we can prove that this allows us to reach our implicit zero-knowledge proof. So we go back to our semi-honest protocol. Alice and Bob are interacting, and to ensure security against malicious adversaries, Alice sends for some public key, which is TPT prime. And Bob, a mask, is next flow with some key K, which is constructed from the hash value HT prime and the transverse projash value T projash T prime, which means that Alice will be able to recover K if and only if MA does belong to LA, and the projection key was correctly constructed. And the HPT prime is our encapsulation of the key K. So to sum up, we've introduced a new card of zero-knowledge argument, implicit zero-knowledge argument, which allows us to ensure security against malicious adversaries. And we have a neurooptimal round efficiency, an end round protocol in the semi-honest model will be converted into an end plus two round protocol in the sector against malicious adversaries, but we can do so by relying only on widely studied assumptions, such as in the example I described, DDH, but you can think of nearly any other assumption. Thank you for your attention.