Home/ Questions/Q 673623
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T00:36:58+00:00

What is the simplest way I can hide a sensitive identifier, while providing some

  • 0

What is the simplest way I can hide a sensitive identifier, while providing some equivalent means of identifying the data from outside?

For example, lets say I have a database table with records and one of them is an sensitive ID field.

ID
2A
1S
etc...

then I want to have a second record:

ID    PublicID
2A    AXXX44328
1S    KKKZJSAAS

such that when I am given a PublicID I can always determine what ID it refers to:

H(PublicID) = ID

but nobody else is able to do so.

Also note, that I want to be able to reproduce the string in at least two different locations. So if I have two servers/database, the ID 2A has to map to string AXX44328 on each one of them independently.

I suspect this is like, encryption – with throwing away a public key?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If your IDs are relatively short (15 bytes or less) then I suggest encrypting them with a block cipher, namely the AES. The AES uses a secret key K, which has length 128, 192 or 256 bits (128 bits are enough). Since AES processes a block of exactly 16 bytes, you have to pad your ID a bit. The “usual” padding (known as “PKCS#5”) consists in adding n bytes (n >= 1), all of them having value n, such that the resulting length is appropriate (here, you want a length of 16).

    So the transformation of ID (the sensitive data) into S (the scrambled string which can be shown to the public at large) is: S = AESencrypt_K(pad(ID)). The reverse operation is: ID = unpad(AESdecrypt_K(S)). If ID is 16 bytes or more, then encryption will use several invocations of AES, and there are subtleties with regards to how those invocations are linked together. The keyword is chaining mode and the usual answer is “CBC”.

    Knowledge of the secret key K (the same K) is needed for both operations. This means that whoever can compute S from ID can also compute ID from S, and vice versa.

    Now if you need some entities to be able to compute S from ID without giving them the power to do the reverse operation, then things are more complex. In particular, you must not have a deterministic process: if there is a single S which can be computed from ID then anybody can try an exhaustive search on the possible values of ID until a match with a given S is found. So you have to relax the model, in that a given ID may yield a great number of possible scrambled strings S’, such that all those S’ may be converted back into ID by someone who has the “right” secret value. This is what you would get from asymmetric encryption. The usual asymmetric encryption algorithm is RSA. With a 1024-bit RSA key (a typical size for proper security), ID could have a size up to 117 bytes, and S’ will be 128-byte long (the size increase corresponds to the injected random data which makes the process non-deterministic). If 128 bytes are too much, you can get shorter encrypted messages with El-Gamal encryption over elliptic curves (down to about 40 bytes or so, for an up-to-20-byte ID), but you may have a hard time finding an existing implementation.

    • 0