During the WPA/WPA2 handshake, the client and AP compute a 256-bit Pre-shared Master Key (PMK) before exchanging Nonces that are used to compute the eventual key. Given that the hosts already have a shared key (the PMK); why dont they use it to encrypt the Nonces? The attacker exploits these nonces to do a dictionary attack -- it seems like the attack would be much more difficult if the nonces were encrypted.
Unfortunately, that wouldn't really achieve much. To see why, let's first recall the steps of the common dictionary attack on WPA/WPA2-PSK.
In WPA/WPA2-PSK, the key hierarchy goes like this:
password - this is the fundamental secret in the entire protocol, and all other keys are ultimately derived from this. Thus, the security of the protocol essentially boils down to the secrecy of this value.
PMK = PSK = PBKDF2(password, SSID, SSID-length, 4096, 256).
PTK = PRF(PMK, "pairwise key expansion", MAC1 || MAC2 || Nonce1 || Nonce2). The exact PRF that is used here is not important, but it is based on HMAC-SHA1.
Notice that as an attacker, if you know the password, then you have all the information you need to first derive the PMK (since everything else that goes into the PBKDF2 function is public), and then the PTK (since the MACs and the nonces are public). This, then, leads to the well-known dictionary attack: make a guess on the password, derive from this guess the PMK and PTK, then use the PTK on some of the captured data to verify your guess (e.g. by recomputing one of the message-authentication codes of the 4WHS). If the verification didn't check out, try another guess on the password.
Now, with your suggestion, the nonces wouldn't immediately be observable in the clear. However, this would only change the above attack slightly: again the attacker makes a guess on the password and derives the PMK as before. However, now it cannot immediately continue to derive the PTK, since it doesn't have the nonces. But this is not a problem, because the encryption of the nonces only depends on the PMK, which it now has a guess for. Thus, using this guessed PMK, it simply decrypts the encrypted nonces, and continues the attack as before, deriving the PTK and verifying the guess on the captured data. If the guess of the password was correct, then the attacker will obtain all the correct data and the final verification will check out. While if the guess was wrong, the final verification will most certainly fail.
Thus, the attack is more or less the same, just with one added step requiring the decryption of the nonces. Moreover, the only computationally intensive calculation being done here is the evaluation of the PBKDF2 function. The time needed for the extra decryption of the nonces dwarfs in comparison to this.