![]() | ![]() |
Key establishment, a fundamental building block in cryptography, is defined to be any process whereby a shared secret key becomes available to two or more parties, for subsequent cryptographic use (Menezes, van Oorschot, andVanstone, 1997). Such a scheme can be broadly classified into key agreement or key transport depending on the nature of the session key (i.e., whether input to the session key is required from only one party or all the participating parties) (Boyd and Mathuria, 2003; Menezes, van Oorschot, andVanstone, 1997). The basis of many key establishment protocols relies on the Diffie--Hellman key exchange (Diffie and Hellman,1976), the RSA algorithm (Rivest, Shamir, and Adleman,1978), and more recently elliptic curve pairings (identity-based). In fact, the first key establishment protocol with public key properties is published by Diffie and Hellman (1976). Although a latter protocol of Merkle (1978), Merkle's puzzles, also achieves the key distribution goal, the protocol of Diffie and Hellman (1976) enjoys a better ratio between security and efficiency (Wolf, 1999).
Despite cryptographic key establishment protocols being the sine qua non of many diverse secure electronic commerce applications, the design of secure protocols is still notoriously hard. The difficulties associated in obtaining a high level of assurance in the security of almost any new or even existing protocols are well illustrated with examples of errors found in many such protocols years after they were published (Abadi, 1997; Abdalla, Bresson, Chevassut, and Pointcheval, 2006); Bao, 2003; Bao, 2004; Basin, Mödersheim, and Viganò, 2003; Boyd and Choo, 2005; Burmester, 1993; Kaliski, 2001; Cheng and Comley, 2006; Choo, 2006; Choo, Boyd, and Hitchcock, 2005; Choo, Boyd, and Hitchcock, 2005c; Choo, Boyd, Hitchcock, and Maitland, 2004a; Choo and Hitchcock, 2005; Donovan, Norris, and Lowe, 1999; Lowe, 1996; Mitchell and Yeun, 1998; Myasnikov, Shpilrain, and Ushakov, 2005;Nam, Kim, and Won, 2004; Ku and Wang, 2000; Shoup, 2001; Wan and Wang, 2004; Wang, Wang, and Xu, 2004; Wing, 1998; Wong and Chan, 2001; Zhang, 2005).
The study of cryptographic protocols for key establishment and authentication have led to the dichotomization of cryptographic protocol analysis techniques between the computer security approach and the computational complexity approach, as shown in Fig 1.

