 Hi everybody, my name is Rune Fiedler. In this presentation I will show you how we have built a post-quantum version of an asynchronous deniable key exchange protocol and how we use this for the signal handshake. This is joint work with Jacqueline Brendel, Felix Günther, Christian Jansson and Dagle Stabila. First let's review the setting of instant messaging. Alice wants to initiate a conversation with Bob. If both of them are online at the same point in time, this is straightforward. However, what do we do if Bob is offline when Alice wants to initiate the conversation? In this case we can use a key server and Bob uploads a so-called pre-key bundle to the key server ahead of time. Then Alice, when she wants to initiate the conversation, queries the key server to get Bob's pre-key bundle. Using this pre-key bundle she can compute her first message and send it to Bob, who can read it whenever he's coming back online. Afterwards, both of them can keep sending messages to each other at their convenience. This feature is called Asynchronicity. Another feature that we want is mutual authentication. That means that each party should be sure that they are actually talking to the party that they think they are talking to. And the third feature that Signal is looking for is called Offline Denyability. Intuitively this means that if you have a transcript of a conversation, then you can deny that you were involved in creating this transcript. But we will go into the details of this more later on. The first few messages, so when they agree on a key, this protocol is called the extended triple Diffie-Hellman protocol or X3DH for short. Then when later on, when both parties keep updating their keys to send new messages, this is called the double ratchet protocol. And let's have a look in more detail at the initial handshake. Here we have again Alice and Bob, and both of them have a long-term key and an ephemera key. In addition, Bob has a semi-static key. And first Bob has transferred his pre-key bundle to Alice via the key server. The pre-key bundle of Bob consists of several Diffie-Hellman public keys, and Alice also has round Diffie-Hellman public keys and pairs them according to these arrows here. So Alice's long-term share goes with Bob's semi-static share, and Alice's ephemera share goes with each of Bob's shares. And then Alice sends her own two Diffie-Hellman shares to Bob so that Bob can compute the same Diffie-Hellman shared keys. This protocol, however, is not post-quantum, because it relies on the Diffie-Hellman assumption, which does not hold against quantum adversaries. So we can see that signal consists of two protocols. First the initial handshake, extended triple Diffie-Hellman, which is not post-quantum. And then there's the double-ratchet protocol, which can be replaced with a post-quantum alternative, for example, from key encapsulation mechanisms. This was shown by Alvernet Al at EuroCrypt 2019. And in this talk, we will focus on replacing the initial handshake with a quantum secure version. Key encapsulation mechanisms have been used as a post-quantum replacement for the Diffie-Hellman key exchange in several scenarios. So let's review chems to see if they fit for our purpose here as well. Bob has a key pair and sends his public key over to Alice. Alice then encapsulates against Bob's public key, resulting in a ciphertext and a session key. She sends the ciphertext over to Bob, who can de-capsulate the ciphertext by using his own secret key to learn the session key. Now both parties know the secret session key. How can we use this to construct a post-quantum version of Signal? We could try the following. Bob has three chem key pairs, a long-term semi-static and ephemera key pair. He sends over all of his public keys to Alice, and Alice encapsulates against each of Bob's public keys. She sends over the three resulting ciphertexts to Bob. The problem with this protocol is that there is no Alice to Bob authentication. And Bob doesn't know if this really came from Alice or if this was actually sent by Charlie. To remedy this, we could add a signature so that Alice signs the three ciphertexts. Now Bob can be sure that this message actually came from Alice, however Alice can no longer deny her involvement in this session, because only Alice herself can compute this signature. Though the idea of using chems for a post-quantum replacement of Signal has been around for a bit. Previously, Brandled Al have proposed to replace the initial handshake with a primitive they called split chems. However, this primitive turned out to be not instantiable. But let's follow the design idea from the previous slide of using chems in combination with some form of deniable authentication. And in this work, we use designated verifier signatures for deniable authentication. Separately, Hashimoto et al have used ring signatures for the same purpose. So how do designated verifier signatures work? Alice sends a message M to Bob in a manner that Bob can be sure this message was sent by Alice, however he cannot prove this fact to anybody else. So what Alice does is she can sign a message M with her own secret key and designates it to Bob by including Bob's public key into the signing algorithm. And this results in an Alice to Bob signature. Similarly, Bob can use the simulation algorithm to create a Alice to Bob signature by using his own secret key as well as Alice's public key. And DVS schemes also have a property called source hiding which tell you that for each attacker it is indistinguishable if a signature was created using the sign algorithm or the simulate or the simulate algorithm, even if the attacker knows both secret keys. There are some post quantum DVS instantiations which were not published in the mainstream cryptographic literature. So we believe they are in need of some more scrutiny. Instead we propose to build post quantum DVS schemes from two user ring signatures and we show in our paper how to do this. With this we have the advantage that we can make use of the big literature on post quantum ring signature schemes. After we have published our work there was an update to their work by Hashimoto et al. We show that you can build a two user ring signature from a DVS scheme. So it turns out two user ring signatures and DVS schemes are actually equivalent for some security notions. Now that we are equipped with a tool for deniable authentication, let's have a look at the core idea of our asynchronous deniable authenticated key exchange protocol. Both Alice and Bob have a DVS key in their long term key. And Bob also has a chem key in his long term key and ephemera key. It begins with Bob transferring his public key over to Alice. And now Alice can encapsulate against Bob's long term chem key and against Bob's ephemera chem key, resulting in two different chem ciphertexts. Next Alice can sign these two chem ciphertexts with a DVS scheme, resulting in an Alice to Bob signature over these two chem ciphertexts. With this we have Alice to Bob authentication while retaining deniability for Alice. Hashimoto et al. use the same principle in their protocol, however they are using a ring signature instead of a DVS scheme. As promised, now let's have a more detailed look at deniability. The signal specification says that the initial handshake protocol doesn't give either Alice or Bob publishable cryptographic proof of the contents of the communication or the fact that they communicate it at all. In other words, if there is a third party and this third party has access to private keys from Alice or Bob and this third party has access to a communication transcript that appears to be between Alice and Bob, then this transcript can only have been created by some party who has the legitimate private keys from Alice or Bob. And we have formalized this informal requirement in the following way. So if we want to have a transcript, there's two ways to get this transcript. The first way is Alice executes the protocol as specified on the previous slide by using the Iran algorithm and her own secret key. This results in a transcript and a session key. The second case is Bob uses a different algorithm which we call the fake algorithm. This fake algorithm takes Bob's secret key and adds the results in a transcript and a session key. And now the third party comes into play because the third party should not be able to distinguish if the run or the fake algorithm was used to create this transcript and session key and even if this third party has access to the private keys of both parties. This is the deniability definition that we introduce and let me point out that there is some design space to this deniability definition. In particular, does the fake algorithm require the secret key of Bob or can you run it with public data? Another option to modify this definition would be does the judge get all of the secret keys or does it have to decide based only on public inputs? And thirdly, is the judge allowed to interact with the participants during the protocol execution or does the judge only learn a transcript afterwards? There is a deniability definition which goes back to D. Raymond from 2006. And compared to their definition, our definition is weaker in the sense that our fake algorithm requires the secret key of Bob. However, our definition is stronger in the sense that our judge gets access to all of the secret keys. And we believe this to be very important to model the case of, for example, a legal judge which is able to subpoena you into giving up your secret keys, or if the judge is an ancient state adversary that can infiltrate your smartphone and thereby learn your secret keys. So all in all, these two deniability notions are incomparable, however, we believe ours to be more suitable for the use case at hand. And another downside of the definition by D. Raymond, is that proofs for their definition require some form of knowledge assumptions in all of the cases that are known to us. So for all the proofs that we know of. Let me also point out that there is some concurrent work by Dobson and Galbraith from last year. And they have lifted the extended triple Diffie-Hellman protocol to the setting of super singular isogenes. So they follow the same blueprint, but they rely on isogenic problems instead of the Diffie-Hellman problem. With this, they retain the same properties, but in addition, they get the quantum resistance which we were looking for. And there's also our full construction. So what you've seen previously was only the core idea, and our full construction is called SPQR, which is short for signal in a post-quantum regime. The full construction includes semi-static keys to model the case where ephemeral keys, which are provided by the key server, run out. Also, we secure our protocol against randomness exposure by the use of a twisted PRF. We prove the security of our protocol in a security model analogous to the original signal analyzers from Konkorn et al. And we also prove deniability of our protocol with respect to our definition. Let's compare the different constructions for the initial handshake protocol. So the first one is X3DH, which relies on the Diffie-Hellman key exchange and is therefore not post-quantum secure. It was recently shown to be deniable with respect to the definition of the Ramanu et al. And we also conjecture it to be deniable with respect to strong judges, so our definition. And it covers the full scope of what we expect. That means it covers real-world setting in which ephemeral keys may run out and where you need semi-static keys to cover for that. Then there are two protocols suggested by Hashimoto et al. Relying on cams and ring signatures. The first one is post-quantum secure, but not deniable with respect to the definition of the Ramanu et al. To remedy that, they added non-interactive zero-knowledge proofs on top to get this deniability. And we also conjecture both of them to be deniable with respect to strong judges, our definition, which is however not proven. Though both of them are not full scope. Then there's our construction, SPQR, which uses key encapsulation mechanisms and designated verifier signatures. It is post-quantum and deniable against strong judges, but not against the definition of the Ramanu et al with the weak judges. Though it is full scope. And both the constructions by Hashimoto et al, as well as our SPQR, are generic constructions, which you can instantiate with different cams and ring signatures, nizics and TVS schemes, relying on different problems. However, this is not the case for the last scheme, SIX3DH, which is hard-coded to use SIDH key exchange. Therefore it is post-quantum and also deniable with respect to the definition of the Ramanu et al and full scope. And we conjecture it to be deniable against strong judges as well. But it's not a generic construction. All in all, we are very happy to see that there's many people working towards making signal post-quantum. And our contribution to that is our protocol SPQR, which is a post-quantum replacement for the initial handshake from key encapsulation mechanisms and designated verifier signatures. Along the way, we have introduced a new definition of deniability with strong judges, which our protocol fulfills, and we have shown that you can build TVS from ring signatures. And then using a post-quantum replacement for the initial handshake, such as our SPQR protocol, and a double ratchet replacement, such as the one using key encapsulation mechanisms from Alvan et al, these two in combination can be used to build a post-quantum alternative of signal. Thank you very much for your attention, and please check out our full paper on e-print.