Skip to main content
Log in

A Formal Security Analysis of the Signal Messaging Protocol

  • Published:
Journal of Cryptology Aims and scope Submit manuscript

Abstract

The Signal protocol is a cryptographic messaging protocol that provides end-to-end encryption for instant messaging in WhatsApp, Wire, and Facebook Messenger among many others, serving well over 1 billion active users. Signal includes several uncommon security properties (such as “future secrecy” or “post-compromise security”), enabled by a technique called ratcheting in which session keys are updated with every message sent. We conduct a formal security analysis of Signal’s initial extended triple Diffie–Hellman (X3DH) key agreement and Double Ratchet protocols as a multi-stage authenticated key exchange protocol. We extract from the implementation a formal description of the abstract protocol and define a security model which can capture the “ratcheting” key update structure as a multi-stage model where there can be a “tree” of stages, rather than just a sequence. We then prove the security of Signal’s key exchange core in our model, demonstrating several standard security properties. We have found no major flaws in the design and hope that our presentation and results can serve as a foundation for other analyses of this widely adopted protocol.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8

Similar content being viewed by others

Notes

  1. TextSecure v1 was based on OTR; in v2 it migrated to the Axolotl Ratchet and in v3 made some changes to the cryptographic primitives and the wire protocol. Signal is based on TextSecure v3.

  2. The tagged releases of libsignal lag behind the current codebase. The commit hash of the state of the repository as of our reading is listed in the bibliography. Note that there are separate implementations in C, JavaScript and Java; the latter is used by Android mobile apps and is the one we have read most carefully.

  3. The key exchange protocol was previously referred to as TripleDH, from the three Diffie–Hellman (DH) shared secrets always used in the KDF (although in most configurations four shared secrets are used). The name QuadrupleDH has also been used for the variant which includes the long-term/long-term Diffie–Hellman (DH) value, not as might be expected the variant which includes the one-time prekey.

  4. If the initial message from Alice is invalid, Bob will in fact not complete a session. This does not affect our analysis, which considers only secrecy of session keys, but may become important if, e.g., analysing deniability.

  5. Future secrecy means “a leak of keys to a passive eavesdropper will be healed by introducing new Diffie–Hellman (DH) ratchet keys” [60].

  6. A vertex cover of a graph is a set of nodes incident to every edge.

  7. In our model, there are two ephemeral/medium-term pairs: \((\textit{prepk}^{B})^{\textit{ek}^{A}}\) and \((\textit{prepk}^{B})^{\textit{rchk}^{A}_{0}}\). Our security model treats \(\textit{ek}^{A} \) and \(\textit{rchk}^{A}_{0} \) as being revealed by the same query, so one predicate covers both terms.

  8. This is done in practice by reinterpreting the Curve25519 point as an Ed25519 key and computing an EdDSA signature.

  9. The implementation of group messaging is not specified at the protocol layer. If it is implemented using multiple pairwise sessions, its security may follow in a relatively straightforward fashion—however, there are many other possible security properties which might be desired, such as transcript consistency.

References

  1. J. Alwen, S. Coretti, Y. Dodis, The Double Ratchet: security notions, proofs, and modularization for the Signal protocol, in IACR Cryptology ePrint Archive 2018 (2018), p. 1037. https://eprint.iacr.org/2018/1037

  2. C. Bader, D. Hofheinz, T. Jager, E. Kiltz, Y. Li, Tightly-secure authenticated key exchange, in TCC 2015, Part I, LNCS, vol. 9014. (Springer, Heidelberg, 2015), pp. 629–658

    MATH  Google Scholar 

  3. C. Bader, T. Jager, Y. Li, S. Schäge, On the Impossibility of Tight Cryptographic Reductions. Cryptology ePrint Archive, Report 2015/374 (2015). http://eprint.iacr.org/2015/374

  4. C. Ballinger, ChatSecure. https://chatsecure.org/blog/chatsecure-v4-released/ (visited on 01/2017)

  5. M. Bellare, A. Boldyreva, A. Palacio, An uninstantiable random-oracle-model scheme for a hybrid-encryption problem, in Advances in Cryptology-EUROCRYPT 2004 (Springer, 2004), pp. 171–188

  6. M. Bellare, R. Canetti, H. Krawczyk, A modular approach to the design and analysis of authentication and key exchange protocols (extended abstract), in 30th ACM STOC. (ACM Press, 1998), pp. 419–428

  7. M. Bellare, D. Pointcheval, P. Rogaway, Authenticated key exchange secure against dictionary attacks, in EUROCRYPT 2000, LNCS, vol. 1807 (Springer, Heidelberg, 2000), pp. 139–155

    MATH  Google Scholar 

  8. M. Bellare, P. Rogaway, Entity authentication and key distribution, in CRYPTO’93., LNCS, vol. 773 (Springer, Heidelberg, 1994), pp. 232–249

  9. M. Bellare, P. Rogaway, Random oracles are practical: a paradigm for designing efficient protocols, in Proceedings of the 1st ACM conference on Computer and communications security (ACM. 1993), pp. 62–73

  10. M. Bellare, A.C. Singh, J. Jaeger, M. Nyayapati, I. Stepanovs, Ratcheted encryption and key exchange: the security of messaging. Cryptology ePrint Archive, Report 2016/1028 (2016). http://eprint.iacr.org/2016/1028

  11. M. Bellare, B.S. Yee, Forward-security in private-key cryptography, in CT-RSA 2003, LNCS, vol. 2612 (Springer, Heidelberg, 2003), pp. 1–18

    MATH  Google Scholar 

  12. D.J. Bernstein, Curve25519: new Diffie–Hellman speed records, in PKC 2006, LNCS, vol. 3958 (Springer, Heidelberg, 2006), pp. 207–228

    MATH  Google Scholar 

  13. D.J. Bernstein, N. Duif, T. Lange, P. Schwabe, B.-Y. Yang, High-speed high-security signatures, in CHES 2011, LNCS, vol. 6917 (Springer, Heidelberg, 2011), pp. 124–142

    MATH  Google Scholar 

  14. K. Bhargavan, C. Brzuska, C. Fournet, M. Green, M. Kohlweiss, S. Zanella-Béguelin, Downgrade resilience in key-exchange protocols, in 2016 IEEE Symposium on Security and Privacy (IEEE Computer Society Press, 2016), pp. 506–525

  15. D. Bogado, D. O’Brien, Punished for a Paradox. Mar. 2, 2016. https://www.eff.org/deeplinks/2016/03/punished-forparadox-brazils-facebook (visited on 07/2016)

  16. N. Borisov, I. Goldberg, E. Brewer, Off-the-record communication, or, why not to use PGP, in WPES (ACM, Washington DC, 2004), pp. 77–84

    Google Scholar 

  17. C. Boyd, C. Cremers, M. Feltz, K.G. Paterson, B. Poettering, D. Stebila, ASICS: authenticated key exchange security incorporating certification systems, in ESORICS 2013, LNCS, vol. 8134 (Springer, Heidelberg, 2013), pp. 381–399

    MATH  Google Scholar 

  18. J. Brendel, M. Fischlin, F. Günther, C. Janson, PRF-ODH: relations, instantiations, and impossibility results, in CRYPTO 2017, Part III LNCS, vol. 10403 (Springer, Heidelberg, 2017), pp. 651–681

    MATH  Google Scholar 

  19. R. Canetti, O. Goldreich, S. Halevi, The random oracle methodology, revisited, in Journal of the ACM (JACM) 51.4 (2004), pp. 557–594

    Article  MathSciNet  Google Scholar 

  20. R. Canetti, S. Halevi, J. Katz, A forward-secure public-key encryption scheme, in EUROCRYPT 2003, LNCS, vol. 2656 (Springer, Heidelberg, 2003), pp. 255–271

    MATH  Google Scholar 

  21. R. Canetti, H. Krawczyk, Analysis of key-exchange protocols and their use for building secure channels, in EUROCRYPT 2001, LNCS, vol. 2045 (Springer, Heidelberg, 2001), pp. 453–474

    MATH  Google Scholar 

  22. K. Cohn-Gordon, C. Cremers, Mind the Gap: Where Provable Security and Real-World Messaging Don’t Quite Meet. Cryptology ePrint Archive, Report 2017/982 (2017). http://eprint.iacr.org/2017/982

  23. K. Cohn-Gordon, C. Cremers, L. Garratt, On Post-Compromise Security. (A shorter version of this paper appears at CSF 2016) (2016). http://eprint.iacr.org/2016/221

  24. Conversations. https://conversations.im/ (visited on 07/2016)

  25. C. Cremers, M. Feltz, One-round Strongly Secure Key Exchange with Perfect Forward Secrecy and Deniability. Cryptology ePrint Archive, Report 2011/300 (2011). http://eprint.iacr.org/2011/300

  26. C. Cremers, M. Horvat, S. Scott, T. van der Merwe, Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication, in 2016 IEEE Symposium on Security and Privacy (IEEE Computer Society Press, 2016)

  27. J.P. Degabriele, A. Lehmann, K.G. Paterson, N.P. Smart, M. Strefler, On the joint security of encryption and signature in EMV, in CT-RSA 2012, LNCS, vol. 7178 (Springer, Heidelberg, 2012), pp. 116–135

    MATH  Google Scholar 

  28. M. Di Raimondo, R. Gennaro, H. Krawczyk, Deniable authentication and key exchange, in ACM CCS 2006 (ACM Press, 2006), pp. 400–409

  29. M. Di Raimondo, R. Gennaro, H. Krawczyk, Secure off-the-record messaging, in WPES. (ACM, Alexandria, VA, 2005), pp. 81–89

    Google Scholar 

  30. B. Dowling, M. Fischlin, F. Günther, D. Stebila, A cryptographic analysis of the TLS 1.3 handshake protocol candidates, in ACM CCS 2015 (ACM Press, 2015), pp. 1197–1210

  31. F. Betül Durak, S. Vaudenay, Bidirectional asynchronous ratcheted key agreement without key-update primitives, in IACR Cryptology ePrint Archive 2018 (2018), p. 889. https://eprint.iacr.org/2018/889

  32. Electronic Frontier Foundation, Secure messaging scorecard (2016). https://www.eff.org/node/82654

  33. Facebook. Messenger Secret Conversations, Technical report (2016). https://fbnewsroomus.files.wordpress.com/2016/07/secret_conversations_whitepaper-1.pdf (visited on 07/2016)

  34. M. Fischlin, F. Gúnther, Multi-stage key exchange and the case of Google’s QUIC protocol, in ACM CCS 2014 (ACM Press, 2014), pp. 1193–1204

  35. T. Frosch, C. Mainka, C. Bader, F. Bergsma, J. Schwenk, T. Holz, How Secure is TextSecure? Cryptology ePrint Archive, Report 2014/904 (2014). http://eprint.iacr.org/2014/904 (Version from April 5, 2016)

  36. T. Frosch, C. Mainka, C. Bader, F. Bergsma, J. Schwenk, T. Holz, How secure is TextSecure?, in 1st IEEE European Symposium on Security and Privacy (IEEE Computer Society Press, 2016)

  37. C. Garman, M. Green, G. Kaptchuk, I. Miers, M. Rushanan, Dancing on the lip of the volcano: chosen ciphertext attacks on Apple iMessage, in Usenix Security 2016 (2016)

  38. Wire Swiss GmbH. Wire Security Whitepaper, in (Aug. 17, 2018). https://wire-docs.wire.com/download/Wire+Security+Whitepaper.pdf (visited on 01/2019)

  39. S. Goldwasser, Y.T. Kalai, Cryptographic assumptions: a position paper, in IACR Cryptology ePrint Archive 2015 (2015), p. 907

  40. M.D. Green, I. Miers, Forward secure asynchronous messaging from puncturable encryption, in 2015 IEEE Symposium on Security and Privacy (IEEE Computer Society Press, 2015), pp. 305–320

  41. M. Hamburg, Ed448-Goldilocks, a New Elliptic Curve. Cryptology ePrint Archive, Report 2015/625 (2015). http://eprint.iacr.org/2015/625

  42. T. Jager, F. Kohlar, S. Schäge, J. Schwenk, On the security of TLS-DHE in the standard model, in CRYPTO 2012, LNCS, vol. 7417 (Springer, Heidelberg, 2012), pp. 273–293

    MATH  Google Scholar 

  43. T. Jager, J. Schwenk, J. Somorovsky, On the security of TLS 1.3 and QUIC against weaknesses in PKCS#1 v1.5 Encryption, in ACM CCS 2015 (ACM Press, 2015), pp. 1185–1196

  44. D. Jost, U. Maurer, M. Mularczyk, Efficient ratcheting: almost-optimal guarantees for secure messaging, in IACR Cryptology ePrint Archive 2018 (2018), p. 954. https://eprint.iacr.org/2018/954

  45. N. Kobeissi, K. Bhargavan, B. Blanchet, Automated verification for secure messaging protocols and their implementations: a symbolic and computational approach, in 2nd IEEE European Symposium on Security and Privacy (IEEE Computer Society Press, 2017)

  46. N. Koblitz, A.J. Menezes, The random oracle model: a twenty-year retrospective, in Designs, Codes and Cryptography 77.2-3 (2015), pp. 587–610

    Article  MathSciNet  Google Scholar 

  47. M. Kohlweiss, U. Maurer, C. Onete, B. Tackmann, D. Venturi, (De-)constructing TLS 1.3, in INDOCRYPT 2015, LNCS, vol. 9462 (Springer, Heidelberg, 2015), pp. 85–102

  48. H. Krawczyk, Cryptographic extraction and key derivation: the HKDF scheme, in CRYPTO 2010, LNCS, vol. 6223 (Springer, Heidelberg, 2010), pp. 631–648

    MATH  Google Scholar 

  49. H. Krawczyk, HMQV: a high-performance secure Diffie–Hellman protocol, in CRYPTO 2005, LNCS, vol. 3621 (Springer, Heidelberg, 2005), pp. 546–566

    MATH  Google Scholar 

  50. C. Kudla, K.G. Paterson, Modular security proofs for key agreement protocols, in ASIACRYPT 2005, LNCS, vol. 3788 (Springer, Heidelberg, 2005), pp. 549–565

    MATH  Google Scholar 

  51. B.A. LaMacchia, K. Lauter, A. Mityagin, Stronger security of authenticated key exchange, in ProvSec 2007, LNCS, vol. 4784 (Springer, Heidelberg, 2007), pp. 1–16

    MATH  Google Scholar 

  52. A. Langley. Pond. (2014). https://pond.imperialviolet.org/ (visited on 06/22/2015)

  53. X. Li, J. Xu, Z. Zhang, D. Feng, H. Hu, Multiple handshakes security of TLS 1.3 candidates, in 2016 IEEE Symposium on Security and Privacy. (IEEE Computer Society Press, 2016), pp. 486–505

  54. libsignal-protocol-java. GitHub repository, commit hash 4a7bc1667a68c1d8e6af0151be30b84b94fd1e38 (2016). https://github.com/WhisperSystems/libsignal-protocol-java (visited on 07/2016)

  55. M. Marlinspike, Advanced Cryptographic Ratcheting. Blog. 2013. https://whispersystems.org/blog/advanced-ratcheting/ (visited on 07/2016)

  56. A. Menezes, B. Ustaoglu, On reusing ephemeral keys in Diffie–Hellman key agreement protocols, in Int. J. Appl. Cryptol. 2.2 (2010), pp. 154–158

    Article  MathSciNet  Google Scholar 

  57. V. Moscaritolo, G. Belvin, P. Zimmermann, Silent Circle Instant Messaging Protocol Specification. Technical report Archived from the original. Dec. 5, 2012. https://web.archive.org/web/20150402122917/, https://silentcircle.com/sites/default/themes/silentcircle/assets/downloads/SCIMP_paper.pdf (visited on 07/2016)

  58. T. Okamoto, D. Pointcheval, The Gap-problems: a new class of problems for the security of cryptographic schemes, in PKC 2001, LNCS, vol. 1992 (Springer, Heidelberg, 2001), pp. 104–118

    MATH  Google Scholar 

  59. K.G. Paterson, J.C.N. Schuldt, M. Stam, S. Thomson, On the joint security of encryption and signature, Revisited, in ASIACRYPT 2011, LNCS, vol. 7073 (Springer, Heidelberg, 2011), pp. 161–178

    MATH  Google Scholar 

  60. T. Perrin, Double Ratchet Algorithm. GitHub wiki (2016). https://github.com/trevp/double_ratchet/wiki (visited on 07/22/2016)

  61. T. Perrin, The XEdDSA and VXEdDSA Signature Schemes. Specification (2016). https://whispersystems.org/docs/specifications/xeddsa/ (visited on 07/2016)

  62. T. Perrin, M. Marlinspike, The Double Ratchet Algorithm. Specification (2016). https://whispersystems.org/docs/specifications/doubleratchet/ (visited on 01/2017)

  63. T. Perrin, M. Marlinspike, The X3DH Key Agreement Protocol. Specification (2016). https://whispersystems.org/docs/specifications/x3dh/ (visited on 01/2017)

  64. B. Poettering, P. Rösler, Towards bidirectional ratcheted key exchange, in Advances in Cryptology—CRYPTO 2018—38th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 19–23, 2018, Proceedings, Part I, Lecture Notes in Computer Science, vol. 10991 (Springer, 2018), pp. 3–32. ISBN:978-3-319-96883-4. https://doi.org/10.1007/978-3-319-96884-15C_1

  65. J. Reardon, D. Basin, S. Capkun, SoK: secure data deletion, in 2013 IEEE Symposium on Security and Privacy (SP), (2013), pp. 301–315

  66. E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.3. Internet-Draft draft-ietf-tls-tls13–14 (2016). http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-14.txt

  67. P. Rogaway, Authenticated-encryption with associated-data, in ACM CCS 2002 (ACM Press, 2002), pp. 98–107

  68. P. Rösler, C. Mainka, J. Schwenk, More is less: on the end-to-end security of group chats in Signal, WhatsApp, and Threema, in 2018 IEEE European Symposium on Security and Privacy, EuroS&P 2018, (London, UK, April 24–26), 2018 (IEEE, 2018), pp. 415–429. ISBN:978-1-5386-4228-3. https://doi.org/10.1109/EuroSP.2018.00036

  69. A. Straub, OMEMO Encryption. Oct. 25, 2015. https://conversations.im/xeps/multi-end.html (visited on 07/2016)

  70. N. Unger, S. Dechand, J. Bonneau, S. Fahl, H. Perl, I. Goldberg, M. Smith, SoK: secure messaging, in 2015 IEEE Symposium on Security and Privacy (IEEE Computer Society Press, 2015), pp. 232–249

  71. N. Unger, I. Goldberg, Deniable key exchanges for secure messaging, in ACM CCS 2015 (ACM Press, 2015), pp. 1211–1223

  72. WhatsApp, WhatsApp Encryption Overview. Technical report (2016). https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf (visited on 07/2016)

