 Welcome to the presentation of a paper towards tight adaptive security of non-interactive key exchange. My name is Roman Langre and this is joint work with Julia Hesse, Dennis Hofheins and Lisa Kohl. I will start my talk with an explanation of what non-interactive key exchange or for short Nike is. Then I will talk about previous results on the tightness for Nike. And then I will go into more detail of our work and present our first result, which is a tight Nike with large keys. Then our second result, which is a lower bound that shows that these large keys seem to be necessary. And finally our third result, which is a tight semi-adaptively secure Nike. Non-interactive key exchange or for short Nike is cryptographic primitives that works as follows. We have a key generation algorithm that every user can use to generate a public key secret key pairs. Then using a public key infrastructure, the users can get authenticated copies of a public key of every other user. And finally they can use a shared key algorithm to generate a shared key using their own secret key and the public key of somebody else. And when Alice and Bob both do this, they should get the same shared key. Now Nike isn't very interesting primitives because it allows you to get symmetric keys with minimal communication. And then it's beneficial because that means it is fast and it also has very little energy usage, which is important for battery powered devices. It is also a building block for several other cryptographic primitives, for example deniable authentication. Or together with a Mac, you can get an interactive key exchange and designated verifier signatures quite easily. Now I will talk about the security notion that we will consider in this talk. That is an adversary has several oracles that he can query adaptively as often as he wants. And the first oracle is to create new users and whenever he does this, he gets their public key. Then he can corrupt these users. That means he gets their secret key. Finally, he can reveal shared keys that is he selects two users and gets a shared key between them. And finally there's an oracle that he can query once where he gets the shared key between two users or a random value. And this goal is to distinguish between these two variants. Of course, the adversary must ensure that he has not revealed this shared key or corrupted any of these two challenge users before. Maybe more realistic security definition would be that the adversary can query this challenge oracle as often as he wants. And our work generalizes to this multi-challenge setting without additional security laws. But for simplicity in this talk, I will focus on the single challenge setting. Our paper uses for multi-challenge setting. Finally, I want to mention that there's another slightly stronger security notion that allows for dishonest key registration. That is the adversary can generate his own public key and then ask for shared keys between this public key and another user in the system. However, this security notion can be achieved generically from what we have here. Using a non-interactive zero-knowledge proof of knowledge. That's why we chose to ignore this additional oracle in our work. But for our first construction, we only need to prove linear relationships with this proof of knowledge. So it is quite efficient. Okay, so what do we mean by tight security? When we want to prove that our Nike achieves this security notion, we typically give a reduction to some underlying assumption. And this reduction guarantees that when we can break the scheme with probability epsilon using some resources row, we can break the underlying assumption with probability epsilon divided by L using, for a fair comparison, approximately the same resources row. And this L is called a security loss. In general, a large security loss L can be compensated by just choosing the security parameter larger. The disadvantage is that your scheme gets less efficient. So it's beneficial to look for schemes that have a small security loss in the first place. And this is captured by tightness. More concretely, we mean that with tightness that the security loss L does not depend on the adversary. So for Nike, this especially means that L does not grow with the number of users N that the adversary registers. An example of a Nike that probably everybody of you knows is the Diffie-Hellman Key Exchange. When we want to analyze this Nike in the multi-user setting, we have to guess both challenge users in advance, so at least the index of the query when the adversary spawns these users, and then embed a challenge in their public key. That means we get a security loss of N squared. And a work by Baader et al showed that this loss of N squared is indeed necessary, at least if the secret keys are unique given the public key. The first work that managed to get around this lower bound is the work by Hesse et al. And they only need to guess one of the challenge users and then can embed a challenge in their public key. And so they get security loss of only O of N. They also get a lower bound that shows that this loss of N is necessary for a large class of Nikes. In our work, we now look at the case where you allow the keys to get larger, grow for example with the number of users. Now both of the previous works cannot get any advantage of such large keys, so their tightness does not change no matter how large you choose your key. But our first construct is a Nike where larger keys give you less security loss. More concretely, if you allow your keys to grow with a number of users, then you get your tightness as low as O of log N. But when you want a constant size keys, your security loss will be O of N squared. We also give a lower bound that shows that these large keys seem to be necessary. However, our lower bound does not quite match our upper bound. It only shows that O of N is necessary for constant size keys, and you need a key size O of N to get constant tightness. Our lower bound applies to Nikes where our shared key is the inner product of the public and secret key. And this is the case for all known group-based constructions. I now want to explain our contributions in more detail. Our first construction starts as follows. We take the public and secret key of a very simple Nike. Here I will use the Diffie-Hellman Nike for example. In fact, we will later use a pairing-based version of the Diffie-Hellman key exchange. And then we append to these keys a vector of a lot of zeros, both in the public and the secret key. This will be our normal keys. That is, these are the keys you will get if you generate your keys honestly. Along with this, the reduction will use a few semi-functional keys. And these semi-functional keys will have in their public key a vector with one entry. So when nu is the dimension of this vector, we will be able to generate up to nu different semi-functional keys. A secret key will have a lot of random entries. And in the i-secret key, we will have random entries ri1 to ri nu. And they are chosen such that rij is the same as rji. Then we need that these normal keys and semi-functional keys are computationally indistinguishable. We will achieve this later by applying a basis change to these vectors and to a uniformly random basis. And then coding everything inside groups. The shared key will be the inner product of public and secret keys. Since we encode everything in groups, we will later need a pairing to compute this. Now, what's the point of having these semi-functional keys? Well, if you compute your shared key with two normal keys, you will kind of get the real shared key. That is the shared key you would also get with this basic nike. The same is true if you have one normal and one semi-functional key. But when both keys are semi-functional, you will get the real value plus rij. And this rij is uniformly random if secret key i and secret key j are both unknown. Now to get to the more concrete construction, I will use implicit notation. That is, a matrix or a vector in the square brackets means that all entries are encoded in the group. Which means that if we have some value a, we will not store a, but g to the power of a where g is the generator of the group. The underlying assumption for our construction will be the MDTH assumption for uniformly random matrices. That states that if I have a matrix D and a vector that is chosen uniformly random from the column span of this matrix D, both encoded in the group, then this is computationally indistinguishable to a uniformly random matrix D and a completely uniformly random vector u. This assumption is tightly implied by well-known standard assumptions, for example the two-linear assumption. And it is constructed to hold even in the presence of a symmetric pairing. And a symmetric pairing is a bilinear map that it maps g to the a and g to the b to gt to the a times b where gt is a generator of another group. So this is our concrete Nike. The public parameters contain a uniformly random matrix D and another matrix that we can write as m times D, where m is a symmetric uniformly random matrix. The public key or a normal public key will be just a vector from the span of D and a secret key m times this public key, both encoded in the group. This can be computed from a public parameters when you know this vector wi over zq, which you know when you generate it yourself, of course. And finally the shared key is just the inner product of the public and the secret key, which you can compute using a pairing. Semi-functional keys now look as follows. The public key is now a uniformly random vector and the secret key is m times this uniformly random vector. Now when you apply to all of these vectors a basis change that maps the column vectors of D and all the semi-functional public keys to the standard basis. Then you will get roughly the representation I started with in the beginning. To see security of this Nike we will look into the leakage of this matrix m and to see this more clearly we will also apply this described basis change transformation to m. So here's the matrix m. This diagonal should remind you that this is a symmetric matrix. And now the public parameters just leak a few rows and of course also the corresponding columns of this matrix m. A secret key of a semi-functional user will leak one more row and also of course the corresponding column of this matrix m. And the shared key between two semi-functional users will be just one entry of this matrix m. And this leaks of course this entry and also the correspondingly mirrored entry because they are the same. That means the shared keys between users with semi-functional keys are uniformly random even when we have adaptive corruptions. Of course as long as not the secret key of any of the challenge users is leaked. Now to prove security of our Nike let's call n the number of users and nu the size of the table entries which is roughly the size of the keys. And then we will apply a hybrid argument. In each hybrid we will change nu of the normal keys to semi-functional keys and so we can randomize nu squared shared keys. Thus o of n divided by nu squared hybrids are necessary. I suggest that we will need to switch nu keys from normal to semi-functional and later back. And this can be done with security loss only o of log nu. Due to a nu MDDA tree randomization argument we give. This leads to our total security loss of n squared times log nu divided by nu squared. Of course the large keys of our Nike are quite a big disadvantage but unfortunately we also have a lower bound that shows that these keys are necessary for a large class of nikes. And these large class of nikes we call inner product nikes and they are defined as follows. The public keys contain implicitly our d-dimensional vector x and also the secret keys contain implicitly our d-dimensional vector y. The shared key is now a function f applied to the inner product of the vectors contained in the public n-secret key. This captures all known group-based constructions for example dp-Halman key exchange, the work by Hesse et al and also our first construction. Here is a sketch on how this lower bound works. Our reduction always sends for public key at registration. That means that this vector xi is fixed for each user at registration. Now when the i's user is registered and this vector xi is in the span of the vector x from all the previous user then the reduction is already committed to the shared key for this user. And the situation that x is not in the span of the previous vectors can happen at most d times. That means that all users are registered and about half of the secret keys are opened. And the reduction is committed to a shared key among the remaining users with a significant probability. Now a meta reduction can unveil the shared key between two of the remaining users then rewind the reduction to the step before this and hopefully win the challenge with this key. When the reduction is indeed committed to the shared key that the adversary unveiled, he will win this game. When you analyze this carefully and repeat this last step over and over again you will see that a minimal security loss of n over d is necessary. That means for tightness you will need a large dimension d. We cannot prove that for dimension d you will also need public and secret keys that grow with d and it seems quite hard to have high dimension with compact keys. Finally, I want to talk about semi-adaptive security because what we have analyzed so far is adaptive security and we have seen that tightness is quite hard to achieve. On the other hand, selective security then there is a security notion where the adversary has to register all users in one shot and then specify the challenge pair before seeing the public key. In this setting it is very easy to achieve tightness because the reduction knows exactly where to embed the challenge. For example, the helmet key exchange is tightly secure in the selective model. In between this lies the semi-adaptive security model. There an adversary has to specify the challenge and keep it before making any corruptions that is any reveal of a secret key or a shared key but after seeing all the public keys. The final construction will work in this semi-adaptive security model. Our semi-adaptive security construction consists of two building blocks. The first building block is in fact a Nike I just presented but used in a different way. So let's look at this construction again but the dimension nu to one so we get compact keys. Then we can still switch all keys to semi-functional and the reduction can also output all of these secret keys. The only problem is there will be information theoretically nothing secret about the shared keys between two semi-functional users anymore when just one of these secret keys is leaked. But this is still useful because in the semi-adaptive setting the reduction first publishes all the public keys and then the adversary picks the challenge pair. And now the reduction can program the challenge shared key to anything the reduction wants as long as it's something that looks uniformly random to the adversary. Thus we have a tool that gives us some adaptivity because we can after publishing all the public keys decide on this challenge key. It's just that we will leak the challenge key to the adversary later. Our second building block will use the shared key as a tag for a so-called tag-based Nike. That is basically a Nike where you additionally get as input for the shared key computation at tag T. And you will have correctness as long as both users input the same tag T except for one special tag T star. And security will hold only for the special tag T star. Now this tag-based Nike doesn't suffer from the same limitations to achieve tightness as standard Nike because all the problems for achieving tightness come from the fact that reduction is usually quite early committed to a large portion of the shared keys and this relies crucially on the correctness property of the Nike. For this tag-based Nike we separated correctness and security because we have to prove security only in a setting where we don't have correctness. We can build that tag-based Nike with a tight security reduction from LWE using techniques for leveled fully homomorphic encryption. And as tag we can use the shared key from the first construction. So this gives us a tight semi-adaptively secure Nike. When we use our first construction with this parameter nu not EZ to 1 but to something larger we will get with this construction a Nike that is secure in a stronger security model. Namely in this model the adversary can ask for a sum of the secret keys before specifying the challenge key pair. Thus in this construction we will get a trade-off between key size and adaptivity of the security model. Now to summarize our work we looked at Nike and focused on the three properties tightness, adaptivity and compact keys and showed that we can achieve any two of these three properties. Our first construction achieves adaptivity and shows that the trade-off between tightness and compact keys is possible. Our second construction achieves tightness and shows that the trade-off between adaptivity and compact keys is possible. Thank you for your attention.