On 9/21/14, nymble <nymble@gmail.com> wrote:
... TKIP is NOT the same as RC4 … while we are trying to remove it from any usage in Wi-FI, it has yet to be fully broken (publicly).
agreed.
Please elaborate. TKIP has not been identified as a ‘active attack’ vector.
if TKIP is optional in WPA2, and yet must be implemented in WPA2 [0] and, attacker is able to inject EAPOL in one or both directions, some of the time then, attacker can force TKIP in a "WPA2 protected session" visibly identical to the user as desired AES-CCMP WPA2 mode. " [1] and attacker can force WPA2-TKIP regardless of the WPA disable, and TKIP disable options set in client or access point, which all appear to set advertised preferences, not absolute capabilities, at the radio level. consider the following states, which may be influenced by injecting attacker: access point WPA2-TKIP disable + client WPA2-TKIP requested access point WPA2-TKIP requested + client WPA2-TKIP disable access point WPA2-TKIP disable + client WPA2-TKIP disable (able to silent transition? bug on top of bug) [2] if any of these end up in WPA2 TKIP for a given hardware pair, it is a problem. we have problems. best regards, to be specific about the problems, in case not concise enough above: 0. lack of a way to enforce TKIP disable. 1. lack of visual signal of TKIP downgraded security in WPA2 to users. 2. insult to injury with "unspecified" bozofail TKIP transition to ON flaws in some hw.