# Re-sending captured encrypted data

Let’s assume Bob is some algorithmic stock trading machine. Bob takes commands from Alice, who sends messages to Bob.

For example: Alice could be sending a message to Bob to stop trading. But if Mallory is able to capture cipher and figure out the effect of sending that cipher to Bob, Mallory could send the captured cipher to Bob and make him stop trading at arbitrary times.

How do cryptographic systems handle such situations?

One way I could think of is to append the current epoch time to message before encrypting it. Then Bob can choose to discard the message if the time shown in the decrypted cypher is far off in the past. But this is not foolproof. What actually is done in real life?

• They can also use strictly increasing counters. $\;$
– user991
Commented Oct 23, 2015 at 5:29
• @RickyDemer …as long as such counter(s) are handled as a common secret between Alice and Bob, and Mallory has no way to learn about them by chance or by attack. (Not saying I disagree, I do agree – just wanted to close that little gap.) Commented Oct 23, 2015 at 5:36
• @e-sushi : $\:$ If the encryption is not AE, then there are bigger problems than replays. $\hspace{1.37 in}$ If the encryption is AE, then does secrecy of the counter matter? $\;\;\;\;$
– user991
Commented Oct 23, 2015 at 5:45
• @RickyDemer Fair point and as I said: I do agree with you. I just didn’t want to let the word “counters” simply hang there (as someone new to it all might misinterpret things). But your second comment does a good job hinting at the fact that adding a counter isn’t all it’ld take. Thanks for adding that.$\color{green}{^{+1}}$ Commented Oct 23, 2015 at 6:08

How do cryptographic systems handle such situations? … What actually is done in real life?

In real life, cryptography handles situations like the one you describe by using “authentication”. Authentication links an action, a message or a situation to an identity. In the example you describe, this will practically boil down to a validation of something an entity knows… like a password, a key, or another kind of secret.

Simplified, you could think of authentication as something which enables you to validate if an entity is actually who they claim to be, or allowed to do something, by showing they know a secret that only they could know. (Note that “authentication” does not always mean an entity proves its individual identity; it can also be used to prove an entity is part of a group of entities knowing a certain secret.)

For better understanding of what “authentication” is, it may be helpful to know there are also other forms (better: factors) of “authentication”. Chances are, you’ve already have met such “authentication” in real life yourself, since “authentication” can be proven by something an entity has – like a passport, a smartcard, a token device, or something similar.

Besides that, “authentication” can be proven by an entity by something an entity is. For example: humans have specific, individual features. These can also be used for “authentication”… which makes up one of the areas biometrics covers. If you‘ve ever had your fingerprint or iris scanned, or if you ever saw that in a movie… well, that’s what we call “authentication” in the realms of cryptography.

As said, in your example Bob and Alice will use a shared secret to enable mutual authentication. Not knowing the secret, Mallory will not be able to successfully authenticate her messages as Bob will detect the missing or wrong authentication factor (the secret) and reject and/or ignore Mallory’s messages/attacks accordingly.

Of course, authentication alone won’t make a protocol secure. Besides authentication things like secure connections (using encryption, etc.) are needed to wrap a secure shield around things. But authentication is an important part of cryptography, as it allows (for example) to learn if the entity you are communicating with is indeed the entity you expect to be communicating with… and not some kind of adversary who tries to inject or even replace messages which you might think are secure. They may be secure due to encryption, but without authentication that’s not worth all too much. Yet, the combination of both make up a pretty solid way of exchanging information between two entities.

• I know a bit of encryption theory. You could be more technical in the explanation. By authentication do you mean alice decrypting the hash of a message, which is half part decided by alice and half part decided by bob? So you mean we always have to do authentication before sending messages.
– user28093
Commented Oct 23, 2015 at 4:57
• @salsabear Actually, Bob and Alice should always do authentication when sending messages (as each individual message needs to be authenticated). Simplified example: Bob and Alice share a common secret. When exchanging data, first the data and then the secret is hashed, based on the data’s hash as in SHA256(msg|secret). Now, Bob and Alice can authenticate exchanged data as they can hash the data (just like Mallory could) and they hash the common secret as a final step – which is where Mallory fails to authenticate (read: make Bob believe she is Alice) as she doesn’t know the secret. Commented Oct 23, 2015 at 5:11
• @salsabear As said: that’s a (very) simplified example. In practice, you could use an authenticated cipher algorithm, or – as it’s usually done – use an according protocol for data exchange (which then includes authentication as part of the protocol). I guess an example of a somewhat alike protocol would be SSL (assuming we ignore the fact that SSL tends to require trusting a 3rd party – the certificate authority – which then acts as an mediator, confirming the identity and/or certificate of an entity/website). Diving into other Q&As tagged authentication may provide additional insights. Commented Oct 23, 2015 at 5:18

You are describing a replay attack.

The most simple method to prevent this is to include a message counter as part of the message, and reject any message with a counter equal to or less than the last message. The message counter should be large enough so that key changes would occur before the counter loops. A 32-bit message counter allows 100 messages per second for about 497 days.

This alone may not be sufficient. Mallory could intercept and block all messages, and if it is known what the message probably is at a given time, could retransmit that specific message when it is at her benefit. An example is the "stop trading" message that occurs at exactly 4pm. It could be delayed until after Mallory has benefited from the extra trading activity in some way.

That attack can be mitigated by the use of a TTL (time to live), telling how long a message is valid after its transmit time, along with mandatory acknowledgment of message receipt, and accurate time sync. Depending on the use case, this may present its own problems in the form of denial-of-service. The acknowledgment allows Alice to determine if Bob got the message within the expected timeframe, and if Bob accepted or rejected the message, and the reason for rejection.

A message counter, time code, TTL, or other piece of information sent with the message that is critical to the security of the system but not encrypted must be authenticated. The encrypted data of course must also be authenticated. In practice this is done by choosing an AEAD cipher or mode, or adding a supplementary integrity check such as HMAC. If the cipher requires a nonce, the message counter and time code could be a component of the nonce, and thus implicitly authenticated. Care needs to be taken to keep accurate count and time to prevent possible reuse.