Description
As of now, all data is stored as binary serialized structs using Sled. Some have asked me whether encryption will be added. Maybe? The thing is, I don't know yet what a good way of encrypting the storage would be. Some thoughts in this issue:
Use one key per store / instance
- On startup, read the key in memory.
- On reading a Resource on the server, first decrypt it before running it through
bincode::serialize
.
The encrypted_sled
crate might help here.
I'm a bit scared that this will have a serious impact on performance, so at the very least is should be optional.
One key per user / drive
- Each resource is encrypted with the public key of its top level parent
- Server will need to know how to decrypt it (e.g. for queries) - so it needs all keys... That's bad
There must be smarter approaches to doing this.
E2E encrypted - using special Encrypted
class
Instead of encrypted storage, we could encrypt resources end-to-end:
We could introduce the Encrypted
class, which as one required encrypted-data
property. This will be an encrypted string that, when decrypted, becomes a JSON-AD object. It cannot have an @id
property, as the @id
is known and should be used to retrieve the resource.
- The resource can also have a
public-key
property, which indicates with what key the object was encrypted. - We could also have a property indicating the algorithm used
The client then decrypts the data, allowing the user to interact with the data as usual.
- Querying the fields will not be possible, as the server cannot decrypt the data
- The feature would be pretty easy to implement on the server side.
- The front-end side will require serious work, especially related to commits. Changes made to any field that arised from the
encrypted-data
should not end up as plain JSON-AD. All changes in Commits need to beset
actions made toencrypted-data
.