Editing Key-agreement protocol (section)

== Authentication ==
{{main|Authenticated key agreement}}
Anonymous key exchange, like Diffie–Hellman, does not provide [[authentication]] of the parties, and is thus vulnerable to [[man-in-the-middle attack]]s.

A wide variety of cryptographic authentication schemes and protocols have been developed to provide authenticated key agreement to prevent man-in-the-middle and related attacks. These methods generally mathematically bind the agreed key to other agreed-upon data, such as the following:
* public–private key pairs
* shared secret keys
* passwords

=== Public keys ===
A widely used mechanism for defeating such attacks is the use of [[digital signature|digitally signed]] keys that must be integrity-assured: if Bob's key is signed by a [[trusted third party]] vouching for his identity, Alice can have considerable confidence that a signed key she receives is not an attempt to intercept by Eve. When [[Alice and Bob]] have a public-key infrastructure, they may digitally sign an agreed Diffie–Hellman key, or exchanged Diffie–Hellman public keys. Such signed keys, sometimes signed by a [[certificate authority]], are one of the primary mechanisms used for secure [[web traffic]] (including [[HTTPS]], [[Secure Sockets Layer|SSL]] or [[Transport Layer Security|TLS]] protocols). Other specific examples are [[MQV]], [[YAK (cryptography)|YAK]] and the [[Internet Security Association and Key Management Protocol|ISAKMP]] component of the IPsec protocol suite for securing Internet Protocol communications. However, these systems require care in endorsing the match between identity information and public keys by certificate authorities in order to work properly.

=== Hybrid systems ===
Hybrid systems use public-key cryptography to exchange secret keys, which are then used in a symmetric-key cryptography systems. Most practical applications of cryptography use a combination of cryptographic functions to implement an overall system that provides all of the four desirable features of secure communications (confidentiality, integrity, authentication, and non-repudiation).

=== Passwords ===
[[Password-authenticated key agreement]] protocols require the separate establishment of a [[password]] (which may be smaller than a key) in a manner that is both private and integrity-assured. These are designed to resist man-in-the-middle and other active attacks on the password and the established keys. For example, DH-[[Encrypted key exchange|EKE]], [[SPEKE (cryptography)|SPEKE]], and [[Secure remote password protocol|SRP]] are password-authenticated variations of Diffie–Hellman.

=== Other tricks ===
If one has an integrity-assured way to verify a shared key over a public channel, one may engage in a [[Diffie–Hellman key exchange]] to derive a short-term shared key, and then subsequently authenticate that the keys match. One way is to use a voice-authenticated read-out of the key, as in [[PGPfone]]. Voice authentication, however, presumes that it is infeasible for a man-in-the-middle to spoof one participant's voice to the other in real-time, which may be an undesirable assumption. Such protocols may be designed to work with even a small public value, such as a password. Variations on this theme have been proposed for [[Bluetooth]] pairing protocols.

In an attempt to avoid using any additional out-of-band authentication factors, Davies and Price proposed the use of the [[interlock protocol]] of [[Ron Rivest]] and [[Adi Shamir]], which has been subject to both attack and subsequent refinement.