Download references

Acknowledgements

The authors acknowledge helpful discussions with Marc Fischlin and Felix Günther and valuable comments from Chris Brzuska and Trevor Perrin. Thanks to Xavier Bultel for carefully reading through the proof. Thanks to Mang Zhao for identifying a missing DH operation in the session setup phase. K. C-G. and L.G. were supported by the Oxford CDT in Cyber Security. B.D was supported by EPSRC Grant EP/L018543/1. D.S. was supported by Australian Research Council (ARC) Discovery Project Grant DP130104304, Natural Sciences and Engineering Research Council of Canada (NSERC) Discovery Grant RGPIN-2016-05146, and NSERC Discovery Accelerator Supplement Grant RGPIN-2016-05146.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Benjamin Dowling.

Additional information

Communicated by Hugo Krawczyk.

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Appendices

On Hardness Assumptions and the Random Oracle Model (ROM)

When performing a game-hopping security proof in an extended Canetti–Krawczyk-style model, after each hop we must show that the resulting game is similar to the original. If certain values have been changed, the queries whose results differ must be simulated in an indistinguishable manner.

In particular, the eCK family of models all contain a query \(\textsf {RevSessKey} \) which reveals the session key derived by a targeted session. This models for example cryptanalysis of a large volume of encrypted traffic, or the ability to read certain locations in memory. When replacing certain Diffie–Hellman (DH) keys with random values, we must ensure that the resulting game is similar to its original. For protocols using only ephemeral Diffie–Hellman (DH) values \(g^x\) and \(g^y\) to compute session keys from \(g^{xy}\), replacing \(g^x\) and \(g^y\) by random does not affect other sessions, and thus other \(\textsf {RevSessKey} \) queries are not affected. However, for more complex protocols (such as NAXOS and HMQV) in which the long-term keys are also included in the session key derivation, this game hop becomes more complex. Specifically, when the long-term keys are modified, all \(\textsf {RevSessKey} \) queries are affected, and their simulation is no longer trivial.

There is a proof obligation to show that the simulation of these queries does not allow an adversary to distinguish the two games. One way to do this is by using Gap-Diffie–Hellman (DH) in the random oracle model, assuming that the KDF is a random oracle. In the simulation, whenever the adversary makes a query to the random oracle, the challenger tests the relevant part of the argument using the DDH oracle to determine whether the adversary has successfully derived the Diffie–Hellman (DH) secret. If so, the simulation can terminate and the challenger uses this value in the Gap-Diffie–Hellman (DH) game. This is the approach we take.

There are known issues with the ROM. An alternative to Gap-Diffie–Hellman (DH) is to take a \(\textsf {PRF-ODH}\) (pseudorandom function with oracle Diffie–Hellman (DH)) assumption, which effectively provides an oracle for session key computations and (roughly) asserts that it is hard to solve computational Diffie–Hellman (DH) even with access to the oracle. The game hop then takes the computational Diffie–Hellman (DH) values from the \(\textsf {PRF-ODH}\) game and answers \(\textsf {RevSessKey} \) queries by querying the oracle. The probability jump over the game is thus bounded by the \(\textsf {PRF-ODH}\) advantage.

There is a further complication in the case of Signal. In most normal Diffie–Hellman (DH) protocols, there is only one method to compute a session key given a collection of secret inputs; such a method could be called a “combinator”. For example, in NAXOS the combinator hashes one long-term key and uses that as a Diffie–Hellman (DH) exponential. In Signal, on the other hand, there are many different combinators, and the oracle we use must be sufficiently flexible to simulate all of them. Thus, we have the following options:

  1. (i)

    Define a \(\textsf {PRF-ODH}\) game parameterized by the combinator K used to assemble secrets into the arguments to the KDF. For each different type of key in Signal, assume hardness of this game and use this assumption to justify a game hop.

  2. (ii)

    Assume that the KDF is a random oracle, and justify the game hop directly from the ROM and Gap-Diffie–Hellman (DH).

We choose the latter option, since we believe that the former hardness assumption is not necessarily justified. However, we conjecture that a carefully formulated \(\textsf {PRF-ODH}\) game could be proven hard in the ROM and therefore that one proof could effectively take either option depending on the reader’s opinions. We leave such a game for future work.

1.1 Definitions of Hardness Assumptions

Our proof of security relies on standard cryptographic hardness assumptions related to Diffie–Hellman (DH) key exchange. Let \(\mathbb {G}=\langle g \rangle \) be a cyclic group of prime order q generated by g, let \(\alpha , \beta , \gamma {\mathop {\leftarrow }\limits ^{{\$}}}\mathbb {Z}_q\), and let \(\mathcal {O}_\text {DDH}\) be an efficient black-box algorithm (oracle) that, on input \((g^x, g^y, g^z)\), outputs 1 if \(g^z = g^{xy}\) and 0 otherwise. For any algorithm \(\mathcal {D}\) let

$$\begin{aligned} \epsilon _\text {DDH}(\mathcal {D})&{:}{=}\Bigg \vert \Pr \left[ \mathcal {D}(\mathbb {G},q,g,g^\alpha ,g^\beta ,g^{\alpha \beta } )=1: \alpha ,\beta {\mathop {\leftarrow }\limits ^{{\$}}}\mathbb {Z}_q \right] \\&\qquad \qquad \qquad - \Pr \left[ \mathcal {D}(\mathbb {G},q,g,g^\alpha , g^\beta , g^\gamma ) = 1: \alpha ,\beta ,\gamma {\mathop {\leftarrow }\limits ^{{\$}}}\mathbb {Z}_q \right] \Bigg \vert \\ \epsilon _\text {CDH}(\mathcal {D})&{:}{=}\Pr \left[ \mathcal {D}(\mathbb {G},q,g,g^\alpha ,g^\beta )=g^{\alpha \beta }: \alpha ,\beta {\mathop {\leftarrow }\limits ^{{\$}}}\mathbb {Z}_q \right] \\ \epsilon _\text {GDH}(\mathcal {D})&{:}{=}\Pr \left[ \mathcal {D^{O_{\text {DDH}}}}(\mathbb {G},q,g,g^\alpha ,g^\beta )=g^{\alpha \beta }: \alpha ,\beta {\mathop {\leftarrow }\limits ^{{\$}}}\mathbb {Z}_q \right] \end{aligned}$$

We make use of the following cryptographic hardness assumptions:

  1. (i)

    Decisional Diffie–Hellman (DDH): it is hard to distinguish \((g^\alpha , g^\beta , g^{\alpha \beta })\) from \((g^\alpha , g^\beta , g^\gamma )\), i.e., \(\epsilon _\text {DDH}(\mathcal {D})\) is negligible in \(\log (q)\) for any efficient \(\mathcal {D}\).

  2. (ii)

    Computational Diffie–Hellman (CDH): it is hard to compute the value \(g^{\alpha \beta }\) from \((g^\alpha , g^\beta )\), i.e., \(\epsilon _\text {CDH}(\mathcal {D})\) is negligible in \(\log (q)\) for any efficient \(\mathcal {D}\).

  3. (iii)

    Gap Diffie–Hellman (GDH) [58]: it is hard to compute the value \(g^{\alpha \beta }\) from \((g^\alpha , g^\beta )\) even when given black-box access to a DDH oracle, i.e., \(\epsilon _\text {GDH}(\mathcal {D})\) is negligible in \(\log (q)\) for any efficient \(\mathcal {D}\).

We also make use of the random oracle model (ROM), instantiating all \({\mathrm {KDF}}\)s as black boxes which return a uniformly random output for any given input.

Security Proof

The proof considers different cases corresponding to the possible behaviour of an adversary. We first describe modifications to the \(\text {Signal }\) protocol made for our proof in B.1. We then recall the main theorem and provide the actual proof in B.3.

1.1 Protocol Modifications for Key Indistinguishability

In order to apply a Bellare–Rogaway-style key indistinguishability model for key exchange, in our proof we make two modifications to the Signal protocol. First, we remove all data messages from the protocol, considering only the key exchange messages. Second, we consider handshake messages as being sent in plaintext instead of inside the associated data of the AEAD encryption of a message. Without this change, an adversary could distinguish a tested message key from random by using it to verify the authentication of a handshake message.

1.2 Proof Structure Overview

