 Okay, hello everyone, my name is Kai and I will present the paper bringing order to chaos a case of collision resistant chameleon hatches. The paper is joined work with David Dela from DF in Zurich and also Daniel Slamanik from the AIT in Vienna. I am currently independent, but the work was done while I was working with the TÜV Rheinland in Germany. To make things a bit more personal, this is us, we have David, me and Daniel. We may meet each other at the next conference next year, so hopefully at least after the crisis. However, without further ado, let's start the talk. I will first introduce chameleon hatches from a very high perspective. We will later go into more detail. So chameleon hash consists of five algorithms. We have a parameter generation algorithm. We have a key generation algorithm, which outputs a key pair, so a secret key and a public key. We have a hashing algorithm, which not only takes a message M, but also some public key. And it outputs two values, some hash value H and some randomness R. Then we have a checking algorithm, which takes this input a public key pk, some hash H, some message M and some R. And it essentially checks the consistency between these four values. Finally, we have an adaption algorithm, which is also called collision find. And this algorithm takes this input a secret key, some message M, some new message M prime, some hash H and some randomness R. And it outputs some new randomness R prime. This algorithm essentially allows finding collisions. So what do we mean by finding collisions? If we hash honestly, we have H, R, pk and M, of course the check algorithm should output true. However, the adapt algorithm now allows for an old hash value H for the same pk use at checking, that the new message M prime, with the new R prime, also passes the checking algorithm. So pk and H are the same, but the message and the randomness are new. That's what we call a collision. Camino and hashes come into settings. The first one is a public coin setting. And the second one is a secret coin setting. In the public coin setting, checking essentially means recalculating the hash. While in the secret coin setting, the randomness R is considered a check value. You can also say witness or approve. For the sake of the paper and the stock, we only consider the secret coin setting as it is more general. Jumping ahead, as we have a secret key which allows finding collisions, we of course need some kind of collision resistance notion. Keep that thought for a moment. We'll come back to that later because this is actually the main part of the paper and the stock. So to visualize things, assume Bob on the right-hand side here has generated his key pair. So he has some secret key and some public key. Further, assume that Alice on the left-hand side here knows Bob's public key, has some message he wants to hash and generate a fingerprint. She does so by adding some randomness and then sending the fingerprint plus message plus a randomness to Bob. What Bob can do now is find new randomness for some new document, such that the fingerprint is still the same, meaning that for his new document and his new randomness, but the old hash value and his public key check also outputs through. This seems to be a bit odd, but think of trapdoor commitments. If you simulate the commitment, you put in some random value and once the value becomes known, you need to put into the commitment. You somehow need to find randomness such that everything is smart or is indistinguishable for the adversary. Same idea for chameleon hashers, but with a slightly different scope. We'll come back to that later. I'll first show you how the rest of the talk is structured. Next, I'll show you our motivation and our contribution. We will then deep-dive into chameleon hashers, which also includes a new unfortunately notion, so a collision distance notion. I will then present how the different properties we will come to soon are related to each other. Then, I will present our construction, which achieves this strong collision resistance notion. Finally, I will show you that the kind of collision-resistant notion used has some serious real-world impact. Why chameleon hashers? Chameleon hashers are actually quite frequently used. This is just a small exempt here. They use in signature schemes and encryption schemes and whatnot. It's a very useful tool, which you should have in your toolbox. However, if you take a look at all the papers around, there seems to be no agreed upon framework. Some use tags, some use identity-based encryption, some are in the public coin setting, some are in the secret coin setting, some don't, and so on and so on and so on. However, this also means that, of course, the security notions differ quite a lot. I guess the reason for that is that if you use a chameleon hash, it's a very tailored for a specific application. We want to tackle that situation and want to present a comprehensive framework. Also, a very strong resistance notion, which subsumes everything else far. Also, show how different relations flying around currently are related to each other. Do you need to prove everything from scratch? Yes or no? We then show that, actually, it's very easy to construct a chameleon hash with very strong resistance notions. And finally, as I told you already earlier, that this is just not only some research topic, but it also has some real-world implication. So let's deep dive into chameleon hashes. First, I want to stress that we decided to group things into three distinct groups. The first one is collision resistance, which is an unfortunate ability notion. Then we have indistinguishability, which is an unfortunate ability notion. And finally, some odd or rather odd definition, which is also an unfortunate ability notion. So let's go to the first group. So first, I want to introduce weak collision resistance, which is actually our wording, because this definition comes from the very first paper about chameleon hashes with Kraftschick and Rabinit and ESS2000. The idea is that the adversary gets access to a public key, which is honestly generated, and it needs to output a collision. So two distinct messages, but still verifying for the same three-up print. Important here is that the adversary does not gain access to any collisions. Think again of Petersen commitments. Like I said, if you simulate stuff, you put a new randomness, but the old randomness is never seen by the adversary. However, that also means that if, for whatever reason, the adversary does gain access to a collision, all security guarantees are lost. Think again of Petersen commitments. If you see a collision, you can extract the exponent and then the binding property of the commitment scheme no longer holds. In the case of chameleon hashes, if you can extract the secret key due to a collision, it has a special name and it's called the key exposure problem. To partly tackle this problem, Atenezer et al. at EuroSMP 2017 introduced the notion of enhanced collision resistance. Here again, the adversary is initialized with a public key, but it also gains access to a collision finding oracle, so adapting oracle. The oracle exactly does what one may think with one exception. With one exception, it also logs which hash is arc varied. And the adversary only wins if it finds a collision, but the hash in outputs was never input to the adapting oracle. That means that once a collision for some hash h was seen, for that particular hash, old security guarantees are lost once more. That such schemes do exist is proven in the paper where we actually have a construction which allows finding arbitrary collisions, so new messages for a hash h once a single collision is seen. Contrary, we have standard collision resistance, which is very similar to enhanced collision resistance with the difference that the hash is no longer logged, but the old and the new message for the collision and the adversary wins if it can come up with some message m star, which was never seen by the collision finding oracle. Clearly, it still has to be a collision. Now we have ruled out that the adversary can play around with the message, but now the hash itself may still be mailable. Again, we show in the paper that such schemes actually do exist. What we really want, of course, is a combination of both, and this is exactly what full collision resistance achieves. Again, we have a collision finding oracle, but now that oracle logs tuples between... So logs pairs of hash message pairs vary to the adapting oracle, and the adversary wins if it can come up with a tuple never seen. This means that mailability for the hash and message are ruled out simultaneously. So that's it for the collision resistance notion. Let's go to the privacy notions. So indistinguishability in a nutshell requires that a hash randomness message tuple does not reveal whether it was created using the hashing algorithm or the adapting algorithm. In the standard definition, so standard indistinguishability, the adversary gains access, initializes with an honestly generated public key and gains access to a left or right-style oracle. And some collision finding oracle, I began it all that for now. And the hash or adapt oracle, so left or right oracle does exactly what one may think. It either hashes or adapts, and the adversary has to decide which way was taken. In the strong version, so strong indistinguishability, still the same idea with only two differences. Now the adversary actually knows the secret key, and those no longer needs access to the collision finding oracle. The left or right oracle still remains the same. Finally, we have fully indistinguishability, and here the adversary is actually even allowed to generate the secret key and public key. But the left or right oracle still remains the same. Finally, we have our odd brother. It's in its uniqueness. It's very rarely used, but we wanted to have a complete picture. So we'll come back to that later. The idea behind uniqueness is that for each message hash pair, exactly one randomness can be found by an adversary, even if the public key can be generated by the adversary. Okay, so much for the security properties. And now I will show how they are related. So for the collision resistance, notions are related as follows. Weak collision resistance is implied by any other definition, while full collision resistance implies all other properties. Standard collision resistance and enhanced collision resistance are not comparable, so they do not imply each other, while standard collision resistance plus enhanced collision resistance imply full collision resistance. In other words, this picture or diagram is complete. The next slide, no surprises, I guess. Full indistinguishability is strictly stronger than strong indistinguishability, which in turn is strictly stronger than standard indistinguishability. I guess that's rather obvious, but we wanted to have it complete, so we did it. And finally, we also compared how the different groups are related. And again, no surprises, they're completely independent. So in other words, if you have a chameleon hash, which is fully collision resistant and fully indistinguishable, that chameleon hash is not necessarily unique. Likewise, if you have a unique and fully indistinguishable chameleon hash, that chameleon hash may not be weakly collision resistant. Note that weak collision resistance is the weakest of the collision resistant notions and is implied by everything else. So if even that implication does not hold, the other ones do not hold either. Finally, if you have a chameleon hash, which is unique and fully collision resistant, it may not even be indistinguishable. Again, that indistinguishability notion over there is the weakest one, thus we have ruled out the stronger ones as well. So take away from this slide is if you prove or need to prove a chameleon hash secure, you need to address all three properties, or prove all three properties. Okay, let's go to the inscription. How do we actually achieve or can construct a chameleon hash, which is fully collision resistant? So from a very high level, we have a OR proof, which proves either that a hash is an encryption of the message, or I know that a secret key to some public key is known. And some public key is exactly the encryption scheme. So at hashing, you encrypt your message you want to hash with fresh random coins and prove that you know the randomness used to encrypt it. So the message is really in that cipher text. The other path in the OR proof is once you want to adapt things, then you no longer care what's in the cipher text, but you say, hey, I don't care, but I know the secret key to the encryption public key and I prove knowledge of that. So, and clearly tracking the validity of the proof or the hash is simply verifying the proof. To make our scheme secure, we require a simulation-summed extractable proof system. However, we only need a single extraction in our security proof. That means that we can use a Fiat-Chemier transform Sigma protocol using the compiler by Faust et al. For the used encryption scheme, we require two major properties. The first one is NCPA. The reason for that we only require NCPA is that we never encrypt or decrypt anything. And also what this is a formality, key verifiability. Key verifiability means that you first can actually prove knowledge of a secret key belonging to some public key and also that once you can prove knowledge of a secret key, that secret key decrypts all cipher texts to the same value. It's a formality. The formal definitions are in the paper. For the sake of this talk, you can think about or think Elgamal period. In the security proof itself for full collision resistance, we also require that the encryption scheme is perfectly correct and also that we have simulation sound extractability. For indistinguishability, we require the already set NCPA security of the encryption scheme and also the knowledge property of the proof system. To be perfectly honest here, in the paper we use a multi-challenge version of the NCPA definition, but it was shown that the MC NCPA definition is polynomial equivalent to standard NCPA, so there is no cheating or trapdoor here. So comparing our construction with some concrete parameters, we see that in the random oracle model with Elgamal, our construction is comparable to already existing ones at least the ones we took a look at. However, if we want to instantiate our blueprint in the standard model, then we can see the number of loop elements required explodes. However, our goal was not to improve here, but maybe future work, so consider at least a standard model instantiation as a feasibility result. And also note that our collision resistance notion is the strongest to date. So what are the implications for the real-world applications I promised? So recently, at Inezer et al. at EuroSNP 2017 proposed the idea of reductable blockchains. I will not go into detail on blockchains, but just as a primer here, the idea is that hash a block, append something, sum some data, hash it again and so on. So you have a chain of blocks. The problem is that sometimes the data additionally stored in the next block may contain data which should not belong there. For example, leak videos or so. So what you can do is instead of putting in the data directly, just put a hash in there, in particular chameleon hash. That means that even though the many, many new blocks have been appended, you can still change some values if you know the secret key. However, looking back at our different collision resistant notions, what about if you want to instantiate that with enhanced collision resistance? Recall, if you see a collision for a single hash value, you may be able to find arbitrary other collisions for that particular hash value. So there may be a problem here, depending on the use case of course. If however you instantiate it with the full collision resistant chameleon hash we proposed, then such a problem does not appear. So from our perspective, this feels more natural to do so. So what's the take home for you? Chameleon hashes are a very versatile and useful tool, so you should keep it in your box. Be aware that there are many different collision resistant notions around. And from our perspective, none actually captures what one would naturally assume from chameleon hashes. In this paper we have proposed a new and arguably more natural notion of collision resistance and also how one can simply and generically build such a chameleon hash with standard primitives. What is open work is if there are more or additional applications for chameleon hashes or even if with our strengths and definition of collision resistance if we can strengthen already existing applications, for example, on offline signatures or so. So I hope you enjoyed the talk. I wish you a nice year and thank you for your time. Bye.