# Security of CFB on a public channel

Given a server that broadcasts all received data to all connected peers (except the sender), two participants can have an encrypted conversation using a self-synchronizing method like CFB and some error detection.

How secure is this given that anyone can not only listen but also paste in chosen text into the stream? Is it enough to prepend random padding to make it secure? Anything else that could be done?

-
Can you explain the system in a little more detail? The broadcast server doesn't do any encrypting/decrypting right? Only the 2 parties. Are the other parties allowed to learn incorrect decryptions, etc? –  mikeazo Jul 30 '13 at 15:04
@mikeazo Yes, the server does nothing more than 1) receive data and 2) send it to everyone. There can be multiple conversations possibly using different protocols on that server. A listener can not know if the decryption succeeded at the client or even how many clients there are and who the originator of any piece of data is. However for the sake of security we could assume that the attacker could manage to catch a clean conversation between two participants on a otherwise idle server. –  Fozi Jul 30 '13 at 16:29
What is the attackers goal? Inject some specially crafted text so that the receiver decrypts it and somehow that leaks private information (either the plaintext of some part of their encrypted conversation, the key, etc)? Or are they trying to cause a denial of service (causing no ciphertext to decrypt properly)? –  mikeazo Jul 30 '13 at 17:26
@mikeazo The scenario I'm thinking of is that the attacker could bring the victims decryptor/encryptor in a 'known' state by sending some data and reduce the strength of the CFB to a ECB, but I'm curious about other possibilities as well. In general the attacker's goal is to acquire the plain text. Replay attacks are irrelevant since the clients response is not necessarily predictable, unless they help the attacker in his goal. Also, the clients have to be able to deal with a lot of 'noise' in the channel and can move their conversation to another server, so DoS is not a problem. –  Fozi Jul 30 '13 at 17:34

There are two possible ways (I can think of) an attacker could mess you up here, but they both stem from very poor design. So I don't know how realistic they are.

Note: the following figure assumes a 64-bit blocksize

1. CFB is only self synchronizing against insertions/deletions of a specific length. The length is determined by the shift register. If the attacker can insert symbols that don't follow this length, then they can throw everything off in effect causing a DoS. Thus, when designing the system, you have to take into account the # of symbols that can be accidentially or maliciously inserted (deleted). If an attacker can inject down to a single symbol, then you'll have to set $k=1$ in the figure.

2. Another possible attack came to light in your comment about forcing CFB to behave like ECB. This can happen if you use the same instance of the block cipher to encrypt and decrypt. This is not how I would design the system. I'd use two separate instances of the block cipher, one for encrypting my messages to you and one for decrypting your messages to me. Furthermore, I would use different keys for each direction. If you do it this way, what the attacker injects will only mess up your decryption instance (which thanks to the self-synchronizing nature of the mode, is a problem from which you can recover).

-
Thanks for your answer, it basically confirms some of the concerns I'm having. As for 1) yes, the attacker, and everyone else on this server, can insert as many bytes as they want in the stream. That's why I was thinking of prepending a random block of data the length of the shift register before each message. Also, the message content is checked (CRC or HASH) so garbage will be ignored. –  Fozi Jul 30 '13 at 18:18
As for 2) my initial version worked as you suggested, however I'd like to have more then two clients be able to participate in the conversation. Basically anyone who knows the shared secret should be able to listen in and participate. This means I have to link the encryptor/decryptor together and solve the known state problem in a different way. –  Fozi Jul 30 '13 at 18:22
Since CFB is self-synchronizing, anyone with the key can decrypt any message (but they will miss the first X bits in order to synchronize. X is the block length in bits) –  mikeazo Jul 30 '13 at 18:25
So if I insert random data in front of the message I don't need to link the encryptor & decryptor - but if I don't link the encryptor & decryptor then I don't need to insert random data... :/ I was hoping I could come up with something that has very little to no overhead. Looking at this and owlstead's point 3 it might make sense to do some random padding though. –  Fozi Jul 30 '13 at 18:33

You asked if there is anything else that can be done, so I'll add some things that mikeazo did not mention.

• You should make very sure that the IV you are using is a nonce. In other words, you should never ever repeat an IV value using the same key.

• You should check your known value (prepended padding) before using any part of the decrypted ciphertext. It's probably better to use a MAC instead.

• You should be aware the the length of CFB encrypted ciphertext can leak information about the plain text. This is more pronounced than in CBC mode where padding may hide some specific sizes.

-
Your point 3 is actually a good one I have not thought of. As of point 2 since the client has to deal with a lot of noise there is filtering at a higher level that ignores all garbage. I'm not sure your first point is a concern since my main problem is that an attacker can force me into a known state at any time, so if I find a solution for that (e.g. prepend random data) I believe I don't have to worry about the IV. –  Fozi Jul 30 '13 at 18:26
You may run into issues regarding the answer you gave about points 1 and 2. It's probably best to try and update your question with additional information about your protocol and describe the protocol the best as you can. –  Maarten Bodewes Jul 30 '13 at 18:37