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

Encrypt seed #192

Merged
merged 14 commits into from
Feb 22, 2023
Merged

Encrypt seed #192

merged 14 commits into from
Feb 22, 2023

Conversation

sasho-axellero
Copy link
Contributor

Purpose

Encrypt the seed and save it securely.

Changes

Encrypt seed before saving.
Encrypt already existing seed.
Re-encrypt seed with new password when changing passwords.

Checklist

  • My code follows the style of this project.
  • The code compiles without warnings.
  • I have performed a self-review of the changes.
  • I have documented my code, in particular the intent of the
    hard-to-understand areas.
  • (If necessary) I have updated the CHANGELOG.

@sasho-axellero sasho-axellero requested review from abizjak, ali-concordium and bisgardo and removed request for abizjak February 3, 2023 07:27
…references.kt


simplify delete and save

Co-authored-by: Michael Bisgaard Olesen <michaelbisgaardo@gmail.com>
Copy link
Contributor

@bisgardo bisgardo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand the flow of where the seed phrase is supposed to be migrated; it seems like it's happening all over the place.

We have tryToSetEncryptedSeedPhrase, setSeedPhraseEncrypted, and checkAndTryToEncryptSeed that all write the encrypted phrase. And same with getSeedPhrase and getSeedPhraseDecrypted for reading it. I can't really see any logic in which variant is used where, and some of them additionally check and delete the unencrypted one.

I feel like there should just be a migration function somewhere in the initial code path that does the following:

  1. Check if the encrypted seed is stored. Return if it is.
  2. Otherwise, encrypt the unencrypted seed and store it.
  3. Decrypt the stored encrypted seed and compare it against the unencrypted one. Delete the latter if they match.

After this, we just pretend like the unencrypted one never existed. No need for fallbacks to the unencrypted seed.

You can also choose to handle it gracefully if storing the encrypted seed failed. Then you would probably do item 3 above just before returning in item 1. And keep the fallbacks.

@ali-concordium
Copy link
Contributor

There are quite a few comments. Let's have a live session tomorrow, where we talk instead of type :-)

…entication Screen until the old seed is encrypted and deleted.

Added error status and error explanation for failed seed encryption on the Authentication Screen
Copy link
Contributor

@bisgardo bisgardo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the activity and view model stuff well enough to review that properly, but the rest looks good.

sasho-axellero and others added 3 commits February 21, 2023 11:48
…references.kt


Removed encrypted seed check

Co-authored-by: Michael Bisgaard Olesen <michaelbisgaardo@gmail.com>
…nActivity.kt

Co-authored-by: Michael Bisgaard Olesen <michaelbisgaardo@gmail.com>
Added comment to checkAndTryToEncryptSeed.
Named parameter in saveSeed lambda.
@sasho-axellero sasho-axellero merged commit f0fd0f7 into main Feb 22, 2023
@sasho-axellero sasho-axellero deleted the encrypt_seed branch February 22, 2023 07:21
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

Successfully merging this pull request may close these issues.

3 participants