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.

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.

Answer 1

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.

Answer 2

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.