Beapi-io / spring-boot-starter-beapi

Springboot 'convention over config' starter for API Automation
Other
1 stars 1 forks source link

TASK : encrypt/decrypt keys for RESPONSE/REQUEST so DB doesn't have to #31

Closed orubel closed 1 year ago

orubel commented 1 year ago

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.

orubel commented 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)

orubel commented 1 year ago

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 :

orubel commented 1 year ago

ok so on further research, this paper is from 2017, tried implementing and is slower than murmur. Not functional. Throwing out.

orubel commented 1 year ago

reopening. while AES/CTR is not a good choice for hashing, AES/GCM MAY still be an option for encrypt/decrypting keys.

orubel commented 1 year ago

changed name of issue to reflect what is left of this issue

orubel commented 1 year ago

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.