Security in this sense means that no efficient adversary can break the multi-stage key-indistinguishability game for the two-party protocol \(\text {Signal }\), parameterized by freshness condition \(\textsf {fresh} \), with non-negligible probability. Suppose for contradiction that such an adversary \(\mathcal {A}\) exists. Whatever the behaviour of the adversary, trivially (by the definition of the security experiment in Fig. 8) it can only succeed when the Tested session \([s]\) is fresh. By Definition 4, this means that the \(\textsf {Test} (u,i,s)\) query satisfies:

  1. (i)

    \({\pi _{u}^{i}}.\textit{status}[s] = \texttt {accept} \),

  2. (ii)

    \(\lnot {\pi _{u}^{i}}.\textsf {rev\_session} [s]\),

  3. (iii)

    for all j such that \({\pi _{u}^{i}}.\textit{sid}[s] = {\pi _{v}^{j}}.\textit{sid}[s]\), \(\lnot {\pi _{v}^{j}}.\textsf {rev\_session} [s]\), and

  4. (iv)

    \(\textsf {clean} _{{\pi _{u}^{i}}.\textit{type}[s]} (u,i,s)\)

where v denotes \(\pi ^{i}_{u}.\textit{peerid}\), the identity of the intended peer to the Tested session, and \(\textsf {clean} _{{\pi _{u}^{i}}.\textit{type}[s]}(u,i,s)\) is a cleanness clause as referenced in Definition 4 and subsequent definitions, further restricting the adversary’s behaviour. In the following overview, we consider the case that the Tested session is the initiator; the responder is analogous.

1.3 High-Level Overview of the Case Distinction

A high-level overview of the proof with its main game sequences and case distinctions is given in Figure 9.

Fig. 9
figure 9

High-level overview of the proof structure. Games are identified by G0, G1, ..., and main case distinctions by C1, C2, ...; G0 denotes the multi-stage security experiment from Sect. 4.2. In the PDF version of this document, such identifiers can be clicked to jump to the corresponding part of the proof

Stage 0. We start by proving the security of the stage 0 key that is output by the \(\texttt {triple} \) key-exchange during session setup. We show this via taking cases over the disjuncts in the \(\textsf {clean} _{\texttt {triple} }\) clause—over the different ways the session could be clean—noting that one of \(\textsf {clean} _{\texttt {LM} }(u,i)\), \(\textsf {clean} _{\texttt {EL} }(u,i,0)\), \(\textsf {clean} _{\texttt {EM} }(u,i,0)\) must be upheld.

We bound each of these probabilities in turn by the advantage of reduction algorithms to the security experiments of our primitives—to DH security using the GDH and ROM assumptions.

Asymmetric stages. Next, we consider the security of a stage s key such that stage s has stage type \(\texttt {asym-ir} \) or \(\texttt {asym-ri} \). Again, we take cases over the different ways to satisfy the cleanness predicate, depending on the type of the stage. Most cases are of the form \(\textsf {clean} _{\texttt {EE} }\), and for these we obtain a probability bound by replacing the Diffie–Hellman (DH) ratchet keys and shared secrets with values from a GDH challenger.

The only case not of this form involves \(\textsf {clean} _{\textsf {state} }\), which describes a scenario where both recent ratchet keys were compromised but the previous stage was still secure. Secrecy here is intuitive, and the bound follows from an inductive argument: if an adversary could win in this manner, then assuming GDH and ROM security, there is an adversary which could win against the previous stage.

Symmetric stages. Finally, we consider the security of stage s keys of type \(\texttt {sym} \). Here, there is no disjunction in the cleanness predicate and hence only one case to consider. We replace the keys used to initialize the current sending chain with uniformly random values, since an adversary who could detect this could win against that previous stage.

1.4 Proof of the Main Theorem

1.4.1 Conventions

We remark on a few conventions which we adopt during the proof.

Many cases technically differ based on whether the actor of the Test session has the initiator or responder role. For example, the first session key derived by the initiator is from a sending chain, while the first one derived by the responder is from a receiving chain. Where the security arguments are identical except for obvious symmetries, we just consider the case of the initiator and leave the responder as analogous.

Signal uses \({\mathrm {HMAC}}\) and \({\mathrm {HKDF}}\) within the \({\mathrm {KDF}}\) invocations. We assume that the \({\mathrm {KDF}}\) invocations themselves (as defined in Fig. 7) are random oracles and thus need not make any assumptions on \({\mathrm {HMAC}}\) and \({\mathrm {HKDF}}\) specifically.

By \(break_{i} \), we mean the event that the adversary wins game \(G_i\). By \(\textsf {Adv}_{i}\), we mean the advantage of the adversary against game \(G_{i}\); that is,

$$\begin{aligned} \textsf {Adv}_{i}:=\left| 2\Pr (break_{i})-1\right| \end{aligned}$$

We aim to show that \(\textsf {Adv}_{0}\) is a negligible function of the security parameter. To avoid overfilling our subscripts, we overload where it is obvious which game is meant.

Theorem 1

The Signal protocol is a secure multi-stage key exchange protocol under the GDH assumption and assuming all \({\mathrm {KDF}}\)s are random oracles. That is, if no efficient adversary can break the assumptions with non-negligible probability, then no efficient adversary can win the multi-stage key indistinguishability security experiment for Signal (and thereby distinguish any fresh message encryption key from random) with non-negligible probability.

Proof

We begin by performing a series of game hops that affect all potential cases. After these, the game hops diverge depending on which case we are considering. See Fig. 9 for a high-level overview of the proof structure and the case distinctions.

1.5 Game Hops for all Cases

1.5.1 Game 0

This game equals the multi-stage security experiment described in Sect. 4.2. As such, the advantage of the adversary against this game is \(\textsf {Adv}_{0}\).

1.5.2 Game 1

In this game, we ensure no collision of honestly generated Diffie–Hellman (DH) public keys. Specifically, the challenger \(\mathcal {C}\) maintains a list L of all Diffie–Hellman (DH) private values (for \(\textit{ik}, \textit{prek}, \textit{ek}, \textit{eprek}, \textit{rchk})\) honestly generated during the game. If a Diffie–Hellman (DH) private value appears twice, \(\mathcal {C}\) aborts the simulation and the adversary automatically loses. For an adversary’s execution during the game, let \(\textsf {n} _\textsf {P} \) denote the total number of parties, \(\textsf {n} _{\textsf {S} }\) the maximum number of sessions, \(\textsf {n} _{\textsf {M} }\) the maximum number of medium-term keys per party, and \(\textsf {n} _{\textsf {s} }\) the maximum number of stages. We note that there are \(\textsf {n} _\textsf {P} \) long-term keys in the game, a maximum of \(\textsf {n} _{\textsf {M} }\) medium-term keys generated for each of the \(\textsf {n} _\textsf {P} \) parties for a maximum of \(\textsf {n} _{\textsf {M} }\textsf {n} _\textsf {P} \) medium-term keys, and a maximum of \(\textsf {n} _{\textsf {s} }\) ephemeral/ratchet keys per session for a total maximum of \(\textsf {n} _{\textsf {S} }\textsf {n} _{\textsf {s} }\) ephemeral/ratchet keys. This means a total maximum of \(\textsf {n} _\textsf {P} + \textsf {n} _\textsf {P} \textsf {n} _{\textsf {M} }+ \textsf {n} _{\textsf {S} }\textsf {n} _{\textsf {s} }\) DH keys in the list L, every pair of which must not collide. There are \(\left( {\begin{array}{c}\vert L \vert \\ 2\end{array}}\right) \) such pairs of DH keys to consider in the game. Each DH key in L is in the same group of order q so collides with another key in L with probability \(\nicefrac {1}{q}\). Therefore, we have the following bound:

$$\begin{aligned} \textsf {Adv}_{0} \le \frac{\left( {\begin{array}{c} \textsf {n} _\textsf {P} + \textsf {n} _\textsf {P} \textsf {n} _{\textsf {M} }+ \textsf {n} _{\textsf {S} }\textsf {n} _{\textsf {s} }\\ 2\end{array}}\right) }{q} + \textsf {Adv}_{1} \end{aligned}$$

We now know that from this game onwards each honestly generated Diffie–Hellman (DH) public key is unique. In future game hops, we will replace certain Diffie–Hellman (DH) values with ones sampled by a GDH challenger; this means that if these replacement values collide, we must abort the game and will therefore be unable to answer the GDH challenge. This will appear in game \(G4\). Luckily, the probability of the GDH challenger producing colliding GDH challenge values is negligible (probability \(\nicefrac {1}{q}\)), as we will see.

1.5.3 Game 2

In this game, the challenger guesses in advance the session \({\pi _{u}^{i}}\) against which the \(\textsf {Test} (u,i,s)\) query is issued: the challenger guesses a pair of indices \((u^*,i^*) \in [1..\textsf {n} _\textsf {P} ]\times [1..\textsf {n} _{\textsf {S} }]\). Let T be the event that the adversary issues a Test query \(\textsf {Test} (u,i,s)\) where \((u,i) \ne (u^*,i^*)\). In this game, we abort if event T occurs; it is a transition based on a large failure event.

T will occur with probability \(\nicefrac {1}{\textsf {n} _{\textsf {S} }\textsf {n} _\textsf {P} }\), and hence:

$$\begin{aligned} \textsf {Adv}_{1} = \textsf {n} _{\textsf {S} }\textsf {n} _\textsf {P} \textsf {Adv}_{2} \end{aligned}$$

We remark that the bound we prove in this hop is not tight and refer the reader to [3] for further discussions and impossibility results regarding tightness.

1.5.4 Game 3

In this game, the challenger guesses an index \(v^* \in [\textsf {n} _\textsf {P} ]\) and aborts if there exists a session \({\pi _{v}^{j}}\) that matches the Test session \({\pi _{u}^{i}}\) but \(v \ne v^*\). Note that it might be the case that no such matching \({\pi _{v}^{j}}\) exists, but this game ensures that if such a \({\pi _{v}^{j}}\) does exist, v is unique and known in advance by the challenger.

We must first show that there can exist at most one identity v with the same session identifier as \({\pi _{u}^{i}}\) (note v may have multiple sessions that match \({\pi _{u}^{i}}\) as the responder does not contribute freshness in the Triple-DH case). Alice’s session identifier for stage \([{\mathbf{ }\text {:}0,} ]\) contains \(\textit{ipk}^{v} \) (the identity public key of the peer). In \(G1\), we ensured that all Diffie–Hellman (DH) values were unique, and hence the claim holds.

It follows that the challenger’s guess is correct with probability \(\nicefrac {1}{\textsf {n} _\textsf {P} }\), and so (large failure event):

$$\begin{aligned} \textsf {Adv}_{2} \le \textsf {n} _\textsf {P} \textsf {Adv}_{3} \end{aligned}$$

In this game, we do not guess the partner session because the responder does not always contribute an ephemeral key. As such, it is perfectly possible for v to have multiple sessions that match the test \({\pi _{u}^{i}}\) because the adversary may replay \({\pi _{u}^{i}}\)’s ephemeral key to multiple sessions of v, which only uses the same public key and medium-term key. Only in \(\texttt {triple+DHE} \) does v contribute a ephemeral key (that is unique due to Game 1), and indeed in this case, we will do another game hop to guess the unique partner session in advance.

Currently, we have derived the following probability bound:

$$\begin{aligned} \textsf {Adv}_{0} \le \frac{\left( {\begin{array}{c} \textsf {n} _\textsf {P} + \textsf {n} _\textsf {P} \textsf {n} _{\textsf {M} }+ \textsf {n} _{\textsf {S} }\textsf {n} _{\textsf {s} }\\ 2\end{array}}\right) }{q} + \textsf {n} _{\textsf {S} }\textsf {n} _\textsf {P} ^2 \cdot \textsf {Adv}_{3} \end{aligned}$$

At this point, we need to partition our analysis for individual cases, with the ultimate aim of bounding \(\textsf {Adv}_{3}\) above. Once we have bounded \(\textsf {Adv}_{3}\), then we have bounded \(\textsf {Adv}_{0}\) and we are done. Since this is \(G3\), each different case begins with a hop to some \(G4\). Given there are five cases, it is clear that:

$$\begin{aligned} \textsf {Adv}_{3} \le \textsf {Adv}_{3}^{\mathbf {C1}}+\textsf {Adv}_{3}^{\mathbf {C2}}+\textsf {Adv}_{3}^{\mathbf {C3}}+\textsf {Adv}_{3}^{\mathbf {C4}}+\textsf {Adv}_{3}^{\mathbf {C5}} \end{aligned}$$
Fig. 10
figure 10

Legend for the boxes in the following diagrams. Red boxes indicate secrets that the adversary may gain access to via Reveal queries (or by computing the secrets as a result of the Reveal query), green boxes indicate secrets that are replaced based on the challenge, and blue boxes indicate secrets that the challenger is able to replace with random, thus ensuring security (Color figure online)

Fig. 11
figure 11

A diagram showing the replacement of secrets in Game 6 of Case 1.1. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case. Diagram legend can be found in Fig. 10 (Color figure online)

C1: Initial Key Exchange: \(\textit{type}[0]=\texttt {triple} \)

First, we consider the security of Signal in the multi-stage key-indistinguishability game against an adversary \(\mathcal {A}\) that issues a \(\textsf {Test} (u,i,[0])\) query with \({\pi _{u}^{i}}.\textit{type}[0] = \texttt {triple} \). By construction, the only way for the adversary to win (with non-negligible probability) is if \(\textsf {clean} _{\texttt {triple} }(u,i,[0])\) is true. We partition these scenarios into subcases. Note also that a \(\textsf {RevState} (u,i,[0])\) or \(\textsf {RevState} (v,j,[0])\) (where \({\pi _{v}^{j}}\) is a session matching \({\pi _{u}^{i}}\) if one exists) query will reveal nothing to the adversary, as there exists no previous state. Moreover, after our game hops, we will have replaced the Tested message key with a uniformly random value that is independent to all other keys, so other issued \(\textsf {RevState} \) queries will only reveal independent root keys and chain keys. As the state will be independent from the Tested session key, it will not help the adversary distinguish the Test session key from random. How to simulate reveal queries will be dealt with formally in the game hops.

