Using IV buffer after altered inside a Rijndael CBC Encryption/Decryption process as IV for next message?

Question

When sending a block to be decrypted or encrypted, with RijndaelCBC, we input the data to decrypt/encrypt and an IV for syncing and to prevent identical outputs for identical inputs.

This question is regarding to any loopback mode use of AES chipher block using an IV, but my experience is with CBC.

Inside the RijndaelCBC "machine", (model), the input IV is processed and changed through a number of XORS with an end result (logically) different from the input IV.

CBC Mode Encryption CBC Mode Decryption

Because of the symmetric nature of RijndaelCBC the encryption process and decryption process will both change the input IV to a different valued buffer then the original but an identical result for both processes.

My questions are:

Does this "Output IV" holds information that can have private key or plain data value inferred from?
Is using the IV in such a way, which can keep both sides of a Rijndael secured communication link sync data (IV) up to date without the need of sending the IV over communication (Although it is not secret), is a known and used approach?

Example for the second question:

Variables: PrivateKey, StartIV
Box A and Box B are connected on a Rijndael secured link.
User Ainputs and receives data from Box A, while User B inputs and receives data from Box B.

User A → Plain Data → Box A →   
Enc(Plain Data,PrivateKey,StartIV) →   
OutputIV, EncedData → SecuredLink

User A sends plain data to box A, it is then encrypted using a starting IV and private key, saving the output IV from the encryption operation, while sending the encrypted data to Box B through the secured link.

SecuredLink → EncedData → Box B → 
Dec(EncedData, PrivateKey, StartIV) → 
OutputIV, Plain Data → B User

Encrypted data received from the secured link in Box B which then decrypts the encrypted data, using the private key and start IV, to plain data; saves the output IV and sends the plain data to the user.

User B → Plain Data → Box B →   
Enc(Plain Data, PrivateKey, OutputIV) →  
NextOutputIV, EncedData → SecuredLink

User B sends plain data to box B, it is then encrypted using the OutputIV, (Generated output from decrypting the message arrived from Box A), and private key, saving the output IV from the encryption operation as the next output IV, while sending the encrypted data to Box A through the secured link.

SecuredLink → EncedData → Box A →   
Dec(EncedData, PrivateKey, OutputIV) →   
NextOutputIV, Plain Data → User A

Encrypted data received from the secured link in Box A which then decrypts the encrypted data, using the private key and the OutputIV, (Generated output from encrypting the message that was sent to Box B), to plain data; saves the output IV as the next output IV, and sends the plain data to the user.

Now i might be very naive but i don't understand why not to use this approach and save the syncing operation over communication.

I meant using rijndael in CBC mode, sorry i will fix it in the question. — TomF, Aug 29 '13 at 11:34

score 2 · Accepted Answer · answered Aug 29 '13 at 12:51

I assume you mean that the CBC-mode encryption and decryption process would 'update' the "output IV" will be identical to the most recent ciphertext block. This isn't obvious from your question; for example, the diagrams you show don't show any "output IV" being generated at all.

Now, for your specific questions:

Does this "Output IV" holds information that can have private key or plain data value inferred from?

Well, obviously not; this "output IV" is just a part of the ciphertext that (we assume) that the attacker sees already.

Is using the IV in such a way, which can keep both sides of a Rijndael secured communication link sync data (IV) up to date without the need of sending the IV over communication (Although it is not secret), is a known and used approach?

Well, techinically yes, this approach is known and in use; for example, TLS 1.0 uses it (except they maintain separate IVs and keys in the different directions; one reason for that is so that if the two sides send messages at the same time, both encryptors don't try to update their internal states to reflect the most recent message they've seen (which would differ) at the same time - you may want to consider that).

However, there's an issue that you don't ask (but should have)

Is there any known weaknesses that can occur because of this?

The answer to this is "Yes; if an attacker can convince one of the two sides to send a message of his choosing, he can use that ability to test the decryption of another message block". With TLS, this is known as the BEAST attack; it would be considered wise to design your encryption system to avoid it.

In addition, I have some questions for you:

What sort of integrity protection are you designing in your protocol? That is, if the attacker can modify an encrypted message, what advantage can he gain? What provisions do you have in your protocol that would limit it?
More fundamentally, why are you designing your own encryption protocol? Encryption protocols have subtle problems (for example, this BEAST attack, which is not at all obvious); is there a specific reason you have decided not to use a known good design which avoids the obvious problems?
How does the two sides get their shared secret key? Now, this may appear to be off-topic for 'how to encrypt', however it's fraught with even more landmines than designing your own encryption protocol.

Ye i tried my best to include all info but, you know first post and all. I am asking out of curiosity, and now that you answered that it is used, is there a name to the actual process? (not the protocol using it). And i neglected to point that it is a PtP connection. And for the "OutputIV" content, doesn't it have the private key "folded" inside it's value? — TomF, Aug 29 '13 at 13:05
@TomF: as for terminology, well, I haven't anything specific; I called it "reusing the last ciphertext block as the next IV". As for whether the "OutputIV" is computed using the secret key, well, it is; on the other hand, so is the ciphertext, and we don't mind publishing that. In fast, the "OutputIV" is extracted from the Ciphertext in a known way; hence if the value of OutputIV gives the attacker any information, well, he already has it. — poncho, Aug 29 '13 at 14:17

score 2 · Answer 2 · edited Apr 13 '17 at 12:48

Your assumption is flawed, you are thinking the IV used for encryption and decryption are different, and that the decrypt IV is an output from the cipher. It is only an input, and it is the same for both operations. Therefore it does not leak any information about the key or the plaintext.

Is using the IV in such a way, which can keep both sides of a Rijndael secured communication link sync data (IV) up to date without the need of sending the IV over communication (Although it is not secret), is a known and used approach?

This can be done in several ways, and is a used approach, I use it myself in my own protocols. One way is to prepend the IV to the plaintext prior to encryption, and use no explicit IV for CBC (or an all 0 bit IV) Using CBC with a fixed IV and a random first plaintext block

Another way is to use dual counters on each end, and increment them. You would start with an IV that would be communicated during key establishment, then each side would use an incrementing counter for their messages, which would be added to half of the original IV. Each side would need to know which half is being modified, so there would be no overlap. This would give 2^64 unique messages per key per party (in 2 party communication). The counter would then be sent with the ciphertext.

I never said that they were different for Enc and Dec, read again. And no i did not mean a fixed IV, if you would read my question you will see that when you introduce the IV buffer to the CBC model it is overwritten with every iteration, and after the iterations (10 per block right?) it becomes a different buffer then the original IV. Is it more clear? — TomF, Aug 31 '13 at 08:31
Also sending the counter, valid approach still is passed over the network, does not serve my means — TomF, Aug 31 '13 at 09:11
You may want to rephrase the question better, even the title is not grammatically correct. There is not an IV 'buffer', CBC simply xors the last ciphertext with the plaintext prior to encrypting the block. Also there is only 1 iteration per block, not 10. If you are asking if it is ok to use the last ciphertext block as the next IV, it can be done, but I would not recommend it. My post will have a guaranteed 0 IV overlap, reuse will not. — Richie Frame, Sep 03 '13 at 07:06

Using IV buffer after altered inside a Rijndael CBC Encryption/Decryption process as IV for next message?

2 Answers2