Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encrypted storage #300

Open
joepio opened this issue Feb 11, 2022 · 0 comments
Open

Encrypted storage #300

joepio opened this issue Feb 11, 2022 · 0 comments

Comments

@joepio
Copy link
Member

joepio commented Feb 11, 2022

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.
@joepio joepio mentioned this issue Apr 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant