1
$\begingroup$

I'm currently reading Cryptography Engineering and in Chapter 7, the topic of secure channel is discussed.

The channel described is using CTR for encryption. Below I include images with pseudo-code used in the book (source):

Secure Channel: Initialization Function Secure Channel: Sending A Message Function Secure Channel: Receiving A Message Function

In Secure Channel: Initialization, 4 different keys are generated (assuming no collisions).

In Secure Channel: Sending a Message the key stream is generated using KeySendEnc as the key to the encryption function (let's say we're using AES here). Then, what we do is XOR the message we want to encrypt (plaintext || authenicated plaintext) with the key stream generated in the previous step. To authenticate the plain text, KeySendAux is used. Up to this point, everything makes sense.

Now, in Secure Channel: Receiving A Message, KeyRecEnc is used as the key to generate the key stream k. Then, the encrypted message is XORed with this k to obtain the original message (plaintext || authenicated plaintext). If KeyRecEnc ≠ KeySendEnc, then the key stream k, generated in the two cases is different. My question is exactly here, how do we obtain the original message if we XOR the ciphertext with some other key stream, different from the one that we used to encrypt the message in Secure Channel: Sending a Message.

Then, KeyRecAuth (KeyRecAuth ≠ KeySendAuth) is used to obtain a MAC. This MAC is then compared with the received MAC (after it's decrypted). How can those two MACs can ever be the same (ignoring collisions), since the input to the HMAC-h function is different in both cases (because KeyRecAuth ≠ KeySendAuth).

Thanks in advance.

Improve this question
$\endgroup$
0

2 Answers 2

Reset to default
0
$\begingroup$

You are looking at the code for one of the parties, Alice or Bob. So the variables for both parties are named the same, but they contain distinct values. You would have a $KeySendAuth_{Alice}$ and a $KeySendAuth_{Bob}$, calculated to different values during the initialization phase. The initialization is started after Alice and Bob have agreed upon $k$.

The idea in this is that both sides create the same keys. However Bob would of course not use "Auth Bob to Alice" as string for the key derivation of $KeyRecAuth_{Bob}$. Instead Bob would use "Auth Alice to Bob", which is identical to to the input of $KeySendAuth_{Alice}$. So $KeySendAuth_{Alice}$ would match $KeyRecAuth_{Bob}$.

The same goes for the encryption keys and therefore the state. The state also has a send counter which is communicated by the ciphertext, which may of course differ for the two parties. The only variable that should be identical at both sides is the secret key $k$, which is only used at the Initialization phase.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Here is the pseudocode used in the initialization function in the book. The idea in this is that both sides create these keys From what I understood, only one party initializes the secure channel, since the message counter is set to zero when the initialization function is called and the returned object s is passed into send and receive functions. $\endgroup$
    – Illya Gerasymchuk
    May 29, 2015 at 23:06
  • $\begingroup$ Note the SWAP for the keys of Bob in the pseudo-code. So this does precisely show why this works. $\endgroup$
    – Maarten Bodewes ♦
    May 30, 2015 at 0:32
  • $\begingroup$ But doesn't only one party initialize the channel (the one that starts the communication)? Wouldn't that make KeySendEnc and KeyRecEnc to be always the same? Or does Alice and Bob initialize the channel at the same time? Are there two copies of s? Like this: s1 := init(1234, "Alice") on Alice's side and s2 := init(1234, "Bob") on Bob's side (I'm assuming the pseudocode from the book and K = 1234). The Alice uses s1 to send messages and Bob s2 to receive them. But wouldn't message counting be broken if this approach is used? $\endgroup$
    – Illya Gerasymchuk
    May 30, 2015 at 9:02
  • $\begingroup$ There would indeed to be two different message states S. They each have their internal state. If Alice has send more messages to Bob then the MesgCountEnc etc. should be higher for Alice than for Bob. The best way to see that this doesn't break the protocol would be to play it out. I do think that there are better explanations and protocols than this. $\endgroup$
    – Maarten Bodewes ♦
    May 30, 2015 at 10:42
  • $\begingroup$ Yes, they would initialize the channel at the same time, after they have agreed upon $k$. $\endgroup$
    – Maarten Bodewes ♦
    May 30, 2015 at 11:46
0
$\begingroup$

how do we obtain the original message if we XOR the ciphertext with some other key stream, different from the one that we used to encrypt the message in Secure Channel: Sending a Message?

Answer: we don't use different keystreams. When Alice sends Bob a message, she uses the 'Enc Alice to Bob' keystream, When Bob receives that message, he uses that same 'Enc Alice to Bob' keystream. The 'Enc Bob to Alice' keystream is used for messages that Bob send to Alice (both by Bob to encrypt those messages, and by Alice to decrypt those messages).

The MACs work the same way; the 'auth Alice to Bob' MAC keys are used by both sides to do integrity checking on the messages that Alice sends to Bob, and the 'auth Bob to Alice' MAC keys are used by both sides for messages that Bob sends to Alice.

Improve this answer
$\endgroup$
4
  • $\begingroup$ But how can the keys used in encryption and decrytpion be the same (in the pseudocode in the images) if KeySendEnc != KeyRecEnc, KeySendEnc is used in the "send message" function and KeyRecEnc is used in the "receive message" function? $\endgroup$
    – Illya Gerasymchuk
    May 29, 2015 at 23:05
  • $\begingroup$ Because what one side uses for KeySendEnc (to encrypt what it sends), the other side uses for KeyRecEnc (to decrypt what it receives) $\endgroup$
    – poncho
    May 29, 2015 at 23:07
  • $\begingroup$ That would make total sense, but where does it say that (in the pseudocode)? From what I interpreted is that different keys are used to encrypt and decrypt the message. $\endgroup$
    – Illya Gerasymchuk
    May 29, 2015 at 23:14
  • 1
    $\begingroup$ You're looking at the code from Alice's point of view. Instead of the string 'Alice to Bob', think of it as a format string "Enc %s to %s" where you pass your identity first, then the other party's identity for the KeySendEnc, similar for the other 3 keys. Alice's then looks like "Enc Alice to Bob" and Bob's looks like "Enc Bob to Alice" for sending and vice versa for receiving. Thus, they match. $\endgroup$
    – Steve Peltz
    May 30, 2015 at 2:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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