[Cryptography] [FORGED] Re: Severe flaw in WPA2 protocol leaves Wi-Fi traffic open to eavesdropping

Peter Gutmann pgut001 at cs.auckland.ac.nz
Thu Oct 19 06:24:47 EDT 2017

Natanael <natanael.l at gmail.com> writes:

>The main difference between the two is that RC4 can be cracked even without
>nonce repetition occurring, as in the now infamous WEP standard.

Sure, but that's not what happened here.  GCM failed catastrophically because
it was a stream cipher, just like RC4.  It doesn't matter if you use the
strongest algorithm in the world, combined with GCM it's going to break in
this case.

What KRACK shows is that, through the careful selection of cipher modes, you
can turn a very robust algorithm (AES) into a very brittle one (GCM).  In fact
if you'd used the canonical worst-case never-use-this AES mode, ECB (+ HMAC to
account for the "G" part in GCM), KRACK would have been a mostly academic
information-leakage attack rather than a complete cryptosystem failure like it
is.  Even a tiny step up, to 1970s-vintage CBC, would have made it even less
of an issue, a very minor information leak but no more.

Another interesting aspect of this, which Matt Green has gone into in more


is that this was a failure of a proven-secure handshake using an encryption
mode with multiple proofs, and yet in combination they failed
catastrophically.  Drew Gross once observed that:

  I love crypto, it tells me what part of the system not to bother attacking

but I have a different take on that:

  I love crypto, it's a pointer to where all the mistakes are being made

It makes an auditor's job so much easier.  When I'm asked to look at a
security product or device, I look for the crypto, and then look at how it's
being used, because that's where I'll find the holes.  For a stream cipher,
I'd first look for places where there's key/nonce reuse, and then if I don't
find any (I often do, thus the "RC4 all over again", because I saw the same
stuff with RC4 in the 1990s, long before anyone knew of weaknesses in RC4
itself) I look for ways to force key/nonce reuse.  Job done, and it doesn't
matter what the actual algorithm was they were using.

Speaking of provable security, I would love to get a statement from both NIST
and the CC evaluators as to how a device with multiple FIPS and CC evaluations
stretching over many years could have a broken RSA key generator, the very
thing that the evaluation is meant to check.  You can't even get a FIPS level
1 without having the RSA keygen validated, so how did this happen?  Will
Infineon's products now be decertified like OpenSSL was?  Will there be an
investigation as to how a broken product passed its FIPS and CC
certifications, to make sure this doesn't happen for other products?  In fact
given that the certification doesn't seem to be able to catch this, how will
we have any confidence in the keygen of other evaluated products?


More information about the cryptography mailing list