You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 be set actions made to encrypted-data.
The text was updated successfully, but these errors were encountered:
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
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
There must be smarter approaches to doing this.
E2E encrypted - using special
Encrypted
classInstead of encrypted storage, we could encrypt resources end-to-end:
We could introduce the
Encrypted
class, which as one requiredencrypted-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.public-key
property, which indicates with what key the object was encrypted.The client then decrypts the data, allowing the user to interact with the data as usual.
encrypted-data
should not end up as plain JSON-AD. All changes in Commits need to beset
actions made toencrypted-data
.The text was updated successfully, but these errors were encountered: