1

If someone is coding a secure connection library, I'd have expected this to stick out like a red flag to them.

Why on earth would someone code logic like this (anyone working on it must have understood the basics enough to notice it was strange) without even querying it?

Stilez
  • 1,664
  • 8
  • 13
  • It isn't . that one focuses on the standard setters. But I'm wonderingly how the FOSS coders who wrote the client software library could miss that the logic they themselves were coding, was weird , as they wrote it. – Stilez Oct 17 '17 at 08:31
  • The question I've linked to asked why nobody saw this "obvious" (according to the question) issue before. You question basically asks the same, also claiming that it should have been obvious for anybody implementing the protocol. *"It isn't . that one focuses on the standard setters"* - there are multiple answers to the question, only one focuses on the standard process. – Steffen Ullrich Oct 17 '17 at 08:41
  • 1
    Maybe someone did, but didn't figure out the attack. Maybe nobody did, because the attack is kinda obscure. Nevertheless, this question doesn't really have a good answer, unless someone from the dev team shows up and tells you. – Tom K. Oct 17 '17 at 12:14
  • The assumption here is that its obvious, possible to trigger the situation as exploited in KRACK. Since it involves 2 subsystems that each have many tests and are inspected throughly, the integration test for using both 1 after the other is never written or conceived. This type of oversight can happen easily with highly specialized parts that are made by different engineers. KRACK requires a predictable start position, something that the protocol does not implicitly allow (only due to a interpretation error it is possible). – LvB Oct 17 '17 at 12:33

0 Answers0