In a web application, I need to send in a webpage form an id (my plain text) and then retrieve it back when the user submit the form. But i need the id to be protected, so malicous users can't send an incorrect id to the server.

I was thinking to send the id and the cypher text to the client, and when i retrieve them server side, i decrypt the cypher text, and if the id don't match the decrypted value, i reject the call. I am using AES with 256bit key.

So the question is : is it safe to do that? is there a better way? thank you for your help

PS : There is a business need to send the id as plain text (not encrypted) to the client.


Use a message authentication code if you want to ensure that the id is not modified by the client. Use SSL between the server and the client if you want to prevent replay etc network layer attacks from eavesdroppers.

But a malicious client can still reuse previously received ID. If this is a concern, you need to do more (e.g. use and keep a nonce for verification).


With any modern¹ encryption mechanism, it's safe to send the plaintext and the ciphertext together, but that doesn't help you. Encryption mechanisms have the property that if someone has a series of plaintexts and their corresponding ciphertexts, and they have one more ciphertext for which they don't have the corresponding plaintext, and they don't have the key, then knowing all of these plaintext-ciphertext pairs doesn't help them decrypt that mysterious ciphertext. This says nothing about being able to build a ciphertext from a plaintext. Depending on the encryption mechanis, this may be completely trivial or possible only with certain specific arrangements of data, but it's not a goal of encryption mechanisms.

What you need is an authentication mechanism. The client has some data in cleartext, and an extra blob which they don't need to be able to decode. Given the cleartext and the extra blob, you want to guarantee that the extra blob was generated by your server for that particular cleartext. The blob is called a signature if using asymmetric cryptography, and a MAC if using symmetric cryptography. Authentication mechanisms have the property that without the key, it's impossible to generate the signature/MAC of a piece of data. This property is exactly what you need.

In plain English: encryption lets you keep the data secret. You have no interest in keeping the data secret, so encryption is not useful here. Authentication lets you check that the data has not been modified, which is what you want.

Since your server is both creating the authentication blob and verifying it later, you can symmetric cryptography, i.e. use a MAC. The most popular family of MACs is HMAC, which doesn't use AES inside. HMAC is available in virtually every cryptographic library.

Note that a MAC (or signature) only guarantees the authenticity of the data, i.e. it guarantees that your server signed it at some point in the past. It doesn't say anything about why your server signed it, so as always, use the key only for the purpose of validating IDs, don't use the same key for different purposes.

The MAC (or signature) also doesn't say anything about when your server signed it, so just because the client can show an ID with a correct MAC doesn't mean that this ID is valid: it only means that the ID was valid in the past. How to deal with that depends on how your IDs become invalid. For example, if IDs remain valid until the server reboots, then you could generate a new key at boot time; IDs from before the reboot would not be signed with the new key and so would be invalid. If it's possible for some IDs to become invalid while other IDs are still valid, then you need a more complex mechanism, perhaps separate keys for each client.

¹ “Modern” meaning anything from the computer era. Obviously this applies only to mechanisms that are widely approved by the cryptographer community, not to homemade or discredited mechanisms.

  • $\begingroup$ thank you for your help, can you explain to me why using HMAC versus just using a secret key to encrypt the data? $\endgroup$ – riadh gomri Jun 8 '18 at 9:32
  • $\begingroup$ @riadhgomri HMAC uses a secret key to authenticate the data. This means that you can verify that the data has not been modified, which is what you want. If you used a secret key to encrypt the data, it would let you keep the data secret, which you have no interest in. $\endgroup$ – Gilles Jun 8 '18 at 12:04
  • $\begingroup$ I am sorry Gilles i really don't get it, if i use HMAC i will send the data and the HMAC to the client? the same thing is with a secret key, i encrypt the data and send it to the client with the encrypted value, then i decrypt it server side and see if it matches. AM I missing something? $\endgroup$ – riadh gomri Jun 8 '18 at 12:15
  • $\begingroup$ @riadhgomri With encryption, the client can change the plaintext ID that it sends back and change the encrypted version to match. Depending on the encryption algorithm, this may be trivial, or it may be difficult but not impossible. With a MAC, the client can't do this. If they change the id, then they can't create a valid MAC for it. $\endgroup$ – Gilles Jun 8 '18 at 16:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.