11
$\begingroup$

I want to know how EXACTLY the WPA password gets encrypted

I have been searching through and I was able to catch:

  1. The actual password is converted to some hash

  2. Salting is applied to the hash

  3. The operation is not reversible

  4. The hash comes with the 4-way handshake

So what kind of hash is it converted? like, SHA1? MD5? and how the salting process is done? like, is the SSID appended to the password before the hashing operation?

Or maybe I have some misunderstanding here?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
20
$\begingroup$

A key is derived from the password using a Password Based Key Derivation Function, in this case PBKDF2:

Key = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256)

PBKDF2 in turn is described by PKCS#5. These RSA cryptographic standards in turn are made available through RFC's nowadays, in this case RFC 2898: PKCS #5: Password-Based Cryptography Specification Version 2.0.

In this case the password needs to be 8 to 63 characters in size. The characters are converted to binary using ASCII so you can only use characters in the (printable) character range of ASCII.

In PBKDF2 the binary password is used as key to the HMAC function. The salt is the SSID of the Wi-Fi connection. The salt + a counter value is used as the initial input to the HMAC function. After that the previous HMAC output is used as input, until 4096 HMAC rounds is reached. Unfortunately it seems that it outputs 256 bits while SHA-1 only output 160 bits. This means that you have to increase the counter once and do all the rounds all over again.

The output of the PBKDF2 function is the pre-shared key or PSK. The PSK is used directly as PMK (pairwise master key) in the 4-way handshake.

This is also described in section H.4 : Suggested pass-phrase-to-PSK mapping of IEEE 802.11i (2004) which is available for download from the IEEE web site.

Improve this answer
$\endgroup$
8
  • 1
    $\begingroup$ Nice, full and comprehensive answer, but I don't seem to understand the 160/256-bit part, I mean I don't understand the point of the problem nor understand what counter are we talking about, thank you very much. $\endgroup$
    – OverCoder
    Sep 5, 2015 at 20:05
  • $\begingroup$ Also, what is the string to binary through ASCII part? I mean the passphrase is already ASCII, I was hanging on an implemention of that using js, what I noticed that it used variable called bPassword (maybe binary?) that contains the password after it has been processed by a function that is described 'Converts raw string to big-endian', is that what are you talking about? $\endgroup$
    – OverCoder
    Sep 5, 2015 at 20:11
  • 1
    $\begingroup$ PBKDF2 uses HMAC internally, which outputs the same size as the underlying hash function. PBKDF2 in this case requires more output (the 256 bits in the last argument to the function) that means that all the iterations of the PBKDF2 function have to be repeated, basically giving you a work factor of 8192 iterations instead of 4096. $\endgroup$
    – Maarten Bodewes ♦
    Sep 5, 2015 at 20:12
  • 2
    $\begingroup$ @MaartenBodewes can you clarify how the user input is converted to ASCII? Are non-printable ASCII characters discarded or mapped, for example? $\endgroup$
    – deed02392
    Dec 9, 2015 at 10:51
  • 1
    $\begingroup$ @deed02392 "There is no canonical binary representation of a character and ambiguity exists when the password is a character string. To eliminate this ambiguity, a compliant STA shall represent a character-based password as an ASCII string." So it seems that non-printable characters can simply not be entered. How to deal with them is therefore probably out of spec, i.e. implementation specific, if they are dealt with at all. $\endgroup$
    – Maarten Bodewes ♦
    Dec 10, 2015 at 19:16

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