Lower case feature for hashing

[martijn-dev]

Hi François,

First of all, thanks for creating this extension. It has been working great for me so far!

I'm working with the hashing option and I was wondering if it is possible to lowercase the input before making a hash out of it.

For example:
We have the following model:

model User {
  id                String  @id
  name          String  @unique /// @encrypted
  nameHash String? @unique /// @encryption:hash(name)
}

The user provides a name: MartijN.
Now I would like to be able to find this user back with a lowercase string martijn, but still decrypt the name field back to MartijN.

Would it be possible to add a "toLowerCase" feature to the input for the hash. (and maybe even to the where query on a search, although you can do that outside the extenstion as well.)

Something like @encryption:hash(name)?transform=lowercase

Would love to hear your opinion/ideas!

Cheers,
Martijn

EDIT:
While submitting I realized that other forms of input transformation might be relevant as well. You might want to find a name like François back with an input francois.

JS has a function for this:
"François".normalize('NFD').replace(/\p{Diacritic}/gu, '');
(https://stackoverflow.com/a/51874002/16813398)

[franky47]

This is a good idea, more broadly it's about whether exact matching is case-sensitive (as it is currently) or not (your proposal).

One thing I'd be wary about is locale-aware case sensitivity:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/toLocaleLowerCase

For the normalisation part (and the casing too for that matter), the lossy aspects of the transformation could cause some issues where two different underlying values end up with the same hash (which would cause a unique constraint failure on write).

[martijn-dev]

You're right. It might be conflicting to do a transform on the hash for unique fields. My example is a bit misleading in that case as well, since you probably don't want to have a unqiue key on a name.
I think a feature like this would only work well on fields that don't have a unique key. Fields with a unique key, you might want to transform before inserting already.

In the example below:

model User {
  id                String  @id
  email          String  @unique  /// @encrypted
  emailHash String?  @unique /// @encryption:hash(name)
  name          String  /// @encrypted
  nameHash String? /// @encryption:hash(name)
}

You probably don't want to transform the email field in the hash, since you should do this at insert already. (you don't want [email protected] and [email protected] in you system at all if they should be unique).

My focus is on the fields that are not unique.