We now begin to separate our analysis based on sub-clauses of the cleanness predicate. Let \(E^{\texttt {triple} }_{}\) be the event that an adversary \(\mathcal {A}\) wins the \(\textsf {ms-ind}\) game by issuing a Test query \(\textsf {Test} (u,i, [0])\), such that \({\pi _{u}^{i}}.\textit{type}= \texttt {triple} \), and let \(E^{\texttt {triple} }_{\textsf {clean} _{\texttt {LM} }}\) (resp. \(E^{\texttt {triple} }_{\textsf {clean} _{\texttt {EL} }}\), \(E^{\texttt {triple} }_{\textsf {clean} _{\texttt {EM} }}\)) be the sub-case in which additionally \(\textsf {clean} _{\texttt {LM} }(u,i)\) (resp. \(\textsf {clean} _{\texttt {EL} }(u, i, [0])\), \(\textsf {clean} _{\texttt {EM} }(u, i, [0])\) is true. By definition of \(\textsf {clean} _{\texttt {triple} }\):

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C1}} \le \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {LM} }(u,i)}} + \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {EL} }(u,i,0)}} + \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {EM} }(u,i,0)}} \end{aligned}$$

1.1 C1.1: Case \(\textit{type}[0] = \texttt {triple} \) and \(\textsf {clean} _{\texttt {LM} }(u,i)\):

In this case, \(\mathcal {A}_{\texttt {triple} }\) issued a \(\textsf {Test} (u,i,[0])\) query such that \(\textsf {clean} _{\texttt {LM} }(u,i)\) is upheld. For Test sessions where \({\pi _{u}^{i}}.\textit{role}= \texttt {init} \), this requires that \(\mathcal {A}_{\texttt {triple} }\) has not issued \(\textsf {RevLongTermKey} (u)\) or \(\textsf {RevMedTermKey} (v,n)\) where \({\pi _{u}^{i}}.\textsf {peerpreid} = n\). Since we do not consider the signatures over the medium-term prekeys in our model, we may assume that \({\pi _{u}^{i}}\) has received \(\textit{prepk}^{v}_{n} \) without modification.

Recall that an honest session derives a master secret \(ms = g^{\textit{ik}^{u} \cdot \textit{prek}^{v}_{n}} \Vert g^{\textit{ek}^{u} \cdot \textit{ik}^{v}} \Vert g^{\textit{ek}^{u} \cdot \textit{prek}^{v}_{n}}\), and then assigns \(\textit{rk}_{1} ~\Vert ~\textit{ck}^{ir}_{0,0} \leftarrow {\mathrm {HKDF}}(ms)\).

Our goal will be to replace the session key with a random value so that the adversary cannot guess the hidden bit (Game 7). Since we are working in the random oracle model and the session key is the output of a call to the random oracle, this means the adversary must query the random oracle on the exact input (Game 6). We embed a Gap Diffie–Hellman challenge into one of the components of the input to the random oracle. For this particular case (C1.1), which depends on the \(\textsf {clean} _{\texttt {LM} }(u,i)\) condition, we embed the GDH challenge into the long-term key of party u and one of the medium-term keys of the peer v (hop from Game 5 to Game 6). In order do this embedding, we must guess which of the medium-term keys of the peer is actually used (Game 4). (There is also a minor technicality covered in Game 5, described below.)

1.1.1 Game 4

In this game, the challenger guesses the index \(n\in [1..\textsf {n} _{\textsf {M} }]\) of the signed prekey of the peer (\(\textit{prek}^{v}_{n} \)) that the Test session will use in the execution of the protocol, and aborts if the guess is wrong. This yields (via large failure event) that

$$\begin{aligned} \textsf {Adv}_{3} \le \textsf {n} _{\textsf {M} }\textsf {Adv}_{4} \end{aligned}$$

1.1.2 Game 5

In this game, the experiment does not abort if \(\textit{ipk}^{u} \) and \(\textit{prepk}^{v}_{n} \) are the same. (Recall that in Game 1, we added an abort event if any DH values were the same. We will soon want to employ a GDH challenger, but the two challenge public keys in a GDH challenger may (with small probability) be the same, so we need to re-allow that in our game hops.) Since the keys are elements of a group of order q, the probability that one of them equals the other is \(\nicefrac {1}{q}\) and thus

$$\begin{aligned} \textsf {Adv}_{4} \le \nicefrac {1}{q} + \textsf {Adv}_{5} \end{aligned}$$

1.1.3 Game 6

In this game, the experiment aborts if the adversary queries \(g^{\textit{ik}^{u} \cdot \textit{prek}^{v}_{n}} = {\mathrm {CDH}}(\textit{ipk}^{u}, \textit{prepk}^{v}_{n})\) as the first component of a call to the \({\mathrm {HKDF}}\) random oracle; denote this event \(abort_{6} \). Thus, by a hop via small failure event,

$$\begin{aligned} \textsf {Adv}_{5} \le \textsf {Adv}_{}(break_{6}) + \textsf {Adv}_{6} \end{aligned}$$

We now need to bound \(\textsf {Adv}_{6}\). To do so, we show that, whenever event \(abort_{6} \) occurs, we can construct an algorithm \(\mathcal {B}_{0} \) that can win the Gap Diffie–Hellman problem. In the GDH experiment, \(\mathcal {B}_{0} \) receives as input a DH pair \((g^\alpha , g^\beta )\) (for \(\alpha \) and \(\beta \) unknown to \(\mathcal {B}_{0} \)) and has access to an oracle \(\mathcal {O}_{\text {DDH}}\) that on input \((g^x, g^y, g^z)\) returns 1 if and only if \(g^{xy} = g^z\).

\(B_0\) will simulate Game 5, except that it replaces \(ipk^u\) with \(g^\alpha \) and \(prepk^v_n\) with \(g^\beta \), refer to Fig. 11. Because certain keys have been replaced with public keys whose corresponding private values are unknown to \(\mathcal {B}_{0} \), we must define the actions that should be taken when these private values would normally be used in a computation. Cleanness implies that \(\lnot \textsf {rev\_ltk} _{u} \wedge \lnot \textsf {rev\_mtk} _{v}^{n}\), so \(\mathcal {B}_{0} \) will not need to answer any Reveal queries from \(\mathcal {A}\) on these values. However, since \(\mathcal {B}_{0} \) has replaced the long-term identity key and a medium-term public key of two parties, if \(\mathcal {A}\) decides to direct parties u or v to execute the protocol in a non-Tested session, then \(\mathcal {B}_{0} \) may need to perform simulations of concrete computations with the private keys \(\alpha \) and \(\beta \), despite not knowing them. There are three distinct types of sessions in which \(\mathcal {B}_{0} \) may lack the private keys needed to compute the master secret ms of that session:

  1. (i)

    a non-Tested session between user u and user v using \(\textit{prek}^{v}_{n} \) where u is the initiator;

  2. (ii)

    a non-Tested session between user u and some other user (possibly v or not) where u is the responder;

  3. (iii)

    a session between a user other than u and user v using \(\textit{prek}^{v}_{n} \) where v is the responder.

In session type (i), the simulator does not know \({\mathrm {CDH}}(g^{\alpha }, g^{\beta })\) which would be an input to the KDF computation of the session key (in fact this is the value that the simulator needs to find in the GDH game). In session type (ii), the simulator does not know \({\mathrm {CDH}}(g^{\alpha }, g^{e})\) for unknown, potentially maliciously chosen, e. In session type (iii), the simulator does not know \({\mathrm {CDH}}(g^{\beta }, g^e)\) for unknown, potentially maliciously chosen, e.

In each of these types of sessions, \(\mathcal {B}_{0} \) will pick random keys \(\textit{rk}_{1}, \textit{ck}^{ir}_{0,0} \) rather than deriving them via \({\mathrm {HKDF}}(ms)\). \(\mathcal {B}_{0} \) maintains a list of all sessions in which random keys have been substituted: the list contains the random session keys as well as the public keys that should have been used to compute each component of the master secret. \(\mathcal {B}_{0} \) must also ensure that key values used are consistent with any queries that \(\mathcal {A}\) makes to the random oracle \({\mathrm {HKDF}}\). We are concerned about queries of the form \(g^{x_1} \Vert g^{x_2} \Vert g^{x_3}\). Before answering any such query, \(\mathcal {B}_{0} \) goes through each entry in the above list of sessions: for each entry in the list, it uses its DDH oracle to check if the public keys that should have been used to compute each component of the master secret match the corresponding component (\(g^{x_1}\), \(g^{x_2}\) or \(g^{x_3}\)) of this random oracle query. For example, for session type (i) this amounts to querying the DDH oracle \(\mathcal {O}_{\text {DDH}}(g^{\alpha }, g^{\beta }, g^{x_1})\) and possibly \(\mathcal {O}_{\text {DDH}}(g^{e}, g^{\beta }, g^{x_2})\). If all components, when queried in the DDH oracle, return 1, then \(\mathcal {B}_{0} \) uses the randomly chosen keys from that element of the list as the random oracle response; otherwise, \(\mathcal {B}_{0} \) samples a new random value as the random oracle response. Similarly, session types (ii) and (iii) can be simulated.

Fig. 12
figure 12

A diagram showing the replacement of secrets in Game 5 of Case 1.2. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case Diagram legend can be found in Fig. 10 (Color figure online)

(While the explanation above starts from \(\mathcal {B}_{0} \) picking random session keys when simulating a session and then ensuring random oracle queries are answered consistently, \(\mathcal {B}_{0} \) must also do the reverse: when simulating a session, before picking random keys \(\mathcal {B}_{0} \) analogously use its DDH oracle to check whether this matches a previous random oracle query, to ensure correct simulation.)

Note the session type (i) is special: if \(\mathcal {O}_{\text {DDH}}(g^{\alpha }, g^{\beta }, g^{x_1}) = 1\), then the adversary has found the solution to the GDH problem for us, and \(\mathcal {B}_{0} \) can use \(g^{x_1}\) as its answer to the GDH challenger. Moreover, this is exactly when the event \(abort_{6} \) occurs.

$$\begin{aligned} \textsf {Adv}_{}(break_{6}) = \epsilon _{\text {GDH}}(\mathcal {B}_{0}) \end{aligned}$$

1.1.4 Game 7

In this game, the experiment replaces the session key in the Test session with a uniformly random key from the same space. Because of the event \(abort_6\) in Game 6, we know that the adversary never queried the random oracle \({\mathrm {HKDF}}\) on the input ms that was used to compute the session key \(\textit{rk}_{1} ~\Vert ~\textit{ck}^{ir}_{0,0} \) of the Test session. Thus, in the random oracle model,

$$\begin{aligned} \textsf {Adv}_{6}&= \textsf {Adv}_{7}=0 \end{aligned}$$

since the session key is uniformly random and independent of the hidden bit, and hence the adversary has no advantage in guessing the hidden bit and winning the experiment. We conclude that

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {LM} }(u,i)}}&\le \textsf {n} _{\textsf {M} }(\nicefrac {1}{q} + \epsilon _{\text {GDH}}(\mathcal {B}_{0}) + 0) \end{aligned}$$

1.2 C1.2: Case \(\textit{type}[0] = \texttt {triple} \) and \(\textsf {clean} _{\texttt {EL} }(u,i,0)\)

In this case, the adversary \(\mathcal {A}_{\texttt {triple} }\) has issued a Test query \(\textsf {Test} (u,i,[0])\) such that \(\textsf {clean} _{\texttt {EL} }(u,i,[0])\) is upheld. For Test sessions such that \({\pi _{u}^{i}}.\textit{role}= \texttt {init} \), this means that \(\mathcal {A}_{\texttt {triple} }\) has not issued \(\textsf {RevRand} (u,i,[0])\) and \(\textsf {RevLongTermKey} (v)\) where \(v={\pi _{u}^{i}}.\textit{peeripk}\). For Test sessions such that \({\pi _{u}^{i}}.\textit{role}= \texttt {resp} \), this means that \(\mathcal {A}_{\texttt {triple} }\) has not issued \(\textsf {RevLongTermKey} (u)\) and a \(\textsf {RevRand} (v,j,[0])\) such that \({\pi _{v}^{j}}.\textit{sid}[0]\) matches the Test session \({\pi _{u}^{i}}.\textit{sid}[0]\).

1.2.1 Game 4, 5, 6

The argument for this case is almost identical to that of the previous subcase, except we no longer need to guess the index of the long-term key of the responder or the ephemeral key of the initiator. The GDH challenge values \(g^\alpha \), \(g^\beta \) are inserted into the simulation in Game 5 in place of the ephemeral key of the initiator and the long-term key of the responder, refer to Fig. 12.

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {EL} }(u,i,0)}} \le \nicefrac {1}{q} + \epsilon _{\text {GDH}} \end{aligned}$$
Fig. 13
figure 13

A diagram showing the replacement of secrets in Game 6 of Case 1.3. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case Diagram legend can be found in Fig. 10 (Color figure online)

1.3 C1.3: Case \(\textit{type}[0] = \texttt {triple} \) and \(\textsf {clean} _{\texttt {EM} }(u,i,[0])\)

1.3.1 Game 4, 5, 6, 7

