0

I am designing a service where each user has both a unique 256-bit private and public ID. These IDs should be derivable from one another, but only within the backend of my service (as to not expose the private IDs to other users). For this purpose, I am considering using AES with a key known only by my service, but this requires an IV for encryption, which is generally meant to be unique. Is this necessary for my use case? I've read that this is done so encrypting the same data twice does not result in the same ciphertext, but in my case this is exactly the necessary behavior. However, not knowing much about cryptography, I wonder whether there could be other issues with this, or if I can just set the IV to zero and call it a day?

Essentially, an attacker in this scheme is able to request an unlimited number of unique private IDs and get each one's corresponding public ID. Does my system remain secure in this scenario? Would a unique IV per key pair do anything to help here?

Also, if there are any other glaring issues with this scheme or better tools for the task than AES, please feel free to mention - I'd love to know about them!

Bonus context irrelevant to the question for those curious why I am doing this:

I want users to be able to interact with my service before signing-up. These users must still have an ID so resources they create can be associated with them. This ID will be stored as a cookie to mark them as the same user until sign-up. After sign-up, the ID is associated with their chosen authentication method which is required to continue being recognized as that user. However, until that point, their identity could be hijacked by anyone who knows their ID, which means I cannot use it in public URLs and such, hence the need for a public ID which is suitable for this purpose

Ryan Hilbert
  • 103
  • 3

1 Answers1

2

Is this necessary for my use case? I've read that this is done so encrypting the same data twice does not result in the same ciphertext, but in my case this is exactly the necessary behavior.

Making sure that encrypting the text twice doesn't result in the same ciphertext is not the only reason for IVs. It is one which is true for any encryption mode that takes an IV; however many modes have additional reasons.

Background: there are a lot of different ways to use AES to encrypt data (not to mention accomplishing other tasks); we term these different ways 'modes of operation'. These differing 'modes of operation' use the IV different (actually, some don't take an IV); those that do make different assumptions about how the IV are generated, and different failure modes if those assumptions are violated.

You've tagged the question with aes-gcm; for that mode, the assumption is that the IVs are unique (and it makes no assumptions beyond that); however if that assumption is violated, it breaks pretty badly:

  • For the two messages that are encrypted with the same IV, the attacker can learn the xor of the two plaintexts. This can often (depending on what the messages are; essentially what language they are in) allow the attacker to recover the full plaintext of the messages.

  • The attacker can learn (with only a handful of false hits) the internal H value of GCM; this allows the attacker to modify any message (by flipping bits) without being detected (hence completely breaking the integrity part of GCM).

So, if you're using GCM, DON'T USE A FIXED IV if you are encrypting multiple messages with the same key. You'd be far better off having the encryptor select a random IV, and include that in with the message (or pick a different mode that has easier to meet assumptions).

poncho
  • 147,019
  • 11
  • 229
  • 360