CODEWITHSUNDEEP
databaseapisecurityencryption
Juraj Mlich
Juraj Mlich

Reputation: 688

Encryption of an identifier without IV

Suppose we have an ID of a person that we want to keep secret and external applications should never know it (for example a social security number). If a person makes an action, we want to inform the external application that some person did this and that. If the person makes multiple such requests, we want the external application aware that it's from the same user.

So we need a unique ID that's like a shadow of the social security number. We can generate unique ID for each user, but we'd like to avoid storing anything. So we were thinking that we'd only encrypt the social security number. However, each encrypted value of the social security number would be unique due to IV, so the external user wouldn't be able to say if two actions were done by the same user.

Is there a cipher that allows this and is secure enough or is there a way to achieve this without storing any additional data?

Edit: forgot to mention that the external applications can in turn query for more data about that particular user. So we need a way to again deanonymize/decrypt the identifier that we originally sent him.

Upvotes: 0

Views: 136

Answers (1)

Luke Joshua Park
Luke Joshua Park

Reputation: 9806

From your question and comments, it sounds like you have the following requirements:

  • The value will be less than 20 characters (I'm assuming here 20 single-byte UTF-8 characters).
  • The value needs to be securely encrypted.
  • It should be possible to decrypt the value.
  • Encryption should be deterministic under a given key.

This is one of the rare cases where ECB mode can be safe. It is important that you select a block cipher that has a block size larger than your maximum plaintext length, in bytes.

In this case, Rijndael with a 192 bit block size is what I would pick, but you might struggle to find implementations. If you don't need to be conservative with length, Rijndael with a 256 bit block size is fine too.

So, simply:

  • Encrypt with Rijndael (192 or 256 bit block size, key size of your choice) using PKCS#5 (or 7) padding.
  • Decrypt using the same.

Do not:

  • Allow your encryption operations to use multiple blocks. This can potentially introduce pattern recognition and other tricks to manipulate and expose data under ECB.
  • Allow third parties to submit and view plaintext/ciphertext pairs. Again, not as much of an issue when you are operating within a single block, but allowing third parties to submit something for encryption and then view the result can, in certain circumstances, expose the entire plaintext.

Upvotes: 2

Related Questions