I need an alternative to initialization vector encryption - encryption

Question

I helped a small non-profit create a cool "anonymous" help line where their clientele can send in SMS questions to a phone number and organization can respond without knowing who the client is. It's proven to be a very helpful tool for the organization. I am in the process of re-writing it from scratch and am looking for advice on how to handle the anonymity aspect of it.
The way that v1 works is by simply encrypting / decrypting the client phone number and using that as the client id in the data model using 'aes-256-ctr'. Since the staff / leadership of the nonprofit do not have access to the encryption key, they can legitimately claim to not be able to have access to any p.i.i. not disclosed voluntary by their clients. When they issue a message response to the client, I simply need to decrypt the client id to get the phone that I need in order to dispatch the message.
v1 encrpytion strategy:
export const encrypt = (text) => {
const cipher = crypto.createCipher(algorithm, password);
let crypted = cipher.update(text, 'utf8', 'hex');
crypted += cipher.final('hex');
return crypted;
};
export const decrypt = (text) => {
const decipher = crypto.createDecipher(algorithm, password);
let dec = decipher.update(text, 'hex', 'utf8');
dec += decipher.final('utf8');
return dec;
};
Lately though, I've been getting console warnings because new node versions will output a warning when using createCipher instead of createCipheriv to utilize initialization vector. On my v2 rewrite I switched it over to createCipheriv, but that has the effect of "randomizing" the encryption output and breaking my ability to rely upon the encrypted phone number as a reliable, consistent client id. Being able to reliably group client messages is an important requirement to provide a conversational view in the UX.
How might I properly encrypt the identifying phone number such that only I can decrypt it at message send time and still have some kind of consistent internal ID by which to group messages? I don't HAVE to rely upon the encrypted phone number as the client id, but I can't think of any reliable alternative (via a lookup table of some kind). If possible I don't want to fall back on createCipher without the I.V. if its not a best practice.
I should note that this application is not dealing with any legally sensitive information or anything high stakes like that. I probably could get away with storing the unencrypted phone number in the database and just not exposing it to the front end and maintain anonymity, I just really don't like that idea if there is a sensible workaround.
Any ideas?

Answer 1

You should be generating a new random (or UUID-style) client id for each new client. The benefit of this is that you can keep using a secure encryption method and still identify and lookup users quickly.
If you want the phone number field to act as a unique lookup, simply take an HMAC of the phone number and use that for lookups (as well as storing encrypted) - it can't ever be decrypted and is guaranteed to be consistent across invocations for the same phone number under a given key.
EDIT: To migrate existing data, you should, for each record, take the client_id (currently the encrypted phone number), decrypt it, HMAC it, and store the result in a new column. Then, generate a new ID and set that to be the client_id. This allows lookup by actual client_id and by phone number.