Using IV buffer after altered inside a Rijndael CBC Encryption/Decryption process as IV for next message? 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.
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.