In this case, the adversary \(\mathcal {A}_{\texttt {triple} }\) has issued a Test query \(\textsf {Test} (u,i,[0])\) such that \(\textsf {clean} _{\texttt {EM} }(u,i,[0])\) is upheld. For Test sessions such that \({\pi _{u}^{i}}.\textit{role}= \texttt {init} \), this means that \(\mathcal {A}_{\texttt {triple} }\) has not issued a \(\textsf {RevRand} (u,i,0)\) and \(\textsf {RevMedTermKey} (v,{\pi _{u}^{i}}.\textsf {peerpreid} )\). For Test sessions such that \({\pi _{u}^{i}}.\textit{role}= \texttt {resp} \), this means that \(\mathcal {A}_{\texttt {triple} }\) has not issued a \(\textsf {RevRand} (v,j,[0])\) such that \({\pi _{v}^{j}}.\textit{sid}[0]\) matches the Test session \({\pi _{u}^{i}}.\textit{sid}[0]\) and \(\textsf {RevMedTermKey} (u, {\pi _{u}^{i}}.\textit{prepk})\).

Again, this is analogous to before. We begin by guessing the index of the signed prekey of the responder, incurring a factor of \(\textsf {n} _{\textsf {M} }\). By the definition of the cleanness predicate \(\textsf {clean} _{\texttt {EM} }(u,i,[0])\), since both the ephemeral key of the initiator and the first ratchet key of the initiator are generated during the initial key exchange and used to derive the first message key, we might use either the ratchet key or the ephemeral key of the initiator as the basis for our game hop. We choose to embed the Gap-DH challenge values \(g^\alpha , g^\beta \) into the simulation in Game 6 in place of the ephemeral key of the initiator and the particular medium-term key of the responder used in the Test session, refer to Fig. 13. Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {EM} }(u,i,0)}} \le \textsf {n} _{\textsf {M} }\cdot (\nicefrac {1}{q} + \epsilon _{\text {GDH}}) \end{aligned}$$

C2: Initial key exchange: \(\textit{type}[0]=\texttt {triple+DHE} \)

Recall that the initial key exchange can also have type \(\texttt {triple+DHE} \), in which case cleanness requires that

$$\begin{aligned} \textsf {clean} _{\texttt {LM} }(u,i) \vee \textsf {clean} _{\texttt {EL} }(u,i,[0]) \vee \textsf {clean} _{\texttt {EM} }(u,i,[0]) \vee \textsf {clean} _{\texttt {EE} }(u,i,[0]) \end{aligned}$$

We now consider the case that the adversary has issued a Test query \(\textsf {Test} (u,i,[0])\) where the stage \({\pi _{u}^{i}}.\textit{type}[0] = \texttt {triple+DHE} \). We note that three of the subcases are the same as previously, with the additional subcase \(\textsf {clean} _{\texttt {EE} }(u,i,[0])\). As before, we define

  • \(E^{\texttt {triple+DHE} }_{\textsf {clean} _{\texttt {LM} }}\) to be the event that an adversary wins the multi-stage key-indistinguishability game where \(\mathcal {A}\) has issued a Test query \(\textsf {Test} (u,i,[0])\) and \(\textsf {clean} _{\texttt {LM} }(u,i)\) is upheld,

  • \(E^{\texttt {triple+DHE} }_{\textsf {clean} _{\texttt {EM} }}\) where \(\mathcal {A}\) has issued a Test query \(\textsf {Test} (u,i,[0])\) and \(\textsf {clean} _{\texttt {EM} }(u,i,[0])\) is upheld,

  • \(E^{\texttt {triple+DHE} }_{\textsf {clean} _{\texttt {EL} }}\) where \(\mathcal {A}\) has issued a Test query \(\textsf {Test} (u,i,[0])\) and \(\textsf {clean} _{\texttt {EL} }(u,i,[0])\) is upheld, and

  • \(E^{\texttt {triple+DHE} }_{\textsf {clean} _{\texttt {EE} }}\) where \(\mathcal {A}\) has issued a Test query \(\textsf {Test} (u,i,[0])\) and \(\textsf {clean} _{\texttt {EE} }(u,i,[0], [0])\) is upheld.

By definition of \(\textsf {clean} _{\texttt {triple+DHE} }\):

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C2}}&\le \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {LM} }(u,i)}} + \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EL} }(u,i,[0])}} + \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EM} }(u,i,[0])}}\\&\quad + \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])}} \end{aligned}$$

The bounds above are proved to be negligible under our cryptographic assumptions exactly as above, yielding the inequalities as desired. As before, the crucial proof step in each case is the Gap-Diffie–Hellman (DH) assumption. However, for this case it will also make a game hop like Game 3, where we additionally know Bob’s unique matching session in advance. We can do this now because Bob has freshness in the handshake.

Fig. 14
figure 14

A diagram showing the replacement of secrets in Game 6 of Case 2.4. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case Diagram legend can be found in Fig. 10 (Color figure online)

1.1 C2.4: Case \(\textit{type}[0] = \texttt {triple+DHE} \) and \(\textsf {clean} _{\texttt {EE} }\)

1.1.1 Game 4, 5, 6, 7

The final ephemeral–ephemeral case \(E^{\texttt {triple+DHE} }_{\textsf {clean} _{\texttt {EE} }}\) is analogous to previous cases except that in Game 6 \((E^{\texttt {triple+DHE} }_{\textsf {clean} _{\texttt {EE} }})\), we need to replace the ephemeral values of both the initiator and the responder, refer to Fig. 14. (Since the simulator in \(G4\) will never reuse ephemeral values in a different session, the simulation in this case is simpler and will not need to use its DDH oracle to maintain consistency.) We have to consider that the responder party generates a list of one-time ephemeral keys that new sessions (used in sessions executed by the responder) may use, and thus \(G4\) now incurs a factor of \(\textsf {n} _{\textsf {S} }\). Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])}} \le \textsf {n} _{\textsf {S} }\cdot (\nicefrac {1}{q} + \epsilon _{\text {GDH}}) \end{aligned}$$

C3: Asymmetric Ratcheting, Initial Stage

We have now proved security of the initial key exchange, optionally including the ephemeral–ephemeral Diffie–Hellman (DH) computation. We next move on to the asymmetric-ratcheting stages, in which Bob and Alice take turns generating new Diffie–Hellman (DH) ephemeral values and updating their root keys. The first asymmetric-ratcheting stage differs slightly from its successors since it immediately follows the initial handshake, and we deal with it here now. Recall it is of type \(\texttt {asym-ri} \), since it is performed when Bob wishes to send a message to Alice.

We consider an adversary \(\mathcal {A}\) that issues a \(\textsf {Test} (u,i, s = [{\mathbf{asym\text {-}ri }\text {:}1} ])\) query, where stage s must have \(\textit{type}= \texttt {asym-ri} \). Note that the initial asymmetric stage is always of type \(\texttt {asym-ri} \) (messages from Alice to Bob before this stage are sent using the symmetric chain derived from the initial handshake), and thus in this section we do not need to consider initial stages of type \(\texttt {asym-ir} \). We define

  • \(E^{\texttt {asym-ri} }_{}\) to be the event that an adversary \(\mathcal {A}\) wins the multi-stage key-indistinguishability game by issuing a \(\textsf {Test} (u,i, s = [{\mathbf{asym\text {-}ri }\text {:}1} ])\) query,

  • \(E^{\texttt {asym-ri} }_{\textsf {clean} _{\texttt {EE} }(u,i,[0])}\) to be the sub-event of \(E^{\texttt {asym-ri} }_{}\) satisfying \(\textsf {clean} _{\texttt {EE} }(u, i, [0], [0])\), and

  • \(E^{\texttt {asym-ri} }_{\textsf {clean} _{{\pi _{u}^{i}}.\textit{type}[0]}(u,i,[0])}\) to be the sub-event of \(E^{\texttt {asym-ri} }_{}\) satisfying

    $$\begin{aligned} \textsf {clean} _{{\pi _{u}^{i}}.\textit{type}[0]}(u,i,[0]) \wedge \textsf {clean} _{\textsf {state} }(u,i,[{\mathbf{asym\text {-}ri }\text {:}1} ]). \end{aligned}$$

It follows from our definition of freshness that

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C3}} \le \textsf {Adv}_{3}^{\mathbf {C3},{\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])}} + \textsf {Adv}_{3}^{\mathbf {C3},{\textsf {clean} _{{\pi _{u}^{i}}.\textit{type}[0]}(u,i,[0])}} \end{aligned}$$
(1)

and we consider these two cases in turn, beginning with the case that \(\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])\) is upheld.

Fig. 15
figure 15

A diagram showing the replacement of secrets in Game 6 of Case 3.1. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case. Diagram legend can be found in Fig. 10 (Color figure online)

1.1 C3.1: Case \(s=[{\mathbf{asym\text {-}ri }\text {:}1} ]\), \(\textit{type}[s]=\texttt {asym-ri} \) and \({\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])}\)

1.1.1 Game 4, 5, 6, 7

This case is dealt with similarly to subcase 2.4, with the only substantial differences being that the GDH challenge values are substituted into the ratchet keys \(g^{\textit{rchk}^{[0]}_{u}}\) and \(g^{\textit{rchk}^{[0]}_{v}}\) (refer to Fig. 15) and we do not need to guess the index of the ratchet keys. Since the adversary reveals secret ephemeral values for specific stages using the \(\textsf {RevRand} \) query (as opposed to querying specific secret values), the predicate \(\textsf {clean} _{\texttt {EE} }\) covers secrecy both of the initiator’s initial key exchange ephemeral value, and the initiator’s first ratchet key, which are generated at the same time. Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C3},{\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])}} \le \nicefrac {1}{q} + \epsilon _{\text {GDH}} \end{aligned}$$

1.2 C3.2: Case \(s=[{\mathbf{asym\text {-}ri }\text {:}1} ]\), \(\textit{type}[s]=\texttt {asym-ri} \) and \({\textsf {clean} _{{\pi _{u}^{i}}.\textit{type}[0]}(u,i,[0])}\)

In this case, cleanness comes from the initial key exchange (i.e., from one of its three or four disjuncts), and the fact that the adversary has not revealed the state linking the initial key exchange to this stage. The initial key exchange derives \(\textit{rk}_{1} \): we perform one game hop to replace that value with a uniformly random value; the game hop is indistinguishable assuming the security of \(\textit{rk}_{1} \), which follows from Cases 1 and 2. Game \(7'\) is indicated below.

1.2.1 Game \(7'\)

In this game, we replace the root key \(\textit{rk}_{1} \) derived in stage [0] by both the Test session and any matching peers with a uniformly random value, refer to Fig. 16.

An adversary which can distinguish \(G7'\) from its predecessor game can distinguish the root key from a random value. The root key was derived in the initial \(\texttt {triple} \) (or \(\texttt {triple+DHE} \)) handshake by applying \({\mathrm {KDF}}_\text {r}\) to the master secret ms. In Case 1 (or Case 2), we argued that all values derived from ms using \({\mathrm {HKDF}}\) were indistinguishable from random. Thus, an adversary that wins here contradicts the security of Case 1 (or Case 2). Recall that we denote with \(\textsf {Adv}_{3}^{\mathbf {C1}}\) the adversary’s advantage in breaking the key-indistinguishability of Case 1, and with \(\textsf {Adv}_{3}^{\mathbf {C2}}\) we denote the adversary’s advantage in breaking the key-indistinguishability of Case 2. Given that only one of Case 1 or Case 2 applies (given how the initial key exchange is either of type \(\texttt {triple} \) or type \(\texttt {triple+DHE} \)), then the adversary’s probability in distinguishing this change is \(\max \{\textsf {Adv}_{3}^{\mathbf {C1}}, \textsf {Adv}_{3}^{\mathbf {C2}}\}\). Note that \(\textsf {Adv}_{3}^{\mathbf {C1}} \le \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {LM} }(u,i)}} + \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {EL} }(u,i,0)}} + \textsf {Adv}_{3}^{\mathbf {C1},{\textsf {clean} _{\texttt {EM} }(u,i,0)}}\) and \(\textsf {Adv}_{3}^{\mathbf {C2}} \le \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {LM} }(u,i)}} + \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EL} }(u,i,0)}} + \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EM} }(u,i,0)}} \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])}}\), and that the upper bounds on the first three subcases of both Case 1 and Case 2 are identical.

Fig. 16
figure 16

A diagram showing the replacement of secrets in Game 7’ of Case 3.2. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; denotes secrets that are not relevant to this case; and denotes secrets one of which is assumed uncompromised but the rest may be revealed by \(\mathcal {A}\). Diagram legend can be found in Fig. 10 (Color figure online)

After replacing the root key \(\textit{rk}_{1} \), it is straightforward to see that it is impossible for the adversary to differentiate keys derived in this stage—chaining keys \(\textit{ck}^{ri}_{x,0} \) and \(\textit{ck}^{ri}_{x,1} \), messaging key \(\textit{mk}^{ri}_{x,0} \), and intermediate value tmp from random: these are derived by applying \({\mathrm {KDF}}_\text {r}\) to \(\textit{rk}_{1} \) and then \({\mathrm {KDF}}_\text {m}\) to that result. Since both KDFs are modelled as random oracles, and the input to \({\mathrm {KDF}}_\text {r}\) is an independent uniformly random value, the adversary has no advantage is distinguishing this stage’s session key from random. For readability, we define \(\textsf {Adv}_{3}^{\mathbf {C3},{\textsf {clean} _{{\pi _{u}^{i}}.\textit{type}[0]}(u,i,[0])}}=\textsf {Adv}_{3}^{\mathbf {C3.2}}\). Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C3.2}} \le \max \{\textsf {Adv}_{3}^{\mathbf {C1}}+\textsf {Adv}_{3}^{\mathbf {C2}}\} \end{aligned}$$

C4: Asymmetric Ratcheting, Non-initial Stages

At this point, we move on to arbitrary subsequent asymmetric stages. We assume that the initial handshake was of type \(\texttt {triple} \), but the case of \(\texttt {triple+DHE} \) is analogous. The intuition for this part of the proof is essentially induction and post-compromise security:

  • root keys provide security because they come from previous stages which are secure; or

  • shared secrets derived from pairs of ephemeral keys provide security even if the root key at the time is compromised.

We first make a case distinction on the direction (Case 4.1: \(\texttt {asym-ir} \) vs. Case 4.2: \(\texttt {asym-ri} \)) and then deal with these cases in turn. Thus, \(\textsf {Adv}_{3}^{\mathbf {C4}} \le \textsf {Adv}_{3}^{\mathbf {C4.1}} + \textsf {Adv}_{3}^{\mathbf {C4.2}}\).

1.1 C4.1: Asymmetric Ratcheting, \(s=[{\mathbf{asym\text {-}ir }\text {:}x} ], x\ge 1\), \(\textit{type}[s]=\texttt {asym-ir} \)

Definition 8 requires that one of the following conditions must be satisfied if \(\textsf {clean} _{\texttt {asym-ir} }(u,i,[{\mathbf{asym\text {-}ir }\text {:}x} ])\) is to hold.

  • event \(E^{\texttt {asym-ir} }_{\text {clean-prev}}\): \(\textsf {clean} _{\texttt {asym-ri} }(u,i,[{\mathbf{asym\text {-}ri }\text {:}x-1} ]) \wedge \textsf {clean} _{\textsf {state} }(u,i,[{\mathbf{asym\text {-}ir }\text {:}x} ])\)

  • event \(E^{\texttt {asym-ir} }_{\text {clean-cur}}\): \(\textsf {clean} _{\texttt {EE} }(u,i,x-1, x-1)\)

Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C4.1}} \le \textsf {Adv}_{3}^{\mathbf {C4.1},{\textsf {clean} _{\textsf {prev}}}} + \textsf {Adv}_{3}^{\mathbf {C4.1},{\textsf {clean} _{\texttt {EE} }(u,i,x-1,x-1)}} \end{aligned}$$

