-
Notifications
You must be signed in to change notification settings - Fork 0
Spec
Eric Chang edited this page Mar 3, 2023
·
3 revisions
- src
- Contracts
- KeyManager
- KeyProvider
- Securable
- Models
- EncrpytionKey
- Traits
- Securable
- Observers
- ModelObserver
- KeyProviders
- AwsKmsKeyProvider
- KeyManager
- SecurityModelServiceProvider
- Contracts
- Key Provider
- encrypt/decrypt data
- encapsulate detail of integrating external key management service
- Key Manager
- retrieve available encryption key
- encrypt/decrypt encryption key through key provider
- retrieve available encryption key
- Model Trait
- retrieve encryption key thought key manager to encrypt/decrypt model data
- update model blind index
- define relationship with encryption key
- register model observer
- Model Observer
- listen model event
- retrieved event
- encrypt data
- saving event
- encrypt data
- saved event
- decrypt data
- retrieved event
- listen model event
to achieve searching on encrypted fields, we use a strategy called blind indexing. its idea is to store a hash value of the plaintext in a separate column and would it will be used for searching.
- Plan A: Create a polymorphism table for storing all blind indexes
- Pros
- developer wouldn’t need to create migration to add blind index column for every table
- package wouldn’t need to handle customization(ex. blind index column name)
- Cons
- encryption on multiple tables would create a huge amount of data in the blind index table, and that might cause potential performance issue
- developer should need make sure the updating operation across the model table and index table is at the same transaction to avoid race condition
- Pros
- Plan B: Create an additional column on the original table for storing the blind index
- Pros
- implementation is simpler for unique index
- searching and updating on the same table/B-tree would make performance better
- can make sure an updating operation of raw value and hash value is consistent & atomic
- Cons
- need to create many additional columns for each searchable column. (email_bidx, phone_bidx, address_bidx, etc...)
- Pros
we choose to use Plan B because we should highly consider performance issues when developing this package.