0
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 code-golf, so please make your program as short as possible!
1Just to double check, is
24343f69e98d3c08236a6db407584227cf2d1222b050e48f0cf25dee6563cd55
the output of the inputsstackexchange
and<ra(<@2tAc<$
? And are we allowed to output bytes instead of hexadecimal digits? – Okx – 2017-10-19T11:23:45.410@Okx Yes it is a complete example – mdahmoune – 2017-10-19T11:25:28.707
1Downvoted because output format is too strict. – Okx – 2017-10-19T11:29:49.243
1Can you add a walk-through of how
stackexchange
and<ra(<@2tAc<$
become24343f69e98d3c08236a6db407584227cf2d1222b050e48f0cf25dee6563cd55
? – Adám – 2017-10-19T11:32:23.173@Okx is it okay for you for a less restricted output? – mdahmoune – 2017-10-19T11:34:58.257
@mdahmoune Output formats on challenges should generally be flexible, because adding bytes just to conform to the output format is annyoing – Okx – 2017-10-19T11:36:08.280
@Okx I edited the challenge – mdahmoune – 2017-10-19T11:36:50.053
1I like the challenge (from an infosec enthusiast's perspective) but I think it's too restrictive language-wise. Most golflangs just don't have a built-in SHA algorithm, so you'd have to implement that, to be able to create the HMAC function, and only then you'd be able to make a function to solve the challenge, which is both very convoluted and kinda misses the point of codegolfing. – J. Sallé – 2017-10-19T12:00:42.183
@J.Salle how can make the challenge more accessible for other languages? – mdahmoune – 2017-10-19T12:03:26.133
6@J.Salle many golfing langs can't access the internet or read JSON easily, and yet we post [tag: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 – 2017-10-19T12:16:30.493
1I think it's a good challenge, so I'm not downvoting this challenge, but I'm not upvoting it, either. Ideally, challenges should be self-contained with no external links required. While it's very unlikely that the IETF will go away anytime soon, and I don't expect the entire algorithms to be spelled out here, some of the explanation from the RFCs could be migrated over to here to make the challenge even better. – AdmBorkBork – 2017-10-19T12:32:46.697
@AdmBorkBork please feel free to edit the challenge... – mdahmoune – 2017-10-19T12:43:56.573
4@ 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 – 2017-10-20T07:37:10.327