从我所读的内容来看，问题很简单，就像执行4步握手的第3步一样，重复执行该步骤的后果也很简单。考虑到这类算法的复杂性，令我感到惊讶的是，它是如此“简单”。如果执行两次该步骤会发生什么？从某种意义上说，这应该是显而易见的。这并不是一个微妙的技巧，它是一个相对明显的缺陷，或者至少是我得到的印象。
#1 楼
描述WPA2（802.11i）的802.11规范背后是付费专栏，由IEEE的一些关键人员设计。该标准是由工程师而不是密码学家审查的。该功能的详细信息（例如重传）尚未为安全专业人员广泛了解或研究。 >IEEE的问题之一是标准非常复杂，并且是通过不公开会议的闭门程序制定的。更重要的是，即使是事实，普通安全研究人员也很难访问它们。继续搜索Google IETF TLS或IPSec规范-您会在Google搜索结果的顶部找到详细的协议文档。现在，尝试使用Google以获得802.11i标准。祝您好运。
IEEE一直在采取一些小步骤来缓解此问题，但这些都是怯tim的增量主义废话。有一个名为GET的IEEE程序，使研究人员可以免费访问某些标准（包括802.11），但前提是这些标准已经公开六个月了-巧合的是，供应商不可撤销地将其烘烤到硬件中，软件。
评论
评论不作进一步讨论；此对话已移至聊天。
–Rory Alsop♦
17-10-17在14:27
+1尽管确实会引发一个问题，即尽管缺乏严格的审查，为什么仍广泛采用了安全协议，例如在加密或哈希算法中却并非如此。
–乔恩·本特利
17-10-19在11:25
虽然该规范可能是由工程师编写的，但最终还是由软件开发人员实施的。与安全相关的功能（例如安全握手）应已构建为可以安全地处理重放攻击，即使规范对此没有说明。所有供应商都可以轻松地缓解“ KRACK”这一事实，而无需对该规范进行正式更改，这说明了早在2004年WPA2（一种专门解决WEP严重安全问题的标准）就可以轻松解决这一问题/ WPA（1）-已发布。
–克里斯托弗·舒尔茨（Christopher Schultz）
17-10-19在16:35
#2 楼
从某种意义上来说，这应该是显而易见的。
记住Heartbleed，Shellshock，POODLE，TLS三重握手攻击，“ goto失败”，...？很明显，如果正确的人在正确的时间在正确的地方仔细观察，就可以避免。但是，只有少数人拥有正确的技术专长，而这些人通常还有很多其他事情要做。请不要指望它们是完美的。
除了对标准的完美设计抱有幻想之外，软件没有错误，系统具有100％的安全性，人们应该接受这一点，对于当今的复杂系统而言，这是不可能实现的。为了减轻这种负担，应该更多地关注弹性和健壮性，即即使通过分层安全性来破坏某些部分也要保持安全，不要完全信任任何事物并在发生某些问题时制定计划。
评论
评论不作进一步讨论；此对话已移至聊天。
–Rory Alsop♦
17-10-17在14:27
还有一个事实是，有人质疑该协议握手的安全性，就会被告知它在数学上被证明是安全的-在安全性方面，我们经常为低挂果而努力-通常没有人会去追求已经``证明''在数学上是安全的东西。 （我相信这也是为什么也没有早就发现令人流血的漏洞的原因）。
–djsmiley2kStaysInside
17-10-17在15:07
为了使莱纳斯定律有些曲解：“事后看来，所有错误都是浅表。”
–多项式
17-10-17在16:23
这些问题的不同之处在于它们是实现错误（主要是因为C很危险，或者因为OpenSSL是大量的代码混乱）。 KRACK是规范中的错误，没有人审查或实施它
–mcfedr
17-10-18在8:03
@ djsmiley2k代表Heartbleed，它看起来像一个带有两个不同长度字段的数据包，“如果它们不相等该怎么办”实在是低落的果实。
–Random832
17-10-18在19:00
#3 楼
描述KRACK的论文在6.6节中讨论了这个问题。有两点：规范中存在歧义。规范的正式证明也基于规范的模型，并且有时该模型与实际规范不匹配，更不用说与基于该规范的实现相匹配了。
评论
它可能早发现了...只是没有公开披露。@Wildcard：解释此问题的区别在于询问为什么在初始（封闭）设计过程中未发现它（这是多项式似乎在解释的解释）与为什么在存在或开发了几个开放实现时未发现它（这是我读到的问题中的内容。）
后视似乎总是很明显...
“怎么会这样？”和“这怎么可能发生？”通常不问类型问题，这不是要求提供实际信息的方法，而是对未能预料到问题的人发扬光大的方法。
@sahuagin最好用“什么”而不是“如何”这样的措词。 “已经实施了哪些程序，他们是否可以检测到此缺陷？”或“在此过程的早期阶段，有哪些软件测试方法可以检测到此漏洞。”