From what I've read, the issue is as simple as performing step 3 of a 4-step handshake and the consequences of performing that step more than once. Considering the complexity of these kinds of algorithms, I'm somewhat surprised that it is so 'simple' of a concept.

How can it be that a system of this complexity was designed without anyone thinking about what would happen if you performed the step twice? In some sense, it feels like this should have been obvious. It's not really a subtle trick, it's a relatively blatantly obvious defect, or at least that's the impression I'm getting.

  • 131
    It may have been discovered sooner ... just not publicly disclosed. Oct 17, 2017 at 1:57
  • 3
    @Wildcard: the difference in interpreting this question is between asking why it was not discovered during the initial (closed) design process (which is the interpretation Polynomial seems to answer) vs. why it was not discovered while several open implementations existed or were developed (which is what I read into the question). Oct 17, 2017 at 2:54
  • 37
    Hindsight always seems obvious...
    – Andy
    Oct 17, 2017 at 13:14
  • 17
    "How can this be?" and "How could this happen?" type questions are usually asked not as a way to request actual information, but as a way to cast aspersions on those who failed to anticipate the problem.
    – barbecue
    Oct 17, 2017 at 16:23
  • 5
    @sahuagin it might be better to word such questions as "what" rather than "how". "What kinds of procedures were in place, and could they have detected this flaw?" or "What kinds of software testing methodologies could have detected this flaw earlier in the process."
    – barbecue
    Oct 17, 2017 at 18:55

3 Answers 3


The 802.11 specification that describes WPA2 (802.11i) is behind a paywall, and was designed by a few key individuals at the IEEE. The standard was reviewed by engineers, not by cryptographers. The details of the functionality (e.g. retransmission) were not widely known about or studied by security professionals.

Cryptographer Matthew D Green wrote a blog post about this subject, and I think this section sums it up quite nicely:

One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they’re hard for ordinary security researchers to access. Go ahead and google for the IETF TLS or IPSec specifications — you’ll find detailed protocol documentation at the top of your Google results. Now go try to Google for the 802.11i standards. I wish you luck.

The IEEE has been making a few small steps to ease this problem, but they’re hyper-timid incrementalist bullshit. There’s an IEEE program called GET that allows researchers to access certain standards (including 802.11) for free, but only after they’ve been public for six months — coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Oct 17, 2017 at 14:27
  • +1 although this does then raise the question of why a security protocol was so widely adopted despite lack of heavy scrutiny, something that isn't the case for example with encryption or hashing algorithms. Oct 19, 2017 at 11:25
  • 6
    While the specification may have been written by engineers, it was ultimately implemented by software developers. Security-related features (like secure handshakes) should have been built to safely deal with replay attacks even though the spec said nothing about it. The fact that "KRACK" is so easy to mitigate by all vendors without an official change to the specification shows just how easily this could have been handled way back in 2004 when WPA2 -- a standard established in particular to fix the dismal security in WEP/WPA(1) -- was published. Oct 19, 2017 at 16:35

In some sense, it feels like this should have been obvious.

Remember Heartbleed, Shellshock, POODLE, TLS Triple Handshake attack, "goto fail", ... ?

In hindsight, most of these problems seem to be obvious and could have been prevented if the right people just had a closer look at the right time at the right place. But, there is only a limited amount of people with the right technical expertise and these usually have lots of other things to do too. Please don't expect them to be perfect.

Instead of having illusions about standards being perfectly designed, software being bug free and systems being 100% secure one should accept that this is impossible to achieve in practice for today's complex systems. To mitigate this one should care more about resilience and robustness, i.e. staying safe and secure even if some parts break by layering security, not fully trusting anything and having plans if something breaks.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Oct 17, 2017 at 14:27
  • 1
    Also the fact that anyone questioning the security of said protocol's handshake would be told it's mathematically proven to be secure - in security we often shoot for the low hanging fruit -- normally no one will go after something already 'proven' to be mathematically secure. (I believe this is also why the heartbleed exploit wasn't discovered sooner too). Oct 17, 2017 at 15:07
  • 18
    To pervert Linus's Law somewhat: "In hindsight, all bugs are shallow."
    – Polynomial
    Oct 17, 2017 at 16:23
  • 3
    Those issues are mostly different in that they are implementation bugs (mostly because C is dangerous or because OpenSSL is a massive mess of code). Whereas KRACK is a bug in the spec that no one who reviewed it or implemented it noticed
    – mcfedr
    Oct 18, 2017 at 8:03
  • 2
    @djsmiley2k for Heartbleed, it seems like a packet with two distinct length fields and "what if these weren't equal" is low-hanging fruit.
    – Random832
    Oct 18, 2017 at 19:00

The paper describing KRACK discusses this very issue in section 6.6.

A couple of points: There were ambiguities in the specification. Also formal proofs of specification are based on a model of the specification, and there are times when that model does not match the actual specification, much less matching the implementations based on that specification.

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