Closed orubel closed 1 year ago
So am looking at AES-CTR for the ID encryption and may just use this for cacheHash as well (no need to decrypt there) : ""A Pseudo Random Generator (PRG) and a hash function are both Pseudo Random Functions (PRFs),"
Also CTR is faster for encrypt and for the 'hashing', thats what we need.
HOWEVER... this will mean that our default value for hash and encryption will now need a check or the starter will not run (thus enforcing the change of values in a 'bootstrap' config (new task of couyrse)
so after a bit of consideration, this is very doable as long as the cipher maintains randomness. And I think I could do that with AES/GCM
so most likely :
ok so on further research, this paper is from 2017, tried implementing and is slower than murmur. Not functional. Throwing out.
reopening. while AES/CTR is not a good choice for hashing, AES/GCM MAY still be an option for encrypt/decrypting keys.
changed name of issue to reflect what is left of this issue
Too ambitious for now. It's DOABLE... BUT to have this be DB agnostic, requires key/hash association in cache/nosql to allow for hash rotation.
Going to close this all and maybe look at this again in the future.
the more I look at encrypting/hashing the PKEY/FKEY/IDX, the more I ponder encryption as an option and replacing hashing altogether.
Streaming cyphers are faster and perform similarly (at least for our purposes) and using encryption would make it easier for testing and rotating hash (or encryption in this case).
The excuse previosuly has been that it would be easier for testing but didn't want to go down this route because it opens privacy concerns.
This is why we would need to make this a VERY OPEN and WELL DOCUMENTED set of processes to maintain trust if we go down this route.
Providing security means providing TRUST.