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

Add plausible deniability to vaults #5872

Open
leafcutterant opened this issue Dec 2, 2018 · 0 comments
Open

Add plausible deniability to vaults #5872

leafcutterant opened this issue Dec 2, 2018 · 0 comments
Labels
area-accounts Relating to how sensitive account data is managed and stored. T08-featureRequest type-security

Comments

@leafcutterant
Copy link

What problem are you trying to solve?

Someone walks up to you and forces you to log in to MM. "I forgot the password" doesn't quite make it.

Describe the solution you'd like

Have an option in the vault to set up a secondary vault, tied to the primary one. This requires you to define a password to the secondary vault, one which is different from the primary vault's password. Upon logging in with the secondary password, the secondary vault will open, which will be indistinguishable in function from the primary one and enjoys the same permanence and customizability as the primary one, but will have different addresses and potentially different external accounts and token additions.

This is just an idea and raises many hard questions to which I don't know the answers. Here's an unstructured stream of the problems.

  • To implement something like this, we may need fancier crypto.
  • We need to redefine the structure of how vaults are stored.
  • We may need/want to convert vaults with the old structure to the new one if something like this becomes implemented. How do we do that safely?
  • We need to make sure that vaults with and vaults without a secondary vault are indistinguishable from the outside.
  • We need to make sure that primary and secondary vaults are indistinguishable from the inside.
  • Should the secondary be derived deterministically from the primary, deterministically from the new password, or just purely randomly?
  • How do you check that the two passwords are not the same?
  • Once you're logged into the primary, should you be able to detect that there's a secondary? If yes, should you be able to modify it from there?
  • What should happen if you already have a secondary, but you define a new secondary?
  • What should happen if we define a secondary while logged into the secondary?
  • If we allow a recursive chain of subvaults or multiple secondary vaults (may be desirable), how do we ensure indistinguishability from the outside?
  • Many other questions I haven't thought of.
@bschorchit bschorchit added the area-accounts Relating to how sensitive account data is managed and stored. label Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-accounts Relating to how sensitive account data is managed and stored. T08-featureRequest type-security
Projects
None yet
Development

No branches or pull requests

4 participants