1.2 C4.1.1: Case \(s=[{\mathbf{asym\text {-}ir }\text {:}x} ], x\ge 1\), \(\textit{type}[s]=\texttt {asym-ir} \) and \(E^{\texttt {asym-ir} }_{\text {clean-prev}}\)

Fig. 17
figure 17

A diagram showing the replacement of secrets in Game 7’ of Case 4.1.1. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case. Diagram legend can be found in Fig. 10 (Color figure online)

This case follows inductively like Case 3.2. This stage’s message key (as well as the next root and chaining key) is derived by applying \({\mathrm {KDF}}_\text {r}\) to tmp, which was derived during stage \([{\mathbf{asym\text {-}ri }\text {:}x} ]\), and then \({\mathrm {KDF}}_\text {m}\) to the result. By an argument similar to Case 3.2, we can replace tmp with a random key, refer to Fig. 17. Treating the KDF as a random oracle, this stage’s message key, the next root key \(\textit{rk}_{x+1} \) and the symmetric chaining keys \(\textit{ck}^{ir}_{x,0} \) and \(\textit{ck}^{ir}_{x,1} \) are then indistinguishable from random. For readability, we denote \(\textsf {Adv}_{3}^{\mathbf {C4.1},{\textsf {clean} _{\textsf {prev}}}} = \textsf {Adv}_{3}^{\mathbf {C4.1.1}}\), \(\textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {LM} }(u,i)}}=\textsf {Adv}_{3}^{\mathbf {C2.1}}\), \(\textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EL} }(u,i,[0])}}=\textsf {Adv}_{3}^{\mathbf {C2.2}}\), \(\textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EM} }(u,i,[0])}}=\textsf {Adv}_{3}^{\mathbf {C2.3}}\), \(\textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])}}=\textsf {Adv}_{3}^{\mathbf {C2.4}}\). Thus:

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C4.1.1}} \le \nicefrac {1}{q} + \textsf {Adv}_{3}^{\mathbf {C2.1}} + \textsf {Adv}_{3}^{\mathbf {C2.2}} + \textsf {Adv}_{3}^{\mathbf {C2.3}} + \textsf {Adv}_{3}^{\mathbf {C2.4}} + \epsilon _{\text {GDH}} \end{aligned}$$
Fig. 18
figure 18

A diagram showing the replacement of secrets in Game 7’ of Case 4.1.2. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case. Diagram legend can be found in Fig. 10 (Color figure online)

1.3 C4.1.2: Case \(s=[{\mathbf{asym\text {-}ir }\text {:}x} ], x\ge 1\), \(\textit{type}[s]=\texttt {asym-ir} \) and \(E^{\texttt {asym-ir} }_{\text {clean-cur}}\)

This case is analogous to Case 3.1, with key indistinguishability following from secrecy of the DH shared secret derived from ratchet keys. We first replace the ratchet public keys with challenge values from the Gap-DH game, noting that \(\textsf {clean} _{\texttt {EE} }\) implies the existence of a unique session at Bob with the same sid as that of Alice’s session, refer to Fig. 18. As before, an adversary which could distinguish this game from its predecessor allows us to answer the Gap-Diffie–Hellman (DH) challenge, violating that assumption. Indistinguishability of this stage’s message key, as well as the next root and chaining keys enumerated in Case 4.4.1, then follows from applying the (random oracle) KDF to the (now independent) DH shared secret. Thus:

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C4.1},{\textsf {clean} _{\texttt {EE} }(u,i,x-1,x-1)}} \le \nicefrac {1}{q} + \epsilon _{\text {GDH}} \end{aligned}$$
Fig. 19
figure 19

A diagram showing the replacement of secrets in Game 7’ of Case 4.2.1. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case. Diagram legend can be found in Fig. 10 (Color figure online)

1.4 C4.2: Asymmetric Ratcheting, \(s=[{\mathbf{asym\text {-}ri }\text {:}x} ], x>1\), \(\textit{type}[s]=\texttt {asym-ri} \)

Now we come to the case of non-initial asymmetric stages of type \(\texttt {asym-ri} \). The proof here is nearly the same as in Case 4.1, except there is an extra KDF application: session keys derived by these stages are computed by first applying a KDF to derive an intermediate value tmp, and second applying another KDF to derive from tmp a session key.

Similarly, we partition our analysis into the following cases.

  • event \(E^{\texttt {asym-ri} }_{\text {clean-prev}}\): \(\textsf {clean} _{\texttt {asym-ir} }(u,i, [{\mathbf{asym\text {-}ir }\text {:}x} ])\)

  • event \(E^{\texttt {asym-ri} }_{\text {clean-cur}}\): \(\textsf {clean} _{\texttt {EE} }(u,i,x, x-1)\)

1.5 C4.2.1: Case \(s=[{\mathbf{asym\text {-}ri }\text {:}x} ], x> 1\), \(\textit{type}[s]=\texttt {asym-ri} \) and \(E^{\texttt {asym-ri} }_{\text {clean-prev}}\)

Once again the inductive argument here is analogous to Case 3.2: secrecy follows from the root key, and so we begin by replacing the root key with a random value, refer to Fig. 19. Detecting this change would violate the security properties of the previous stage, but after it the session key is easily proven indistinguishable from random. This stage’s message key \(\textit{mk}^{ri}_{x,0} \) as well as symmetric chaining keys \(\textit{ck}^{ri}_{x,0} \) and \(\textit{ck}^{ri}_{x,1} \) and intermediate value tmp, are all also then indistinguishable from random. For readability, we denote \(\textsf {Adv}_{3}^{\mathbf {C4.2},{\textsf {clean} _{\textsf {prev}}}} = \textsf {Adv}_{3}^{\mathbf {C4.2.1}}\), \(\textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {LM} }(u,i)}}=\textsf {Adv}_{3}^{\mathbf {C2.1}}\), \(\textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EL} }(u,i,[0])}}=\textsf {Adv}_{3}^{\mathbf {C2.2}}\), \(\textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EM} }(u,i,[0])}}=\textsf {Adv}_{3}^{\mathbf {C2.3}}\), \(\textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EE} }(u,i,[0],[0])}}=\textsf {Adv}_{3}^{\mathbf {C2.4}}\). Thus:

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C4.2.1}} \le \nicefrac {1}{q} + \textsf {Adv}_{3}^{\mathbf {C2.1}} + \textsf {Adv}_{3}^{\mathbf {C2.2}} + \textsf {Adv}_{3}^{\mathbf {C2.3}} + \textsf {Adv}_{3}^{\mathbf {C2.4}} + \epsilon _{\text {GDH}} \end{aligned}$$

1.6 C4.2.2: Case \(s=[{\mathbf{asym\text {-}ri }\text {:}x} ], x> 1\), \(\textit{type}[s]=\texttt {asym-ri} \) and \(E^{\texttt {asym-ri} }_{\text {clean-cur}}\)

For this case, we proceed similarly to Case 3.1. The DH shared secret can be shown indistinguishable under the Gap-DH assumption by replacing the ratchet public keys \(\textit{rchk}^{u}_{x}, \textit{rchk}^{v}_{x-1} \) of the Test session and its matching peer with values from a GDH challenger, refer to Fig. 20. Indistinguishability of the stage’s message key, symmetric chaining keys, and intermediate value tmp (as enumerated in case 4.2.1) all follow in turn from applying a (random oracle) KDF to (now independent) secret values. Thus:

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C4.2},{\textsf {clean} _{\texttt {EE} }(u,i,x-1,x-1)}} \le \nicefrac {1}{q} + \epsilon _{\text {GDH}} \end{aligned}$$
Fig. 20
figure 20

A diagram showing the replacement of secrets in Game 3 of Case 4.2.2. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; and denotes secrets that are not relevant to this case. Diagram legend can be found in Fig. 10 (Color figure online)

C5: Symmetric Ratcheting: \(\textit{type}[s]\in \{\texttt {sym-ir} ,\texttt {sym-ri} \}\)

We finally arrive at the case of Signal in the multi-stage key-indistinguishability game against an adversary \(\mathcal {A}\) that issues a \(\textsf {Test} (u,i,[{\mathbf{sym\text {-}ir }\text {:}x,y} ])\) or \(\textsf {Test} (u,i,[{\mathbf{sym\text {-}ri }\text {:}x,y} ])\) query against some symmetric stage. Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C5}} \le \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} } + \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ri} } \end{aligned}$$

In all subcases, we will show that the probability of winning is \(\nicefrac {1}{2}\).

1.1 C5.1: Symmetric Ratcheting, \(s=[{\mathbf{sym\text {-}ir }\text {:}x,y} ], \textit{type}[s]=\texttt {sym-ir} \)

We partition into the three different freshness conditions for the case \([{\mathbf{sym\text {-}ir }\text {:}x,y} ]\). We then cover the case of \([{\mathbf{sym\text {-}ri }\text {:}x,y} ]\) similarly. The intuition is that for the first stage, the symmetric keys are derived from an asymmetric update and their secrecy follows from the previous cases. For subsequent stages, we have security due to the recursive nature of the freshness condition: we can replace the chain key used to derive the message key with randomness; if the simulation did not work, then the adversary could attack the previous stage, which is a contradiction to security of previous cases because the previous stage is fresh. In all symmetric stages, no new ephemeral keying material is introduced, so security depends solely on the chaining state not being leaked (which is guaranteed for these cases by \(\textsf {clean} _{\textsf {state} }\)). Thus:

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} } \le \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} , x= 0, y= 1} + \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} , x> 0, y= 1} + \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} , x\ge 0, y> 1} \end{aligned}$$
Fig. 21
figure 21

A diagram showing the replacement of secrets in Game 7’ of Case 5.1.2. All other subcases follow a similar replacement strategy. In particular, denotes secrets that the adversary may compromise via Reveal queries (or by computing the secrets as a result of the Reveal query); denotes secrets that are replaced with the output of a Test query from a Case 1 or Case 2 challenger; denotes secrets that the challenger is able to replace with random, thus ensuring security; denotes secrets that are not relevant to this case; and denotes secrets one of which is assumed uncompromised but the rest may be revealed by \(\mathcal {A}\). Diagram legend can be found in Fig. 10 (Color figure online)

(Recall that the case \(y=0\) is performed as part of the message key derivation in the previous asymmetric update, so that the first symmetric stage derives key number 1.)

1.2 C5.1.1: Case \(s=[{\mathbf{sym\text {-}ir }\text {:}x,y} ], x= 0, y= 1\), \(\textit{type}[s]=\texttt {sym-ir} \)

This stage’s messaging key is derived by applying a \({\mathrm {KDF}}_\text {m}\) to \(\textit{ck}^{ir}_{0,1} \), which was derived during the initial \(\texttt {triple} \) or \(\texttt {triple+DHE} \) handshake. By Case 3.2, \(\textit{ck}^{ir}_{0,1} \) is indistinguishable from random, refer to Fig. 21. Like the argument in Case 3.2, treating \({\mathrm {KDF}}_\text {m}\) as a random oracle, this stage’s messaging key and the next chaining key \(\textit{ck}^{ir}_{0,2} \) are thus indistinguishable from random. Thus,

$$\begin{aligned}&\textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} , x= 0, y= 1} \le \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {LM} }(u,i)}} + \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EL} }(u,i,[{\mathbf{ }\text {:}0,} ]))}} + \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EM} }(u,i,[{\mathbf{ }\text {:}0,} ]))}}\\&\quad + \textsf {Adv}_{3}^{\mathbf {C2},{\textsf {clean} _{\texttt {EE} }(u,i,[{\mathbf{ }\text {:}0,} ],[{\mathbf{ }\text {:}0,} ])}} \end{aligned}$$

1.3 C5.1.2: Case \(s=[{\mathbf{sym\text {-}ir }\text {:}x,y} ], x> 0, y> 1\), \(\textit{type}[s]=\texttt {sym-ir} \)

