1

I need to keep sensitive data in a de fact public place (i.e. with a user, e.g. in a cookie) and only there (no copy or hash of that data should be kept on the server).

The data was encrypted AES/CBC and the private AES key is kept secret on the server (the kind and safety of this key should not be a concern here, let's say it is beyond doubt).

To make use of the data the user sends the encrypted data to the server, which decrypts it with the private key.

So far so good, but here is my question: I need to ensure the integrity of the data (i.e. make sure the user did not temper with the data).

What are my options to ensure the integrity?

Constraint: ideally I would not have to store any derivate of the encrypted data on the server, not even its HMAC hash.

robert
  • 113
  • 3

1 Answers1

3

You can append both the intended recipient, possible a timestamp or counter (see Ángel's comment), and the hash to the original data, and then encrypt. Upon decryption, you can compare the origin, and the original intended recipient, as well as the hash.

This will not prevent other parties from tampering with the encrypted blob before it reaches your server, but it will enable you to verify it when it reaches your server.

Sinan Ünür
  • 180
  • 1
  • 10
  • 2
    Thank you, this is the solution I was also considering. I will keep the question open for now to see if there are other options. Now I find myself working on the message format (e.g. recipient + hash of data + actual data) and I have the sneaking suspicion that I am reinventing the wheel. – robert Aug 23 '15 at 12:45
  • 1
    Actually, that's that you should do. There's no much problem if the cookie is just a key for retrieving data stored in the server, but if the cookie is the data (eg. "Bob has $100"), you don't want the users to modify the 10th character! Not even blidly. :) Moreover, you may also need to ensure there's not back in time (such as setting the old cookie again after spending $70). – Ángel Aug 23 '15 at 21:18