# WPA transient key calculation clarification

Hello experts,

I understand that for WPA:

## 1.

The AP sends a nonce value to the client

## 2.

The client sends its own nonce value to the AP and computes the transient key using the two nonces ,as well as the MAC address of itself and the AP, and hashes the nonce as well to send

## 3.

The AP now also constructs a transient key based on the same values from step 2....  (rest of the exchange omitted)

Now, what I don't understand is:  in steps 2 and 3 the transient key that is calculated is supposed to be the output of a random (okay, pseudorandom) function.  If this is the case doesn't this mean that even though the input is the same, the two keys will be different because they're run on each side and not shared?   I'm surely missing some detail here.
###### Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Commented:
There's a bit you missed, but this link explains better than me...

http://wi-fu.co.uk/wi-fi/wpa-attacks/94-attacking-wpa-psk-part-1

Look right at the bottom for the bits that go together to derive the PTK.
Author Commented:
Okay, but let me clarify:
PTK = PBKDF2(PSK, ANonce, SNonce, AMAC, SMAC)

I see that PBKDF2 takes as one of its input parameters a pseudorandom function (http://en.wikipedia.org/wiki/PBKDF2  ).  Now, what is this PRF value in this case?  The nonces?  They're sent plaintext so that's my confusion...  I guess they're pretty random but they are known.
Commented:
Before that there's the PMK - the master key.  In 802.1x this is dynamic per client.  In PSK this is obviously known to all clients as it 'is' the PSK.

The PMK is used to authenticate to the AP, before encryption occurs.  The PMK is derived from the PSK and the SSID so the only thing ever transmitted up to this point is already known.  After the client authenticates the 4-way handshake kicks-off and the PTK is derived.  This is unique per client always.

The AP generates the Anonce value using the PMK and its MAC address.  The client generates the Snonce value in the same way.  Both of these values are derived without the values being transmitted as they are known to each client already.  When the EAPOL message comes from the AP it sends its Anonce value.  The client uses this to derive the PTK using its Snonce value and sends that back to the AP, along with the MIC.  This protects the packet from being spoofed.

I see where you're going with this though.  What makes it secure?  The answer is - nothing.  It's not.  Anyone can learn the AP's or client's MAC address.  Anyone can sniff for packets containing the Anonce and Snonce value and EAPOL packets.   You can also learn the MIC easily.  Put all that together and all you need is a dictionary to launch an attack to learn the PSK.

The only thing that makes this less easy to crack is the 256-bit key that is hashed.  If you supply a weak passphrase to generate the PSK you're open to a dictionary attack.  Use a complex passphrase longer than a few characters and you're far less likely for the passphrase to be reverse-engineered.

The objective is to keep the passphrase secret.  Let that out and obviously anyone can connect to the AP.

Experts Exchange Solution brought to you by