This stage’s messaging key is derived by applying a \({\mathrm {KDF}}_\text {m}\) to \(\textit{ck}^{ir}_{x,1} \), which was derived during asymmetric second-stage \([{\mathbf{asym\text {-}ir }\text {:}x} ]\). By Case 4.1, \(\textit{ck}^{ir}_{x,1} \) is indistinguishable from random. Like the argument in Case 2, treating \({\mathrm {KDF}}_\text {m}\) as a random oracle, this stage’s messaging key and the next chaining key \(\textit{ck}^{ir}_{x,2} \) are thus indistinguishable from random. Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} , x> 0, y= 1} \le \textsf {Adv}_{3}^{\mathbf {C4.1},{\textsf {clean} _{\textsf {prev}}}} + \textsf {Adv}_{3}^{\mathbf {C4.1},{\textsf {clean} _{\texttt {EE} }(u,i,x-1,x-1)}} \end{aligned}$$

1.4 C5.1.3: Case \(s=[{\mathbf{sym\text {-}ir }\text {:}x,y} ], x\ge 0, y. 1\), \(\textit{type}[s]=\texttt {sym-ir} \)

This stage’s messaging key is derived by applying a \({\mathrm {KDF}}_\text {m}\) to \(\textit{ck}^{ir}_{x,y} \), which was derived during symmetric stage \([{\mathbf{sym\text {-}ir }\text {:}x} ]{y-1}\). By Case 5.1.1, 5.1.2, or induction on Case 5.1.3, \(\textit{ck}^{ir}_{x,y-1} \) is indistinguishable from random. Like the argument in case 3.2, treating \({\mathrm {KDF}}_\text {m}\) as a random oracle, this stage’s messaging key and the next chaining key \(\textit{ck}^{ir}_{x,y+1} \) are thus indistinguishable from random. Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} , x\ge 0, y> 1} \le \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} , x= 0, y= 1} + \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} , x> 0, y= 1} \end{aligned}$$

1.5 C5.2: Symmetric ratcheting, \(s=[{\mathbf{sym\text {-}ri }\text {:}x,y} ], \textit{type}[s]=\texttt {sym-ri} \)

These cases are analogous to Case 5.1, by symmetry: cleanness is defined in the same recursive manner for both \(\texttt {sym-ir} \) and \(\texttt {sym-ri} \) stages, except that the base cases differ. The initial game hops are thus analogous to those in the \(\texttt {asym-ir} \) and \(\texttt {asym-ri} \), respectively, and the subsequent inductive argument is analogous to Case 5.1.3. Thus,

$$\begin{aligned} \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ri} } = \textsf {Adv}_{3}^{\mathbf {C5}, \texttt {sym-ir} } \end{aligned}$$

Achieving a Standard Model Proof of the Signal Protocol

One drawback of the proof as it currently stands is that it sits within the random oracle model. This is an assumption which has received some criticism from parts of the cryptographic community because, while it is a useful assumption for proofs, it can never be satisfied in reality [9, 39]. There are even pathological constructions which are provably secure with random oracles, but which can never be secure when the random oracle is replaced with any concrete primitive [5, 19]. While the use of the random oracle model does not imply an attack, and in fact sometimes deliberately avoiding it can cause more severe problems [46], its use may be unsettling for some.

Therefore, in this section, we outline the process in which one could attempt a standard model proof of the Signal Protocol in our security model. This is not a straightforward task; a naive attempt would be by retaining the current structure of our proof and replacing Gap-DH assumptions with a pair of DDH and PRF security assumptions. However, this approach does not fit. Similarly to previous proofs of TLS [30, 42], we find ourselves relying instead on the PRF-ODH assumption. There are many different variants of the PRF-ODH assumption throughout the literature; see [18] for a detailed exposition of these variants. However, the crux of the assumption is as follows. Given \(g^u\) and \(g^v\), computing a function \({\mathrm {PRF}}(g^{uv}, x)\) should be hard, even with choice of x and an oracle that computes values like \({\mathrm {PRF}}(g^{uw}, x')\) and \({\mathrm {PRF}}(g^{wv}, x')\) for chosen \(w \ne u, v\).

Roughly speaking, the reason a PRF-ODH assumption is required is that there are long-lived keys used in key computations in Signal that must be simulated when they are substituted out in the game hops. Before, we used a random oracle—which, by definition, gives random replies that the simulator could just choose randomly but consistently—to simulate these key computations. Now, we need a Diffie–Hellman oracle from the PRF-ODH assumption to carry out the simulation. Because Signal computes keys using a PRF on Diffie–Hellman values, it seems at least plausible that some version of a PRF-ODH assumption may work for a proof.

Readers may ask why we cannot simply retain the current structure of our proof and replace the Gap-DH assumptions with a single PRF-ODH step. As discussed in Sect. 2 (and wholly unlike TLS), the Diffie–Hellman values used in Signal can be long term, medium term, or ephemeral. These keys are also used in different combinations in key derivations. This difference requires that we not use a single PRF-ODH assumption, but a range of PRF-ODH assumptions that are parameterized by how many times the challenger will generate \({\mathrm {PRF}}(g^{uv'},x)\) and \({\mathrm {PRF}}(g^{u'v},x)\) values upon being queried for a “left” or “right” PRF-ODH oracle \((g^{v'},x)\) or \((g^{u'},x)\) (where \(g^{u'}\) and \(g^{v'}\) are not one of the DH challenge values \((g^u,g^v)\) given by the challenger). We give a formal definition below from the work by Brendel et. al. [18].

Definition 10

(Generic PRF-ODH assumption) Let \(\mathbb {G}\) be a cyclic group of order q with generator g. Let \({\mathrm {PRF}}:\mathbb {G}\times \{0,1\}^* \rightarrow \{0,1\}^{\lambda }\) be a pseudo-random function that takes as key input an element \(k \in \mathbb {G}\) and an arbitrary-length salt value \(x \in \{0,1\}^*\) as input and outputs a value \(y \in \{0,1\}^{\lambda }\).

We define a generalized security notion lr-\(\textsf {PRF-ODH}\), which is parameterized by \(l,r \in \{\textsf {n},\textsf {s},\textsf {m}\}\), indicating how often the adversary is able to query a certain left oracle or right oracle (denoted \(\textsf {ODH}_u\) and \(\textsf {ODH}_v\), respectively) where \(\textsf {n}\) indicates that no query is allowed, \(\textsf {s}\) indicates that a single query is allowed, and \(\textsf {m}\) indicates that arbitrarily many queries are allowed to the respective oracle. Consider the lr-\(\textsf {PRF-ODH}\) security experiment depicted in Fig. 22.

Fig. 22
figure 22

Security experiments for the generic \(\textsf {PRF-ODH}\) assumption, and the symmetric \(\textsf {PRF-ODH}\) assumption. Note that both experiments make use of identical \(\textsf {ODH}_u\) and \(\textsf {ODH}_v\) oracles

