Encrypted Communication - Avoid resending messages of third party

Question

I want two parties to be able to send encrypted messages to each other. How can i make sure that a man-in-the-middle is not able to just resend encrypted messages? Of course the man-in-the-middle would not know what he send, but the receiver would have no clue that it was not just send again by the person before.

Are there algorithmns techniques to avoid just that?

I hope you get my problem.

Greetings

score 1 · Answer 1 · answered Jan 20 '14 at 16:27

The standard solution is to number every message on a given channel sequentially. If a message arrives with a sequence number less than the previous message, then reject that message.

You will need a separate system to resolve any issues, "Did you just resend a message from yesterday?"

score 0 · Answer 2 · answered Jan 20 '14 at 16:12

0

You can encrypt the message before sending the message but the receiving end should know the key to decrypt it. If you are using .NET framework, Microsoft provides Encryption library with number of functions to choose from.
You can try using SSL

answered Jan 20 '14 at 16:12

johnpili

688
6
9

score 0 · Answer 3 · answered Jan 20 '14 at 18:03

0

If there's a single request-response communication, then the client can include a nonce in request, and the nonce will be sent back in the response. The nonce is used eg. in TSP protocol.

If there's a unidirectional flow of data, then sequential numbering of packets will work.

If there are commands being sent from the client to the server, then some kind of nonce can work as well. The nonce is created by the server, passed to the client and then included by the client into the command sent to the server. The welcome message of the server should include the initial nonce, and the nonce for the next command must be included in the response to the previous command.

answered Jan 20 '14 at 18:03

Eugene Mayevski 'Callback

45,135
8
71
121

Message flows can always be made unidirectional. Use one count for Alice to Bob and a separate count for Bob to Alice. Also good to use a flag to indicate message direction: "AB" or "BA" so the attacker does not send a message back to the originator. – rossum Jan 20 '14 at 18:35
@rossum in protocols like TSP and OCSP they can't. Random nonce is used there. – Eugene Mayevski 'Callback Jan 20 '14 at 19:23
Then add in your own message header at the start of your plaintext: "AB0123 Hello Bob..." This will be separate from the system-generated random nonce. – rossum Jan 20 '14 at 19:28
@Rossum that just doesn't make sense for certain protocols. Not all message flows consist of several packets which can or should be numbered. – Eugene Mayevski 'Callback Jan 20 '14 at 19:30
It would be a strange message flow if the sender was unable to specify the contents of the message she is sending. At some point in the process, the contents of the message will be generated as plaintext before encryption. Specific headers can be added at that point, preferably automatically -- humans forget sometimes. – rossum Jan 20 '14 at 20:02

score 0 · Answer 4 · answered Feb 08 '14 at 13:13

As you have tagged this post with the pgp tag, why don't you try to achieve this with the help of the OpenPGP cryptography.

The client can encrypt the data with the public key of the server and sign it with its own private key. Only the server will be able to decrypt it and it will also verify (with the public key of the client) that it originated from the client.

Encrypted Communication - Avoid resending messages of third party

4 Answers4