Add encrypted client data support #88
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…oaded This process is very expensive on low powered hardware so this should result in a better user experience, particularly as we use the cache more.
We use a single derivation for both as follows, given a privately derived pub key P: - TMP_KEY = HMAC_SHA512(P, PASSWORD_SALT, 2048) - AES_KEY = SHA256(TMP_KEY[:32]) - HMAC_KEY = TMP_KEY[32:]
jgriffiths
force-pushed
the
green_ss_to_merge
branch
from
1b4b9ff
to
8a4de54
Compare
These implementations differ from the existing cache ones in that they operate directly on memory buffers.
When getting or setting values from the blob, load it if its obsolete. This mostly eliminates failed server blob saving attempts, and ensures we always fetch the most recent data from it.
Also share the code to retry blob updates.
Its not going to be possible to store for better compression and also keep the client blob backwards compatible, so remove that FIXME.
This prevents the server from returning old client blobs.
Without this terminate() is called when these exceptions fire.
jgriffiths
force-pushed
the
green_ss_to_merge
branch
from
8a4de54
to
1a4de39
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds support for end-to-end encrypted client data (a 'client blob'), cached locally and backed up/synchronized between wallet installs using the Green backend servers. The Green servers do not and cannot know the contents of the users data, nor can they attempt to maliciously modify it, downgrade it to an earlier version, or censor it without the users wallet detecting it.
On connecting with a client blob enabled wallet, any existing tx memos and subaccount names are migrated into the client blob. New wallets will use the blob from wallet creation. Once the blob is initialized, memos and names are never passed to the server except inside the encrypted blob.
A backend server job will periodically remove the memo and subaccount name data from the backend for wallets that have upgraded. Once a user has set their client blob, the server allows logins only from blob-enabled wallets, and rejects any attempts to store memos/names unencrypted using the existing API end points.