Avoid repeating duplicate messages that always look the same after encryption and can be reproduced by an attacker?

Question

I am looking for authentication that a particular message comes from a specific location.

Example. Resends the same message to B. Lets say that this message is "helloworld" , which is encrypted to "asdfqwerty" .

How can I guarantee that the third-party C does not recognize that B always receives the same encrypted string, and C starts sending "asdfqwerty" to B?

How can I make sure that when B decrypts "asdfqwerty" to "helloworld" , it always gets this "helloworld" from A?

Thanks for any help.

Answer 1

For the first, you want to use the Operation mode for your symmetric cipher, which uses the Initialization vector . IV ensures that each encrypted message is different, even if it contains the same plaintext.

For the latter, you want to sign your message using the private key A (lice). If B (ob) has Alice’s public key, he can check if she really created the message.

Finally, beware of repeated attacks , where C (harlie) writes the correct message from Alice and then repeats it to Bob. To avoid this, add nonce and / or a timestamp to the encrypted message (yes, you could do a double IV job as nonce).

Answer 2

Add a random value to the encrypted data and whenever it is decrypted, delete it from the original unencrypted data.

You need a good random number generator. I'm sure Google will help you with this.

Answer 3

C, noticing that B receives the same encrypted message twice, is a problem called traffic analysis and has historically been a serious problem (but this was in the time leading up to public key encryption).

Any decent, publicly available encryption system includes some random additions. For example, for RSA, as described in PKCS # 1 , an encrypted message (no longer than 117 bytes for a 1024-bit RSA key) receives a header with at least eight random (non-zero) bytes and some additional data that allows the receiver to unambiguously find the bytes fill in and see where the "real" data begins. Random bytes will be regenerated every time; therefore, if A sends twice the same message to B, the encrypted messages will be different, but B will restore the original message twice.

Random filling is required for public key encryption precisely because the public key is publicly available: if encryption was deterministic, then the attacker could “try” potential messages and look for a match (this is an exhaustive search for possible messages).

Public key encryption algorithms often have serious limitations on the size or performance of the data (for example, using RSA, you have a strict maximum message length, depending on the size of the key). Thus, it is customary to use a hybrid system: public key encryption is used to encrypt the symmetric key K (i.e., a bunch of random bytes), and K is used to symmetrically encrypt the data (symmetric encryption is fast and has no limit on the size of the input message). In a hybrid system, you generate a new K for each message, so it also gives you the randomness you need to avoid the problem of encrypting the same message several times with this public key: at the public encryption level, you never encrypting the same message twice (the same key K), even if the data that is symmetrically encrypted with K is the same as in the previous message. This will protect you from traffic analysis, even if the public key encryption itself does not include random padding.

When symmetric encryption of data with key K, symmetric encryption should use the "initial value" (IV), which is generated randomly and uniformly; it is integrated into the encryption mode (in some modes it only requires a non-repeating IV without the need for random uniform generation, but CBC requires random uniform generation), This is the third level of randomness that protects you from traffic analysis.

When using an asymmetric key agreement (static Diffie-Hellman ), because they are a little more complicated, because the key agreement leads to a key K that you don’t choose, and which can be the same always and always (between the given sender and receiver). In this situation, protection from traffic analysis is based on the random chance of symmetric encryption IV.

Asymmetric encryption protocols such as OpenPGP describe how all symmetric encryption, public key encryption and randomness should be related to each other, smoothing tricky details. You are strongly advised not to invent your own protocol: it is difficult to develop a secure protocol, mainly because it is not easy to check for the presence or absence of any weakness.

Answer 4

You might want to learn block cipher modes . However, the modes are designed to work with a data stream that is sent over a reliable channel. If your messages fail due to unreliable transport (for example, UDP packets), I don’t think you can use it.