4

Among the requirements for a secure key exchange is the key confirmation. I wonder why is this step required. Even if the other party hasn't computed a correct value for the shared secret, it doesn't matter. It won't be able to decipher the information sent anyway. Why bother and make sure that the other party actually possesses the correct shared secret? It is said that this is a requirement for a secure key exchange. But why?

2 Answers 2

4

They certainly could decipher anything you send because you are talking about synchronous encryption, where the same key is used to encrypt and decrypt the traffic. In order for this to work both sides have to agree on a key for exchange. Shared secret verification is not actually a requirement for a secure key exchange from a theoretical standpoint, you could exchange keys securely with anyone really. However, if you do not verify the other side then you could be setting up a VPN with anyone, even those you do not want to, and send all sorts of confidential information. This is why sender verification is an integral part of all secure transfer technologies.

You may be getting confused by mixing up PKI and VPN technology, mistakenly thinking that when verification is taken care of by PKI that only the true recipient can decrypt the traffic. It's not that simple because PKI decryption (asynchronous as opposed to synchronous encryption) is extremely computation intensive, so secure transfers almost always use PKI for sender verification but then set up synchronous encryption for the transfers themselves.

EDIT: poster says the source is a lecture

If both sides do not share the same key neither side would be able to decrypt the other's traffic, so key confirmation is important from an operability perspective if not from a pure security perspective. Also, if you are using a VPN to check for authentication (see IPSEC AH) then you must verify keys, or you can't be sure what is authentic traffic. What the lecturer may mean is that it simply won't work without a key verification, rather than being a security process.

6
  • I guess my question wasn't understood. I am not confusing asynchronous and synchronous encryption. And I also understand the authentication problem. My question is about synchronous encryption. For instance, signed Diffie-Hellman key exchange with nonces and key confirmation. First, the parties exchange some public value, together with the nonces and the signatures. The signatures ensure that they parties are authentic. Nonces ensure freshness. Then, they compute the shared secret. However, to make this exchange really secure(according to some), you need to have key confirmation also. Why?
    – elena
    Nov 8, 2013 at 13:19
  • What is the source of the assertion regarding key confirmation @elena? If you have a link please edit your original post. It will be difficult to answer your question without more detail.
    – GdD
    Nov 8, 2013 at 13:38
  • Well, the source is the lecture material. Unfortunately, it is private. However, I think this requirement (of key confirmation) is a generally known security goal. I just don't seem to understand its purpose.
    – elena
    Nov 8, 2013 at 14:21
  • Well, if both sides do not share the same key neither side would be able to decrypt the other's traffic, so key confirmation is important from an operability perspective if not from a pure security perspective. It may be as simple as that. Also, if you are using a VPN to check for authentication (see IPSEC AH) then you must verify keys, or you can't be sure what is authentic traffic.
    – GdD
    Nov 8, 2013 at 14:38
  • 1
    Remember that security doesn't just mean confidentiality, but availability and integrity as well. While it might not be vital for confidentiality it is for availability and integrity checking, so from that standpoint it is an important security requirement.
    – GdD
    Nov 8, 2013 at 15:31
1

Why bother and make sure that the other party actually possesses the correct shared secret? It is said that this is a requirement for a secure key exchange. But why?

In addition to other reasons, a key confirmation is sometimes required during algorithm validation. For example, NIST's The Key Agreement Schemes Validation System (KASVS) requires them in some instances.

For completeness, here's NIST's definition from Section 4.1, page 7:

A procedure to provide assurance to one party (the key confirmation recipient) that another party (the key confirmation provider) actually possesses the correct secret keying material and/or shared secret.


Even if the other party hasn't computed a correct value for the shared secret, it doesn't matter. It won't be able to decipher the information sent anyway.

This may not necessarily be true. If a bad guy can somehow taint the exchange, he/she may be able to learn some things in the absence of a full-blown break by controlling parameters. In this case, the protocol execution would stop immediately at the key confirmation phase rather than giving the attacker more than one bite of the proverbial apple.

Protocols for Authentication and Key Establishment (pp. 162-63) actually details an attack on key exchange that's thwarted by key conformation, so its not theoretical.


I've never implemented a key confirmation protocol, but I expect them to be a two-way challenge/response protocol that does not use the keying material directly. It probably adds 2 to 4 additional messages to the protocol.

Its two way because both parties should prove knowledge of the key. It does not use the keying material directly to avoid disclosing information about the actual key to an adversary.

On a related note, you never use the shared secret/key material directly. You have to move it from the Diffie-Hellman domain into another domain where values are equally probably (i.e., uniformly distributed). IPSec uses HKDF for this step.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.