search

pardot / deci

Apache License 2.0
1 stars 1 forks source link

Implement at-rest encryption for Keys #11

Open lstoll opened 5 years ago

lstoll commented 5 years ago

We should have an optional at-rest encryption method for private key data that is persisted in the storage.

alindeman commented 5 years ago

@lstoll Do you think it'd be too taxing if we just encrypted every value in storage, if the storage is configured that way? Or do you think we need some way to differentiate between non-encrypted and encrypted values?

lstoll commented 5 years ago

Probably not, really. It would make manually reading data from the DB slightly harder, but we shouldn't be doing that anyway.

One thing to consider is the lifecycle of keys for rotation - right now, we rotate signer regularly so rotating an encryption key would take affect in a known window. If we do everything, how would we handle an encryption key rotation for a value in storage that lives forever? Definitely something solvable later, just worth a thought.

alindeman commented 5 years ago

Probably not, really. It would make manually reading data from the DB slightly harder, but we shouldn't be doing that anyway.

Cool.

One thing to consider is the lifecycle of keys for rotation - right now, we rotate signer regularly so rotating an encryption key would take affect in a known window. If we do everything, how would we handle an encryption key rotation for a value in storage that lives forever? Definitely something solvable later, just worth a thought.

That's fair. Maybe we have a subcommand that rekeys everything with the latest key, which we use when we rotate the key?

I'm not necessarily sold on it, but it would maybe be easier to just transparently encrypt everything than introduce it as a client-specified option everywhere.