Fig 1. Overview of cryptographic protocol analysis techniques
[The Computer Security Approach]
In the 1990s academic cryptography started its move toward
a mature discipline by demanding new standards of proof, with many researchers
shifting their attention to using formal methods, especially in the last decade.
Emphasis in the computer security approach is placed on automated
machine specification and analysis (e.g., model checking and theorem proving).
The Dolev and Yao (1983) adversarial model is the
de-facto model used in formal specifications, where cryptographic operations
are often used in a black box fashion ignoring the various cryptographic properties,
resulting in possible loss of partial information. One of the main obstacles
in this automated approach is the undecidability and intractability problems
since the adversary can have an exponentially large set of possible actions
(e.g., messages from adversary are unbounded in structural depth, number of
possible values for some data fields is infinite) which result in a state explosion
(Cervesato, Durgin, Lincoln,
Mitchell, & Scedrov, 1999). Furthermore, protocols proven secure in
such a manner could possibly be flawed (i.e., giving a false positive result
-- analogous to a Type II error in hypothesis testing). From a real world practicality
perspective, it is debatable whether proofs of security in this manner carry
significant weight in the real world, due to their idealistic model. However,
the computer security approach should be credited for proving insecurities in
protocols (i.e., finding both known and previously unknown flaws in protocols)
(Allamigeon and Blanchet, 2005; Basin, Mödersheim, and Viganò, 2003;Choo, 2006a;Choo,
Boyd, and Hitchcock, 2005; Clarke, Jha,
and Marrero, 2000; Steel and Bundy, 2005)
[The Computational Complexity Approach]
On the other hand, the computational complexity approach adopts a deductive reasoning process (i.e., the logical process of deriving a conclusion from a known premise) whereby the emphasis is placed on a proven reduction from the problem of breaking the protocol to another problem believed to be hard. The first treatment of computational complexity analysis for cryptography began in the 1980s (Goldwasser and Micali, 1984). It was made popular for key establishment protocols by Bellare & Rogaway (1993) whereby they formally defined a model of adversary capabilities with an associated definition of security and provided a proof of security for two-party entity authentication and key exchange protocols. Since then, there have been several extensions to the Bellare & Rogaway (1993) proof model, such as the Bellare & Rogaway (1995) key establishment model, the Bellare, Pointcheval, & Rogaway (2000) password-based mutual authentication and key establishment model, the Bresson, Chevassut, & Pointcheval (2001) group authenticated key establishment model, and the most recent Abdalla, Fouque, & Pointcheval (2005) password-based authenticated key establishment model. Independent yet related works based on Bellare, Canetti & Krawczyk (1998) by Canetti & Krawczyk (2001) and Shoup (1999) result in two new proof models, namely the Canetti-Krawczyk modular model (Canetti & Krawczyk, 2001) and the Shoup key exchange model (Shoup, 1999).
A complete (human-generated) mathematical proof with respect to cryptographic definitions provides a strong assurance that a protocol is behaving as desired. The history of mathematics is, however, full of erroneous proofs (Bundy, Jamnik, and Fugard, 2005). The difficulty of obtaining correct mathematical proofs has been illustrated in the virtuoso work of Lakatos (1976) whereby the many proofs and refutations for Euler's characteristic in algebraic topology are presented as a comedy of errors (many formulations for Euler's characteristic in algebraic topology, a theorem about the properties of polyhedra, have been tried, only to be refuted and replaced by another formulation).
The difficulty of obtaining correct computational proofs of security is also dramatically illustrated by the well-known problem with the OAEP mode for public key encryption (Shoup, 2001}. Although OAEP was one of the most widely used and implemented algorithms, it was several years after the publication of the original proof that a problem was found (and subsequently fixed in the case of RSA). Problems with proofs of protocol security have occurred too. Furthermore, such security proofs usually entail lengthy and complicated mathematical proofs, which are daunting to most readers (Koblitz and Menezes, 2004). The breaking of provably-secure protocols after they were published is evidence of the difficulty of obtaining correct computational proofs of protocol security. Despite these setbacks, we advocate that proofs are invaluable for arguing about security and certainly are one very important tool in getting protocols right (Choo, Boyd, and Hitchcock, 2005c).
[Motivations of Lounge]
Motivated by the absence of a compendium of provably-secure key establishment and/or mutual authentication protocols, this lounge aims to provide an updated brief summary of proposed key establishment and/or mutual authentication protocols proven secure in one of the earlier-mentioned models (Bellare & Rogaway, 1993; Bellare & Rogaway, 1995; Shoup, 1999; Bellare, Pointcheval, & Rogaway, 2000; Bresson, Chevassut, & Pointcheval, 2001; Canetti & Krawczyk, 2001; Abdalla, Fouque, & Pointcheval, 2005) and their properties. In doing so, we hope that this lounge will be useful for the wider research community.
| Protocols | Comments | |
| A1-A4. | Bellare and Rogaway (1993) MAP1, MAP2, AKEP1, and AKEP2 | |
| A5. | Blake-Wilson and Menezes (1997) Protocol 1 | |
| A6. | Blake-Wilson and Menezes (1997) Protocol 2 | |
| A7. | Blake-Wilson, Johnson, and Menezes (1997) Protocol 1 | |
| A8. | Blake-Wilson et al. (1997) Protocol 2 & Blake-Wilson and Menezes (1998) Protocol 8 (Unified Model with Key Confirmation) | These two protocols are the same. |
| A9. | Blake-Wilson et al. (1997) Protocol 3 & Blake-Wilson and Menezes (1998) Protocol 5 (Unified Model) | Reveal query is not allowed. These two protocols are the same. |
| A10. | Blake-Wilson et al. (1997) Protocol 4 | No proof is provided although Blake-Wilson et al. (1997) speculate that the protocol meets the full rigour required of a proof. In a later work, this protocol is proven secure by Kudla and Paterson (2005) with slight modifications. This same modified protocol is also proven secure in an independent work of Lauter and Mityagin (2006). |
| A11-A14. | Chen and Kudla (2003) Protocols 2, 2’, 3, and 4 | Reveal query is not allowed. Choo, Boyd, & Hitchcock (2005a) present an improved protocol 2 whereby Reveal query is allowed except to any sessions owned by the partner player associated with the Test session. However, if GAP assumption due to Okamoto and Pointcheval (2001) is employed, then the protocol can be proven secure without any Reveal query restriction. Note: The proposed key derivation function method used in the improved protocol 2 is recently included in the special publication by NIST (Special Publication: SP 800-56A -- Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography), March 2006. (Publication available for download from http://csrc.nist.gov/publications/nistpubs/index.html). |
| A15-A16. | MacKenzie and Swaminathan (1999) and MacKenzie, Patel, and Swaminathan (2000) SNAPI and SNAPI-X | |
| A17. | McCullagh and Barreto (2005) AK protocol | Reveal query is not allowed as shown by Choo (2005). Choo, Boyd, & Hitchcock (2005a) present an improved AK protocol whereby Reveal query is allowed except to any sessions associated with the owner of the Test session. However, if GAP assumption due to Okamoto and Pointcheval (2001) is employed, then the protocol can be proven secure without any Reveal query restriction. Flaws in existing proof are revealed by Choo, Boyd, & Hitchcock (2005a). The same flaws are also subsequently revealed in later independent yet related work of Cheng & Chen (2005). |
| A18. | Al-Riyami and Paterson (2002) TAK | Reveal query is not allowed. |
| A19-A20. | Wang (2005) IDAK and IDAK with Key Confirmation | |
| A21. | Wong and Chan (2001) MAKEP | The published version is broken but it can be fixed, as noted by Boyd and Mathuria (2003). The fixed version was broken and fixed by Choo, Boyd, and Hitchcock (2005c). |
| A22-A23. | Improved Choo, Boyd, & Hitchcock (2005a) (Chen and Kudla (2003)) Protocol 2 & (McCullagh and Barreto (2005)) AK protocol | Reveal query is allowed except to any sessions owned by the partner player associated with the Test session and the owner of the Test session respectively. However, this technicality can be resolved using GAP assumption due to Okamoto and Pointcheval (2001), which requires access to a non-existent Decisional Diffie--Hellman oracle. |
| A24. | Cheng, Chen, Comley, & Tang (2006) Protocol 1 | |
| A25. | Revised Key Agreement Protocol of Boyd (1996) Protocol | Proven Secure by Boyd, Choo, &
Mathuria (2006) In addition to the basic protocol, there is an extension which allows the session key to be renewed. However, there is a significant weakness in such an extension -- an adversary who obtains a long-term key of a user can continue to use it to masquerade as that user even after a new long-term key has been issued -- as acknowledged by Boyd (1996). |
| A26. | Key Agreement Protocol of Boyd, Choo, & Mathuria (2006) | Proven Secure in an extended Bellare--Rogaway model whereby they introduced an additional Reset query and a modified definition of freshness. Consequently, this protocol allows session keys to be renewed in subsequent sessions without the server’s further involvement even in the event that the long-term key or the earlier session key have been compromised. |
| Protocols | Comments | |
| B1. | Bellare and Rogaway (1995) 3PKD | The specific partner function defined in the proof of security for the 3PKD protocol is flawed but was fixed (refer to Choo, Boyd, Hitchcock, and Maitland (2004)). |
| B2-B5. | Shoup and Rubin (1996) SK1, SK2, SK3, SK4. |
| Protocols | Comments | |
| C1. | Abdalla, Chevassut and Pointcheval (2005) OPKeyX | Corrupt query is not allowed. |
| C2-C3. | Abdalla and Pointcheval (2005) SPAKE-1 and SPAKE-2 | Corrupt query is not allowed. |
| C4. | Bellare et al. (2000) AddMA | |
| C5. | Bellare and Rogaway (2000) AuthA | |
| C6. | Boyd and Gonzalez-Nieto (2003) Conference Key Agreement | Broken and fixed by Choo, Boyd, and Hitchcock (2005c). |
| C7. | Bresson, Chevassut, Essiari, and Pointcheval (2003) GKE | Corrupt query is not allowed. |
| C8. | Bresson, Chevassut, Pointcheval, and Quisquater (2001) AddPPsA(P) | Corrupt query is not allowed. |
| C9. | Bresson, Chevassut, and Pointcheval (2004) OMDHKE | Corrupt query is not allowed. |
| C10. | Catalano, Pointcheval, and Pornin (2004) IPAKE | Corrupt query is not allowed. |
| C11. | Chevassut, Fouque, Gaudry, and Pointcheval (2006) "Twist-AUgmented" Diffie--Hellman protocol | Although the Bellare & Rogaway (1993) and Bellare & Rogaway (1995) models were cited, the proof for the protocol uses the notion of session identifiers (in its partnership definition) and Execute queries, which only appear in the later Bellare, Pointcheval, & Rogaway (2000) model. |
| C12. | Choo, Boyd, Hitchcock, and Maitland (2004) Improved (Bellare & Rogaway, 1995) 3PKD | |
| C13 | Jiang and Gong (2004) Key Exchange Protocol | Corrupt query is not allowed. |
| C14-C16. | Jeong, Katz, and Lee (2004) TS1, TS2, and TS3 | Corrupt query is not allowed for TS1. Some important implementation details for TS2 are noted by Choo and Hitchcock (2005). |
| C17. | Katz, MacKenzie, Taban, and Gligor (2005) Two-Server Password-only Authenticated Key Exchange | |
| C18. | Katz, Ostrovsky, and Yung (2001) Password-AKE | Corrupt query is not allowed. |
| C19. | Katz, Ostrovsky, and Yung (2002) KOY | Corrupt query is not allowed. |
| C20. | Kobara and Imai (2002) Pretty-Simple PAKE | Corrupt query is not allowed. |
| C21 | Kwon (2004) TP-AMP | Corrupt query is not allowed. |
| C22-C23. | MacKenzie (2002) PPKE | Corrupt query is not allowed. |
| C24. | MacKenzie (2002) PAKE and PAKE-Z | Corrupt query is not allowed. As pointed out by Gentry, MacKenzie, & Ramzan (2005), PAKE is not resilient to server compromise when instantiated with some standard signature schemes. |
| C25. | Jakobsson and Pointcheval (2001) MAKEP | The unpublished pre-proceedings version was broken (refer to Wong and Chan (2001)) but the published version has been fixed. The (fixed) published version was broken and fixed by Choo, Boyd, and Hitchcock (2005c). |
| C26. | Zhang (2004a) QR-EKE | Corrupt query is not allowed. |
| C27-C28. | Zhang (2004b) PEKEP and CEKEP | Corrupt query is not allowed. |
| C29. | MacKenzie & Patel (2005) SEPPKE | Corrupt query is not allowed. The difference between SEPPKE and MacKenzie (2002) PPKE is in how x and y are chosen. |
| C30. | Shin, Kobara, & Imai (2005) RSA-AKE | Corrupt query is not allowed. |
| C31. | Abdalla & Pointcheval (2005a) 3PAKE | Corrupt query is not allowed. Due to the omission of the Corrupt query, an unknown key share (triangle) attack on 3PAKE cannot be detected as demonstrated by Choo, Boyd, and Hitchcock (2005c). |
| C32. | Gentry, MacKenzie, & Ramzan (2005) PAK-Z+ | Corrupt query is not allowed. PAK-Z+ is a revised version of the MacKenzie (2002) PAKE. |
| C33. | Gentry, MacKenzie, & Ramzan (2005a) Oblivious-Transfer PAKE | Corrupt query is not allowed. |
| C34. | Lee, Hitchcock, Park, & Moon (2005) One-Round Tripartite PPK Protocol | Corrupt query is not allowed. |
| Protocols | Comments | |
| D1. | Bresson, Chevassut, and Pointcheval (2001, 2002a) AKE1 | |
| D2. | Bresson, Chevassut, and Pointcheval (2002b) AKE1 | |
| D3. | Bresson, Chevassut, and Pointcheval (2003) OEKE | |
| D4. | Bresson, Chevassut, Essiari, and Pointcheval (2003) GKE | Nam, Kim, and Won (2004) found a flaw in the earlier conference version of this protocol. However, the flaw has been fixed in this journal version. |
| D5-D6. | Choi, Hwang, and Lee (2004) GKA and ID-based AGKA | They used the proof technique due to Katz and Yung (2003). GKA protocol is secure only against passive adversary. |
| D7. | Dutta, Barua, and Sarkar (2004) Tree-Based Group KA | They used the proof technique due to Katz and Yung (2003), and no Corrupt query is used in the proof of security. |
| D8. | Dutta, and Barua (2005) Tree-Based Dynamic Group KA | They used the proof technique due to Katz and Yung (2003), and no Corrupt query is used in the proof of security. A constant round variant of this protocol appear in another related work of Dutta and Barua (2005a). |
| D9. | Katz and Yung (2003) Constant-Round Group KE | Katz and Yung (2003) includes a compiler that transforms a secure group key exchange protocol to a secure group AKE protocol, in the proof approach. |
| D10. | Kim, Lee, and Lee (2004) Constant-Round AGKE | They used the proof technique due to Katz and Yung (2003), and no Corrupt query is used in the proof of security. |
| D11-D12. | Raimondo and Gennaro (2003) Dist-KOY1 and Dist-KOY2 | |
| D13. | Lee, Hwang, and Lee (2004) Password-Based Group Key Exchange Protocol | Abdalla, Bresson, Chevassut, and Pointcheval (2006) show that this protocol is insecure. |
| D14. | Choi, Hwang, Lee, and Seo (2005) ID-AKA Protocol | |
| D15. | Bresson, Chevassut, and Pointcheval (2005) GOKE | Corrupt query is not allowed. |
| D16. | Dutta, and Barua (2006) Password-Based Group KA | The protocol was proven secure in both the ideal cipher model and the random oracle model. However, Abdalla, Bresson, Chevassut, and Pointcheval (2006) show that this protocol is insecure. |
| D17-D18. | Viet, Yamamura, and Tanaka (2005) APAKE (Server Authentication) & APAKE (Mutual Authentication) |
|
| D19. | Abdalla, Bresson, Chevassut, and Pointcheval (2006) Password-based group key exchange protocol | The protocol was proven secure in both the ideal cipher model and the random oracle model. |
| D20. | Tang and Choo (2006) Password-based authenticated group key agreement protocol | Corrupt query is not allowed. |
| Protocols | Comments | |
| E1. | Abdalla, Fouque, & Pointcheval (2005) GPAKE | |
| E2. | Abdalla, Chevassut, Fouque, & Pointcheval (2005) GTPAKE |
| Protocols | Comments | |
| F1. | Aiello et al. (2002) IKE | |
| F2-F3. | Aiello et al. (2004) JFKi and JFKr | |
| F4-F5. | Boyd, Mao, and Paterson (2004) Protocols 1 and 2 | The corrected version is available from http://sky.fit.qut.edu.au/~boydc/papers/. |
| F6-F7. | Canetti and Krawczyk (2001) SIG-DH and REKEY | |
| F8. | Choo and Hitchcock (2005) 3PKD Protocol | This is the fixed version of Tin, Boyd, and Gonzalez-Nieto (2003) 3PKD Protocol. This (fixed) 3PKD protocol was used by Agre, Chen, Refaei, Sonalker, Zhu, & Yuan (2005) in phase 2 of the Key Exchange in Distributed Mode in their SnowMesh proposal (to the IEEE 802.11, The Working Group Setting the Standards for Wireless LANs). |
| F9. | Imamoto and Sakurai (2004) PAS Protocol | PAS protocol is similar to Blake-Wilson, Johnson, and Menezes (1997) Protocol 1, although this is not reflected in the Reference list. |
| F10. | Tin, Boyd, and Gonzalez-Nieto (2003) 3PKD Protocol | Broken but fixed by Choo and Hitchcock (2005). |
| F11-F12. | Tin, Vasanta, Boyd, and Gonzalez-Nieto (2004) 3PKDUM and 2DHTUM | |
| F13-F18. | Hitchcock, Boyd, and Gonzalez-Nieto (2004) Protocols 3, 4, 5, 6, 7, and 8 | |
| F19-F20. | Hitchcock, Tin, Boyd, Gonzalez-Nieto, and Montague (2003) ENCP and 2DHPE | A flaw in the proof of the encryption-based MT-authenticator due to Bellare, Canetti, and Krawczyk (1998) was revealed by Choo, Boyd, and Hitchcock (2005c). The same flaw in the encryption-based MT-authenticator was also revealed in a later independent yet related work of Tian and Wong (2006). Choo, Boyd, and Hitchcock (2005c) then show how the use of the flawed MT-authenticator in the proof of 2DHPE results in the violation of the key establishment goal in 2DHPE where a malicious adversary is able to learn a fresh session key. |
| F21. | Krawczyk (2005) HMQV Protocol | |
| F22. | Cliff, Tin, and Boyd (2006) Optimized authenticated server aided Diffie--Hellman protocol |
| Protocols | Comments | |
| G1-G3. | Boyko, MacKenzie, and Patel (2000) PAK, PAK-X, and PPKE | |
| G4-G8. | Shoup (1999) DHKE, EKE, A-DHKE, A-EKE-1, and A-EKE-2 | Proven secure under static corruption. |
| G9. | Shoup (1999) DHKE-1 | Proven secure under adaptive corruption (liberal compromise rule) and strong adaptive corruption (if, and only if, the internal data is appropriately erased). |
| G10. | Shoup (1999) DHKE-2 | Proven secure under adaptive corruption (liberal compromise rule). |
| G11. | Shoup (1999) DHKE-2 | Proven secure under adaptive corruption (liberal + conservative compromise rule). |
| G12. | Hwang, Yum, and Lee (2003) EPA | Broken but fixed by Wan and Wang (2004). |
| G13. | Zhang (2003) AP-AKA | Proven secure under adaptive corruption. |
| 2P / 3P | Two-Party / Three-Party |
| Conf | Conference / Multi-Party / Group |
| DH | Diffie-Hellman |
| DL | Discrete Logarithms |
| FS | Forward Secrecy |
| KA | Key Agreement |
| KC | Key Confirmation |
| KD | Key Distribution |
| KE | Key Exchange / Establishment |
| KT | Key Transport |
| MA | Mutual Authentication |
| ID / Pair | Identity-Based / Pairings-Based |
| Pwd | Password-Based |
| Ser | Server-Based |
Protocol
|
# Entity |
Security Goals |
-Based |
||||||||||||
2P |
3P |
Conf |
MA |
KA |
KE |
KD |
KT |
KC |
FS |
ID/Pair |
DH |
RSA |
Pwd |
Ser |
|
X |
X |
||||||||||||||
X |
X |
||||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
||||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
Protocol
|
# Entity |
Security Goals |
-Based |
||||||||||||
2P |
3P |
Conf |
MA |
KA |
KE |
KD |
KT |
KC |
FS |
ID/Pair |
DH |
RSA |
Pwd |
Ser |
|
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X | X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
X |
||||||||||||
Protocol
|
# Entity |
Security Goals |
-Based |
||||||||||||
2P |
3P |
Conf |
MA |
KA |
KE |
KD |
KT |
KC |
FS |
ID/Pair |
DH |
RSA |
Pwd |
Ser |
|
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
||||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
||||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
||||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
Protocol
|
# Entity |
Security Goals |
-Based |
||||||||||||
2P |
3P |
Conf |
MA |
KA |
KE |
KD |
KT |
KC |
FS |
ID/Pair |
DH |
RSA |
Pwd |
Ser |
|
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
||||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
Protocol
|
# Entity |
Security Goals |
-Based |
||||||||||||
2P |
3P |
Conf |
MA |
KA |
KE |
KD |
KT |
KC |
FS |
ID/Pair |
DH |
RSA |
Pwd |
Ser |
|
X |
X |
X |
|||||||||||||
X |
X |
X |
X |
X |
|||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
||||||||||||||
X |
X |
||||||||||||||
X |
X |
X |
|||||||||||||
X |
X |
X |
X |
||||||||||||
X |
X |
X |
X |
X |
|||||||||||