# How compute WPA key? [closed]

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.

Inputs

• 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! ## closed as too broad by Xcali, caird coinheringaahing, Toto, DJMcMayhem♦, Mego♦Oct 19 '17 at 16:37 Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question. • 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? – Okx Oct 19 '17 at 11:23
• Downvoted because output format is too strict. – Okx Oct 19 '17 at 11:29
• Can you add a walk-through of how stackexchange and <ra(<@2tAc<\$ become 24343f69e98d3c08236a6db407584227cf2d1222b050e48f0cf25dee6563cd55? – Adám Oct 19 '17 at 11:32
• @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... – Socratic Phoenix Oct 19 '17 at 12:16
• @ 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 – Felix Palmen Oct 20 '17 at 7:37

# C# (.NET Core) lambda expression, 8882 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!

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


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;}}

• @someone SecretKeyFactory#getInstance throws NoSuchAlgorithmException – Okx Oct 19 '17 at 11:48
• @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. – Okx Oct 19 '17 at 11:50