6

I'm a little bit confused regarding the keystream. When installing the same session key again the nonce will be reset and start again.

  • Session Key + Nonce = Keystream?

  • The Keystream is now the part which is used to encrypt the plain text?

How is it possible to decrypt anything? Do I need a piece of plain text and an encrypted message from what I suggest this plain text is in there to then derive the keystream?

Does every single packet get a new Keystream for encryption or does the keystream renew after a complete new 4-way handshake?

2

Session Key + Nonce = Keystream?

Yes, the keystream is a function of the key and the nonce, in the mathematical sense (same key + nonce combination yields same keystream):

keystream = F(key, nonce)

...where F is the stream cipher's keystream generation function (often just called the stream cipher). Think of F as the black box where all the cryptographic dark magic happens—each time you feed it a secret key and public nonce, it will produce very long output that looks random in practice to somebody who doesn't know the key, but which another party that knows the same secret key can recreate simply by using the same key + nonce combination.

The Keystream is now the part which is used to encrypt the plain text?

Yes, by XORing them together:

ciphertext = plaintext XOR keystream

Or, expanding the definition of keystream:

ciphertext = plaintext XOR F(key, nonce)

How is it possible to decrypt anything? Do I need a piece of plain text and an encrypted message from what I suggest this plain text is in there to then derive the keystream?

Since 0 XOR x = x and x XOR x = 0 for all x, the previous equation implies this one:

plaintext = ciphertext XOR F(key, nonce)

So to decrypt the ciphertext, the recipient just needs to have the same key and nonce that were used to encrypt it. Think of F, again, as a compact black box that reproduces the same keystream given the same key and nonce that were used to encrypt.

Does every single packet get a new Keystream for encryption or does the keystream renew after a complete new 4-way handshake?

Each packet in the same session is encrypted with the same key, but with a different nonce; this means that in correct operation, a new keystream is used for each packet. An incrementing packet counter is used for the nonces. The attack consists in tricking implementations to reset the packet counter to its initial value without resetting the key. This causes the victim to encrypt multiple messages with the same key and nonce, and thus with the same keystream.

0

Look at this wikipedia page. Since we're using a derivative of the depicted CTR mode, a reset of the counter is fatal. Each transmitted data packet is encrypted with the same part of the "keystream".

So, neither is the AES key recovered through a known plaintext attack, nor can we derive the complete key stream right away.

But forcing the encryption of a lot of different packets with potentially the same (first) part of the key stream (counter reset to zero!), we have a known plaintext attack against the the first parts of the key stream and can presumably over time recover all bits from it:

  1. decode from the assumption it's a TCP packet a few bits in front of the 0th part of the key stream (constant parts of TCP header).
  2. next packet you're lucky: you decrypt the packet again with the already known bits of the key stream and discover the start of the text of the declaration of independence in latin encoding. This would result in a large portion of the key stream to be known.

Just the principle - still not trivial, but enough to count as "broken", I guess.

Also see this question.

  • Hm OK, Thanks for explanation. You are right it seem not to be so trival.... Althought the guy who discovered the KRACK method said: "In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream" Maybe we have different views of what is trival ;) – Rene Oct 18 '17 at 17:29
0

In addition to what user1931751 has already answered, I would want to add the following regarding your second question.

Does every single packet get a new Keystream for encryption or does the keystream renew after a complete new 4-way handshake?

The 4-way handshake derives a new session key which leads to a new keystream that wouldn't match with the previous one as a new key is used for encryption (input to AES cipher). In the KRACK attacks against the 4-way handshake the same session key is installed twice, though. So there you will have the same keystream. But you asked for a "complete 4-way handshake" which is not what the attack provokes, so I will try to shortly explained after a complete handshake finished.

If one session key is installed, a nonce (combined with some fixed stuff) initialized with one will be used as the IV (initialization vector) for encrypting the first packet. This packet (MPDU) of the 802.11 standard consists of multiple blocks and the CCM Mode (RFC 3610) is used to cope with this. So for the 802.11 standard the nonce is a counter that is incremented by one for each packet. This packet consisting of a few AES blocks will use this counter as an initialization vector for its own "intern" counter mode as specified in RFC 3610. So each block and each packet should encrypt under the next part of the current keystream determined by the current session key and the 802.11 initialization vector(the one consisting of the nonce, MAC address etc.).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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