116 reputation
4
bio website
location Toronto, Canada
age
visits member for 1 year, 2 months
seen Aug 20 at 20:12

I fell into the C++-potion as a child.


Sep
24
awarded  Autobiographer
Aug
2
awarded  Scholar
Aug
2
accepted Security of CFB on a public channel
Jul
30
comment Security of CFB on a public channel
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.
Jul
30
comment Security of CFB on a public channel
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.
Jul
30
comment Security of CFB on a public channel
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.
Jul
30
comment Security of CFB on a public channel
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.
Jul
30
awarded  Supporter
Jul
30
awarded  Student
Jul
30
comment Security of CFB on a public channel
@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.
Jul
30
comment Security of CFB on a public channel
@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.
Jul
30
asked Security of CFB on a public channel