WPA2, the actual encryption standard that secures all modern wifi networks, has been cracked... This challenge has nothing to do with the way that the WPA2 was cracked, however is is about computing the 64-digit hexadecimal key that corresponds to a given WPA-PSK pass-phrase.

A wireless network with WPA-PSK encryption requires a pass-phrase to be entered to get access to the network. Most wireless drivers accept the pass-phrase as a string of at most 63 characters, and internally convert the pass-phrase to a 256-bit key. However, some systems also allow the key to be entered directly in the form of 64 hexadecimal digits. So the challenge is to calculate the 64-digit hexadecimal key that corresponds to a given pass-phrase.

The hexadecimal key is computed from the pass-phrase and the network SSID (an SSID is a unique ID that consists of 32 characters).

Details of the calculation

For WPA-PSK encryption, the binary key is derived from the pass-phrase according to the following formula: Key = PBKDF2(pass-phrase, SSID, 4096, 256)

The function PBKDF2 is a standardized method to derive a key from a pass-phrase. It is specified in RFC2898 with a clear explanation on how to compute it. The function needs an underlying pseudo-random function. In the case of WPA, the underlying function is HMAC-SHA1.

SHA1 is a function that computes a 160-bit hash from an arbitrary amount of input data. It is clearly explained in RFC3174. HMAC is a standardized method to turn a cryptographic hash function into a keyed message authentication function. It is specified in RFC2104.

To summarize, the key derivation process involves iterating a HMAC-SHA1 function 4096 times, and then doing that again to produce more key bits.


  • SSID a string of at most 32 characters (e.g. stackexchange)
  • pass-phrase a string of at most 63 characters (e.g. <ra(<@2tAc<$)

Output any reasonable output of the 64 hexadecimal digits

  • e.g. 24343f69e98d3c08236a6db407584227cf2d1222b050e48f0cf25dee6563cd55
  • it is the result of the previous inputs

This is , so please make your program as short as possible!

  • 1
    \$\begingroup\$ Just to double check, is 24343f69e98d3c08236a6db407584227cf2d1222b050e48f0cf25dee6563cd55 the output of the inputs stackexchange and <ra(<@2tAc<$? And are we allowed to output bytes instead of hexadecimal digits? \$\endgroup\$
    – Okx
    Oct 19 '17 at 11:23
  • 1
    \$\begingroup\$ Downvoted because output format is too strict. \$\endgroup\$
    – Okx
    Oct 19 '17 at 11:29
  • 1
    \$\begingroup\$ Can you add a walk-through of how stackexchange and <ra(<@2tAc<$ become 24343f69e98d3c08236a6db407584227cf2d1222b050e48f0cf25dee6563cd55? \$\endgroup\$
    – Adám
    Oct 19 '17 at 11:32
  • 6
    \$\begingroup\$ @J.Salle many golfing langs can't access the internet or read JSON easily, and yet we post stack-exchange-api challenges, besides, I think implementing the algorithm is part of the fun, and having a challenge which golfing langs may not win is always refreshing... \$\endgroup\$ Oct 19 '17 at 12:16
  • 4
    \$\begingroup\$ @ close voters -- so, what makes this challenge "too broad"? Is it too broad for requiring "too much work" in languages that don't have PBKDF-2 in their standard libraries? I'd personally like to see a submission in such a language (or, maybe, provide one myself) :o \$\endgroup\$ Oct 20 '17 at 7:37

C# (.NET Core) lambda expression, 88 82 81 bytes

Takes input as byte arrays (curried, see comments), returns key as byte array.

p=>s=>new System.Security.Cryptography.Rfc2898DeriveBytes(p,s,4096).GetBytes(32);

Try it online!

  • \$\begingroup\$ @someone as I/O is relaxed, I have a complete new version operating on byte arrays ... updating. \$\endgroup\$ Oct 19 '17 at 11:57
  • 2
    \$\begingroup\$ You could just do System.Security.Cryptography.Rfc2898DeriveBytes and save on the using-statement. \$\endgroup\$
    – Emigna
    Oct 19 '17 at 12:03
  • \$\begingroup\$ 82 bytes. \$\endgroup\$
    – Ian H.
    Oct 19 '17 at 12:18
  • \$\begingroup\$ @Emigna thanks, that was kind of silly ;) \$\endgroup\$ Oct 19 '17 at 13:12
  • \$\begingroup\$ Use currying to save one more byte (Func<byte[],Func<byte[],byte[]>> f = p=>s=>...; call as f(p)(s)). \$\endgroup\$ Oct 20 '17 at 13:20

Java, 192 88 + 36 = 124 bytes

36 bytes for import de.rtner.security.auth.spi.*;

a is the SSID taken as a byte array, b is the password taken as a string. Outputs byte array. Requires PBKDF2.

a->b->new PBKDF2Engine(new PBKDF2Parameters("HmacSHA1","UTF-8",a,4096)).deriveKey(b,32);

Old answer:

Takes SSID as char array and password as byte array. Outputs byte array.

a->b->{try{return javax.crypto.SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1").generateSecret(new javax.crypto.spec.PBEKeySpec(a,b,4096,256)).getEncoded();}catch(Exception e){return null;}}

Try it online!

  • \$\begingroup\$ Why do you need to catch the exception? \$\endgroup\$ Oct 19 '17 at 11:46
  • \$\begingroup\$ @someone SecretKeyFactory#getInstance throws NoSuchAlgorithmException \$\endgroup\$
    – Okx
    Oct 19 '17 at 11:48
  • \$\begingroup\$ Does java require a try-catch for everything that throws exceptions? \$\endgroup\$ Oct 19 '17 at 11:50
  • \$\begingroup\$ @someone Yes, If it's declared in the method. Not always though, for example you can get a NullPointerException if you do something like String s = null; s.isEmpty(); (which will throw a NPE) which doesn't need to be caught (but still can be), as in the String#isEmpty method declaration, it doesn't say it throws NullPointerException. \$\endgroup\$
    – Okx
    Oct 19 '17 at 11:50

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