We say that the adversary \(\mathcal {A}\) wins the lr-\(\textsf {PRF-ODH}\) game if \(b'=b\) and define the following advantage function:

$$\begin{aligned} \textsf {Adv}^{lr\text {-}\textsf {PRF-ODH}}_{{\mathrm {PRF}},\mathbb {G}}(\mathcal {A}):=|\Pr (\textsf {Exp}^{lr\text {-} \textsf {PRF-ODH}}_{{\mathrm {PRF}},\mathbb {G},g,q}(\mathcal {A}) = 1)-\frac{1}{2}| \end{aligned}$$

To add to the difficulty, these left-and-right generic PRF-ODH assumption variants do not allow the adversary to query both sides of the DH keyshares multiple times before the challenger generates the secret value, which would be the case in the replacement of the long-term and medium-term secrets (refer to Case 1.1), which means that we would need to further modify the generic PRF-ODH assumption to the needs of our particular Signal Protocol proof. We call this a symmetric generic \(\textsf {PRF-ODH}\) problem, which we define below.

Definition 11

(Symmetric PRF-ODH assumption) Let \(\mathbb {G}\) be a cyclic group of order q with generator g. Let \({\mathrm {PRF}}:\mathbb {G}\times \{0,1\}^* \rightarrow \{0,1\}^{\lambda }\) be a pseudo-random function that takes as key input an element \(k \in \mathbb {G}\) and an arbitrary-length salt value \(x \in \{0,1\}^*\) as input and outputs a value \(y \in \{0,1\}^{\lambda }\).

We define a symmetric security notion lr-\(\textsf {sPRF-ODH}\), which is parameterized by \(l,r \in \{\textsf {n},\textsf {s},\textsf {m}\}\), indicating how often the adversary is able to query a certain left oracle or right oracle (denoted \(\textsf {ODH}_u\) and \(\textsf {ODH}_v\), respectively) where \(\textsf {n}\) indicates that no query is allowed, \(\textsf {s}\) indicates that a single query is allowed, and \(\textsf {m}\) indicates that polynomially many queries are allowed to the respective oracle. Consider the security game \(\textsf {Exp}^{lr\text {-}\textsf {sPRF-ODH}}_{{\mathrm {PRF}},\mathbb {G},g,q}(\mathcal {A})\) described in Fig. 22. We say that the adversary \(\mathcal {A}\) wins the lr-\(\textsf {sPRF-ODH}\) game if \(b'=b\) and define the following advantage function:

$$\begin{aligned} \textsf {Adv}^{lr\text {-}\textsf {sPRF-ODH}}_{{\mathrm {PRF}},\mathbb {G},\mathcal {A}}(\lambda ):=|\Pr (\textsf {Exp}^{lr\text {-} \textsf {sPRF-ODH}}_{{\mathrm {PRF}},\mathbb {G},g,q}(\mathcal {A}) = 1)-\frac{1}{2}| \end{aligned}$$

However, Brendel et al. [18] also show (via a algebraic reduction and meta-reduction argument) that the existence of any efficient black-box reduction from the \(\textsf {sn}/\textsf {ns}\)-\(\textsf {PRF-ODH}\) problem to a decisional Diffie–Hellman-augmented (DDHa) problem would imply that either the DDHa problem or the decisional-square Diffie–Hellman problem is not hard. The DDHa assumption is a class of assumptions, roughly stating that the adversary cannot efficiently win between either the decisional Diffie–Hellman problem or some other independent cryptographic problem. This, the authors argue, shows that the existence of a standard-model instantiation of any generic \(\textsf {PRF-ODH}\) problem (excepting \(\textsf {nn}\)-\(\textsf {PRF-ODH}\)) is impossible, assuming the aforementioned problems are indeed hard. So constructing a standard model proof of the Signal Protocol using generic PRF-ODH based assumptions could be moot.

There is, however, some advantage to this effort: it would bring clarity to which of the cases would be easier for the adversary to break. In the work by Brendel et. al., the relations and separations between the variants of lr-\(\textsf {PRF-ODH}\) are shown, and thus the security of each of the cases is able to be compared concretely. In our current proof, the adversary seemingly does not have an advantage targeting one particular case over another. Now we have all the tools we would require to consider how the security proof in each case would work. We consider each case below and explain which flavour of \(\textsf {PRF-ODH}\) is required and why.

  • Case 1.1 In Game 6 of Case 1.1, we know that the long-term identity key of party u and the medium-term key of the peer v have not been compromised by the adversary, and thus we can replace the key shares \(\textit{ipk}^{u} \), \(\textit{prepk}^{v} \) and the computed root key \(\textit{rk}_{1} \) and first-stage chain key \(\textit{ck}^{ir}_{0,0} \) with \(\textsf {PRF-ODH}\) challenge values. Since both of these Diffie–Hellman key shares can be used in multiple sessions, and (potentially) may be used before the Test session has initialized, we require many \(\textsf {ODH}_u\) and \(\textsf {ODH}_v\) queries at the start of the experiment before the challenge salt value x is computed. Thus, we require the \(\textsf {mm}\)-\(\textsf {sPRF-ODH}\) assumption, the strongest variant of the PRF-ODH problem. In this case, we treat the keys \(\textit{ipk}^{u} \) and \(\textit{prepk}^{v} \) as the keys to the \(\textsf {PRF-ODH}\) problem (which is now internal to the \(\textsf {mm}\)-\(\textsf {sPRF-ODH}\) game) and the following (potentially revealed) secrets \(\textit{ipk}^{v} \) and \(\textit{ek}^{u} \) values as the salt value x that is queried to the \(\textsf {mm}\)-\(\textsf {sPRF-ODH}\) challenger. The challenge value \(y_b\) output by the challenger is then used to replace the \(\textit{rk}_{1} \), \(\textit{ck}^{ir}_{0,0} \) values in both the Tested session and its peer session that is used in computing the message key \(\textit{mk}^{ir}_{0,0} \) which was Tested by the adversary. In order to ensure that the message key \(\textit{mk}^{ir}_{0,0} \) is indistinguishable from random, we need an additional PRF game to replace the computation of \(\textit{mk}^{ir}_{0,0} \) from \({\mathrm {KDF}}_{m}\), and use the output from the PRF challenger to replace \(\textit{mk}^{ir}_{0,0} \). Thus, an adversary capable of distinguishing these changes would also be capable of breaking the PRF security of \({\mathrm {KDF}}_{m}\), or the \(\textsf {mm}\text {-}\textsf {sPRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\).

  • Case 1.2 In Game 6 of Case 1.2, we know that the predicate \(\textsf {clean} _{\texttt {EL} }(u,i,[0])\) is upheld, which means that the ephemeral key of the initiator and the identity key of the responder have not been compromised by the adversary, and thus we can replace the key shares \(\textit{epk}^{u} \), \(\textit{ipk}^{v} \), and the computed root key \(\textit{rk}_{1} \) and first-stage chain key \(\textit{ck}^{ir}_{0,0} \) with \(\textsf {PRF-ODH}\) challenge values. Since only the identity key of the responder can be used in multiple sessions and (potentially) may be used before the Test session has initialized, we require many \(\textsf {ODH}_u\) queries at the start of the experiment before the challenge salt value x is computed. Thus, we require the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) assumption, a non-symmetric variant of the PRF-ODH problem. In this case, we treat the values \(\textit{ipk}^{v} \), \(\textit{ek}^{u} \) as the keys to the \(\textsf {PRF-ODH}\) problem (which is now internal to the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) game) and the following (potentially revealed) secrets \(\textit{prepk}^{v} \), \(\textit{ik}^{u} \) as the salt value x that is queried to the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) challenger. The challenge value \(y_b\) output by the challenger is then used to replace the \(\textit{rk}_{1} \), \(\textit{ck}^{ir}_{0,0} \) values in both the Tested session and its peer session that is used in computing the message key \(\textit{mk}^{ir}_{0,0} \) which was Tested by the adversary. In order to ensure that the message key \(\textit{mk}^{ir}_{0,0} \) is indistinguishable from random, we need an additional PRF game to replace the computation of \(\textit{mk}^{ir}_{0,0} \) from \({\mathrm {KDF}}_{m}\), and use the output from the PRF challenger to replace \(\textit{mk}^{ir}_{0,0} \). Thus, an adversary capable of distinguishing these changes would also be capable of breaking the PRF security of \({\mathrm {KDF}}_{m}\), or the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\).

  • Case 1.3 In Game 6 of Case 1.3, we know that the predicate \(\textsf {clean} _{\texttt {EM} }(u,i,[0])\) is upheld, which means that the ephemeral key of the initiator and the medium-term key of the responder have not been compromised by the adversary, and thus we can replace the keyshares \(\textit{epk}^{u} \), \(\textit{prepk}^{v} \) and the computed root key \(\textit{rk}_{1} \) and first-stage chain key \(\textit{ck}^{ir}_{0,0} \) with \(\textsf {PRF-ODH}\) challenge values. Since only the signed prekey of the responder can be used in multiple sessions and (potentially) may be used before the Test session has initialized, we require many \(\textsf {ODH}_v\) queries at the start of the experiment before the challenge salt value x is computed. Thus, we require the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) assumption, a non-symmetric variant of the PRF-ODH problem. In this case, we treat the values \(\textit{prepk}^{v} \), \(\textit{ek}^{u} \) as the key to the \(\textsf {PRF-ODH}\) problem (which is now internal to the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) game) and the following (potentially revealed) secrets \(\textit{ipk}^{v} \), \(\textit{ik}^{u} \) values as the salt value x that is queried to the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) challenger. The challenge value \(y_b\) output by the challenger is then used to replace the \(\textit{rk}_{1} \), \(\textit{ck}^{ir}_{0,0} \) values in both the Tested session and its peer session that is used in computing the message key \(\textit{mk}^{ir}_{0,0} \) which was Tested by the adversary. In order to ensure that the message key \(\textit{mk}^{ir}_{0,0} \) is indistinguishable from random, we need an additional PRF game to replace the computation of \(\textit{mk}^{ir}_{0,0} \) from \({\mathrm {KDF}}_{m}\) and use the output from the PRF challenger to replace \(\textit{mk}^{ir}_{0,0} \). Thus, an adversary capable of distinguishing these changes would also be capable of breaking the PRF security of \({\mathrm {KDF}}_{m}\), or the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\).

  • Case 2.1 This is treated identically to Case 1.1, with the same bounds and game hops.

  • Case 2.2 This is treated identically to Case 1.2, with the same bounds and game hops.

  • Case 2.3 This is treated identically to Case 1.3, with the same bounds and game hops.

  • Case 2.4 In Game 6 of Case 2.4, we know that the predicate \(\textsf {clean} _{\texttt {EE} }(u,i,[0])\) is upheld, which means that the ephemeral key of the initiator and the ephemeral key of the responder have not been compromised by the adversary, and thus we can replace the key shares \(\textit{epk}^{u} \), \(\textit{epk}^{v} \) and the computed root key \(\textit{rk}_{1} \) and first-stage chain key \(\textit{ck}^{ir}_{0,0} \) with \(\textsf {PRF-ODH}\) challenge values. Since both keys are ephemerally generated and only used a single time, we require the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) assumption, the weakest non-standard model variant of the PRF-ODH problem. In this case, we treat the \(\textit{epk}^{v} \), \(\textit{ek}^{u} \) as the key to the \(\textsf {PRF-ODH}\) problem (which is now internal to the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) game) and the following (potentially revealed) secrets \(\textit{prepk}^{v} \), \(\textit{ik}^{v} \) and \(\textit{ik}^{u} \) values as the salt value x that is queried to the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) challenger. The challenge value \(y_b\) output by the challenger is then used to replace the \(\textit{rk}_{1} \), \(\textit{ck}^{ir}_{0,0} \) values in both the Tested session and its peer session that is used in computing the message key \(\textit{mk}^{ir}_{0,0} \) which was Tested by the adversary. In order to ensure that the message key \(\textit{mk}^{ir}_{0,0} \) is indistinguishable from random, we need an additional PRF game to replace the computation of \(\textit{mk}^{ir}_{0,0} \) from \({\mathrm {KDF}}_{m}\) and use the output from the PRF challenger to replace \(\textit{mk}^{ir}_{0,0} \). Thus, an adversary capable of distinguishing these changes would also be capable of breaking the PRF security of \({\mathrm {KDF}}_{m}\), or the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\).

  • Case 3.1 In Game 6 of Case 3.1, we know that the predicate \(\textsf {clean} _{\texttt {EE} }(u,i,[{\mathbf{asym\text {-}ri }\text {:}1} ])\) is upheld, which means that the ratchet key of the initiator and the ratchet key of the responder have not been compromised by the adversary, and thus we can replace the key shares \(\textit{rchpk}^{u}_{0} \), \(\textit{rchpk}^{v}_{0} \) and the computed temporary value x and asymmetric-stage chain key \(\textit{ck}^{ri}_{1,0} \) with \(\textsf {PRF-ODH}\) challenge values. Since both keys are ephemerally generated and only used a single time, we require the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) assumption, the weakest non-standard model variant of the PRF-ODH problem. In this case, we treat the values \(\textit{rchpk}^{v}_{0} \), \(\textit{rchk}^{u}_{0} \) as the key to the \(\textsf {PRF-ODH}\) problem (which is now internal to the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) game) and the (potentially revealed) root key \(\textit{rk}_{1} \) of the first stage as the salt value x that is queried to the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) challenger. The challenge value \(y_b\) output by the challenger is then used to replace the x, \(\textit{ck}^{ri}_{1,0} \) values in both the Tested session and its peer session that is used in computing the message key \(\textit{mk}^{ri}_{1,0} \) which was Tested by the adversary. In order to ensure that the message key \(\textit{mk}^{ri}_{1,0} \) is indistinguishable from random, we need an additional PRF game to replace the computation of \(\textit{mk}^{ri}_{1,0} \) from \({\mathrm {KDF}}_{m}\) and use the output from the PRF challenger to replace \(\textit{mk}^{ri}_{1,0} \). Thus, an adversary capable of distinguishing these changes would also be capable of breaking the PRF security of \({\mathrm {KDF}}_{m}\), or the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\).

  • Case 3.2 In Game 6 of Case 3.2, we know that the predicate \(\textsf {clean} _{{\pi _{u}^{i}}.\textit{type}[{\mathbf{ }\text {:}0,} ]}(u,i,[{\mathbf{ }\text {:}0,} ])\) is upheld, which means that initial key-exchange stage has some Diffie–Hellman key share pair that has not been corrupted and that the adversary has not revealed the state linking the initial key-exchange to this stage. Depending on which clean predicate that was upheld in the first stage, the replacement of Diffie–Hellman values is done as in Case 1.1, Case 1.2, Case 1.3 or Case 2.4. We know from these case analysis that the root key \(\textit{rk}_{1} \) is indistinguishable from random, and thus we are able to replace this value with a random value \(\textit{rk}_{1'} \) and note that an adversary capable of distinguishing this change can break the security of Case 1.1, Case 1.2, Case 1.3 or Case 2.4. We then use PRF game hops in a standard way to replace the derivation of the x, \(\textit{ck}^{ri}_{1,0} \) values in both the Tested session and its peer session that is used in computing the message key \(\textit{mk}^{ri}_{1,0} \) which was Tested by the adversary. In order to ensure that the message key \(\textit{mk}^{ri}_{1,0} \) is indistinguishable from random, we need an additional PRF game to replace the computation of \(\textit{mk}^{ri}_{1,0} \) from \({\mathrm {KDF}}_{m}\) and use the output from the PRF challenger to replace \(\textit{mk}^{ri}_{1,0} \). Thus, an adversary capable of distinguishing these changes would also be capable of breaking the PRF security of \({\mathrm {KDF}}_{m}\), or the \(\textsf {mm}\)-\(\textsf {sPRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\) (as in Case 1.1), or the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\) (as in Cases 1.2 and 1.3), or the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\) (as in Case 2.4).

  • Case 4.1.1 In Game 6 of Case 4.1.1, we know that the predicate \(\textsf {clean} _{\texttt {asym-ri} }(u,i,[{\mathbf{asym\text {-}ri }\text {:}x-1} ])\) is upheld, which means that either:

    • the previous stage’s ratchet keys have not been compromised by the adversary (in which case analysis follows from Case 3.1)

    • the previous stage’s state has not been compromised by the adversary (in which case analysis follows from Case 3.2)

    In a similar way, then, we follow those cases to replace the appropriate uncompromised Diffie–Hellman key shares with challenge values from a PRFODH game. Thus, an adversary capable of distinguishing these changes would also be capable of breaking the PRF security of \({\mathrm {KDF}}_{m}\), or the \(\textsf {mm}\)-\(\textsf {sPRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\) (as in Case 1.1), or the \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\) (as in Cases 1.2 and 1.3), or finally the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\) (as in Cases 2.4 and 3.1).

  • Case 4.1.2 In Game 6 of Case 4.1.2, we know that the predicate \(\textsf {clean} _{\texttt {EE} }(u,i,x-1, x-1)\) is upheld, which means that the previous stages ratchet keys have not been compromised by the adversary and analysis follows from Case 3.1, with the same bounds and game hops. In particular, this means that the adversary’s advantage in breaking the key indistinguishability of the Tested session key is bound by the PRF security of \({\mathrm {KDF}}_{r}\) and \({\mathrm {KDF}}_{m}\), or the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\).

  • Case 4.2.1 In Game 6 of Case 4.1.1, we know that the predicate \(\textsf {clean} _{\texttt {asym-ri} }(u,i,[{\mathbf{asym\text {-}ir }\text {:}x-1} ])\) is upheld. Note that similarly to the proof of Case 4.2.1, this follows identically to Case 4.1.1 with an additionally application of a PRF game to account for the intermediate computation of a tmp value.

  • Case 4.2.2 In Game 6 of Case 4.2.2, we know that the predicate \(\textsf {clean} _{\texttt {EE} }(u,i,x-1, x-1)\) is upheld, which means that the previous stages ratchet keys have not been compromised by the adversary and analysis follows identically to Case 4.1.2, with an additional PRF game to account for the intermediate computation of a tmp value. In particular, this means that the adversary’s advantage in breaking the key indistinguishability of the Tested session key is bound by the PRF security of \({\mathrm {KDF}}_{r}\) and \({\mathrm {KDF}}_{m}\), or the \(\textsf {sn}\)-\(\textsf {PRF-ODH}\) security of \({\mathrm {HKDF}}, \mathbb {G}\).

  • Case 5 In this Case, and all subcases, analysis follows from Case 4, with additional PRF game hops to inductively replace chaining keys that via the cleanness predicate \(\textsf {clean} _{\texttt {sym} }\) have not been compromised by the adversary and thus follows from the security of the appropriate asymmetric stage.

From this vantage point, we can now compare the cases concretely. For instance, it is clear that the adversary’s advantage of breaking Case 1.1 (where the long-term identity key of the initiator and the medium-term signed prekey of the responder have not been compromised by the adversary) is quantitatively higher than the adversary’s advantage in breaking Case 2.4 (where the ephemeral key of the initiator and the one-time prekey of the responder have not been trivially compromised by the adversary). This is due to the fact that Case 1.1 (and identically, Case 2.1) requires the strong symmetric variant of PRFODH (i.e. \(\textsf {mm}\)-\(\textsf {PRF-ODH}\)), whereas Case 2.4 (and similarly, Case 3.1) requires the weak non-symmetric variant of PRFODH (i.e. \(\textsf {sn}\)-\(\textsf {PRF-ODH}\)). Cases 1.2, 1.3, 2.2, and 2.3 sit between these two, requiring multiple queries an \(\textsf {ODH}_u\) oracle, but no queries to the \(\textsf {ODH}_v\) oracle, as it simulates a long-term Diffie–Hellman key and a single-use ephemeral Diffie–Hellman key using a \(\textsf {mn}\)-\(\textsf {PRF-ODH}\) challenger.

In addition, this supplemental proof also allows us to consider any future work that examines the computational hardness of the generic and symmetric \(\textsf {PRF-ODH}\) assumptions in relation to the security of the Signal protocol.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Cohn-Gordon, K., Cremers, C., Dowling, B. et al. A Formal Security Analysis of the Signal Messaging Protocol. J Cryptol 33, 1914–1983 (2020). https://doi.org/10.1007/s00145-020-09360-1

Download citation

  • Received:

  • Revised:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00145-020-09360-1

Navigation