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.

Sign up for GitHub

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

Jump to bottom

xud master password #912

Closed
kilrau opened this issue Apr 26, 2019 · 6 comments
Closed

xud master password #912

kilrau opened this issue Apr 26, 2019 · 6 comments
Assignees
@sangaman
Labels
configuration cryptography Issues related to encryption & signing packets or local data P1 top priority

Comments

@kilrau
Copy link
Contributor

kilrau commented Apr 26, 2019 •
edited
Loading

Needs some research if this could work like this @sangaman :

  • let's btclnd create memonic, use it for xud and inject it in all other non-preexisting nodes
  • encrypts xud's private key and all other nodes non-preexisting nodes private key with xud master password
  • lnd macaroons, full-node rpc passwords
  • pre-existing LND/raiden/fullnode's: user has to enter passwords and xud stores and encrypts these pws with master password. Needs great explainer on what is happening here and why this is secure.
  • as just discussed, this should be a xud core function exposed as gRPC and CLI call
@kilrau kilrau changed the title xud master password [Concept] xud master password Apr 27, 2019
@kilrau kilrau assigned ghost , sangaman and kilrau Apr 27, 2019
@kilrau
Copy link
Contributor Author

kilrau commented Apr 27, 2019 •
edited
Loading

Need your feedback on the concept in general and also if you see any reason why this shouldn't be part of xud core @sangaman @erkarl

Old issue on this topic: #184

@kilrau kilrau added this to the 1.0.0-sprint.15 milestone Apr 27, 2019
@kilrau kilrau added configuration cryptography Issues related to encryption & signing packets or local data labels Apr 27, 2019
@kilrau kilrau unassigned ghost and kilrau Apr 27, 2019
@kilrau kilrau changed the title [Concept] xud master password xud master password Apr 27, 2019
@kilrau kilrau assigned ghost Apr 29, 2019
@kilrau
Copy link
Contributor Author

kilrau commented Apr 29, 2019

Divide & conquer for @sangaman @erkarl

@kilrau kilrau added the P1 top priority label Apr 30, 2019
@kilrau kilrau mentioned this issue May 1, 2019
Closed
@kilrau kilrau modified the milestones: 1.0.0-sprint.15, 1.0.0 May 8, 2019
@kilrau
Copy link
Contributor Author

kilrau commented May 14, 2019

As per #889 (comment), this includes simplifying and integrating the following LND calls:
https://api.lightning.community/#genseed
https://api.lightning.community/#initwallet
https://api.lightning.community/#unlockwallet

@sangaman
Copy link
Collaborator

Karl is going to look into how we can generate an ethereum address based on a seed (which does not seem to be a built in feature of geth but which is done by open source projects like MetaMask and MyEtherWallet). This would require xud to communicate directly with geth most likely, unless Raiden exposes API calls that will do this for us (as well as allowing us to unlock encrypted ethereum keys).

The plan is still to have xud prompt for a password when it starts up and attempt to unlock every lnd wallet (and eventually raiden/geth wallet) using that password. And if xud starts up and doesn't find an xud pubkey such that it has to create a new one, it will generate a seed (using any one of the lnd instances) and attempt to init wallets for every lnd client we have configured using that seed, and also prompt for a password and set that for every newly initialized wallet. That same seed will be used to derive the xud key and same password will be used to encrypt it.

We'll need to change the flow for initializing LndClients, since we can't call GetInfo on an lnd instance that is still locked or uninitialized.

@kilrau
Copy link
Contributor Author

kilrau commented May 14, 2019

https://github.com/iancoleman/bip39

@ghost ghost mentioned this issue May 22, 2019
Merged
sangaman added a commit that referenced this issue Jun 4, 2019
@sangaman
feat: xud master password
44645e4 
This is a major commit that introduces new functionality to encrypt the
xud node key with a password which can also be used to encrypt lnd and
(with a separate PR) Raiden.

A new config option `noencrypt` is added and for now defaults to `true`,
meaning that this functionality is off by default. This is to minimize
disruption with existing applications of xud. When `noencrypt` is true,
starting up xud occurs as it does before this PR.

When `noencrypt` is false, we first check if there is an existing node
key file saved to disk. If one exists, we wait to receive a new
`UnlockNode` call to provide us with a password. We use this password to
decrypt the node key file and to call `UnlockWallet` on each configured
lnd instance that is waiting to be unlocked.

If none is found, we wait to receive a new `CreateNode` call to provide
us with a password. We then attempt to call `GenSeed` on a configured
lnd instance to generate an aezeed 24 word mnemonic. We use this
mnemonic to generate our node key, and then encrypt that with our
password and save to disk. We then call `InitWallet` on each configured
lnd instance that is waiting to be unlocked, using the same mnemonic and
password from earlier steps.

As part of this PR, we introduce a new grpc `XudInitService` for calls
when xud is in a state of waiting for a password before it can complete
initialization. New `create` and `unlock` commands are added for
`xucli` as well.

This is a major step towards #912.
sangaman added a commit that referenced this issue Jun 4, 2019
@sangaman
feat: xud master password
f93366e 
This is a major commit that introduces new functionality to encrypt the
xud node key with a password which can also be used to encrypt lnd and
(with a separate PR) Raiden.

A new config option `noencrypt` is added and for now defaults to `true`,
meaning that this functionality is off by default. This is to minimize
disruption with existing applications of xud. When `noencrypt` is true,
starting up xud occurs as it does before this PR.

When `noencrypt` is false, we first check if there is an existing node
key file saved to disk. If one exists, we wait to receive a new
`UnlockNode` call to provide us with a password. We use this password to
decrypt the node key file and to call `UnlockWallet` on each configured
lnd instance that is waiting to be unlocked.

If none is found, we wait to receive a new `CreateNode` call to provide
us with a password. We then attempt to call `GenSeed` on a configured
lnd instance to generate an aezeed 24 word mnemonic. We use this
mnemonic to generate our node key, and then encrypt that with our
password and save to disk. We then call `InitWallet` on each configured
lnd instance that is waiting to be unlocked, using the same mnemonic and
password from earlier steps.

As part of this PR, we introduce a new grpc `XudInitService` for calls
when xud is in a state of waiting for a password before it can complete
initialization. New `create` and `unlock` commands are added for
`xucli` as well.

This is a major step towards #912.
@sangaman sangaman mentioned this issue Jun 4, 2019
Merged
sangaman added a commit that referenced this issue Jun 6, 2019
@sangaman
feat: xud master password
bc55ce0 
This is a major commit that introduces new functionality to encrypt the
xud node key with a password which can also be used to encrypt lnd and
(with a separate PR) Raiden.

A new config option `noencrypt` is added and for now defaults to `true`,
meaning that this functionality is off by default. This is to minimize
disruption with existing applications of xud. When `noencrypt` is true,
starting up xud occurs as it does before this PR.

When `noencrypt` is false, we first check if there is an existing node
key file saved to disk. If one exists, we wait to receive a new
`UnlockNode` call to provide us with a password. We use this password to
decrypt the node key file and to call `UnlockWallet` on each configured
lnd instance that is waiting to be unlocked.

If none is found, we wait to receive a new `CreateNode` call to provide
us with a password. We then attempt to call `GenSeed` on a configured
lnd instance to generate an aezeed 24 word mnemonic. We use this
mnemonic to generate our node key, and then encrypt that with our
password and save to disk. We then call `InitWallet` on each configured
lnd instance that is waiting to be unlocked, using the same mnemonic and
password from earlier steps.

As part of this PR, we introduce a new grpc `XudInitService` for calls
when xud is in a state of waiting for a password before it can complete
initialization. New `create` and `unlock` commands are added for
`xucli` as well.

This is a major step towards #912.
sangaman added a commit that referenced this issue Jun 6, 2019
@sangaman
feat: xud master password
cebedb1 
This is a major commit that introduces new functionality to encrypt the
xud node key with a password which can also be used to encrypt lnd and
(with a separate PR) Raiden.

A new config option `noencrypt` is added and for now defaults to `true`,
meaning that this functionality is off by default. This is to minimize
disruption with existing applications of xud. When `noencrypt` is true,
starting up xud occurs as it does before this PR.

When `noencrypt` is false, we first check if there is an existing node
key file saved to disk. If one exists, we wait to receive a new
`UnlockNode` call to provide us with a password. We use this password to
decrypt the node key file and to call `UnlockWallet` on each configured
lnd instance that is waiting to be unlocked.

If none is found, we wait to receive a new `CreateNode` call to provide
us with a password. We then attempt to call `GenSeed` on a configured
lnd instance to generate an aezeed 24 word mnemonic. We use this
mnemonic to generate our node key, and then encrypt that with our
password and save to disk. We then call `InitWallet` on each configured
lnd instance that is waiting to be unlocked, using the same mnemonic and
password from earlier steps.

As part of this PR, we introduce a new grpc `XudInitService` for calls
when xud is in a state of waiting for a password before it can complete
initialization. New `create` and `unlock` commands are added for
`xucli` as well.

This is a major step towards #912.
This was referenced Jun 10, 2019
Open
Closed
Closed
Closed
This was referenced Jun 10, 2019
Closed
Closed
@kilrau kilrau removed this from the 1.0.0-beta milestone Jun 11, 2019
@kilrau kilrau mentioned this issue Jun 11, 2019
Closed
16 tasks
@kilrau kilrau mentioned this issue Jun 11, 2019
Open
sangaman added a commit that referenced this issue Jun 18, 2019
@sangaman
feat: xud master password
6bfad02 
This is a major commit that introduces new functionality to encrypt the
xud node key with a password which can also be used to encrypt lnd and
(with a separate PR) Raiden.

A new config option `noencrypt` is added and for now defaults to `true`,
meaning that this functionality is off by default. This is to minimize
disruption with existing applications of xud. When `noencrypt` is true,
starting up xud occurs as it does before this PR.

When `noencrypt` is false, we first check if there is an existing node
key file saved to disk. If one exists, we wait to receive a new
`UnlockNode` call to provide us with a password. We use this password to
decrypt the node key file and to call `UnlockWallet` on each configured
lnd instance that is waiting to be unlocked.

If none is found, we wait to receive a new `CreateNode` call to provide
us with a password. We then attempt to call `GenSeed` on a configured
lnd instance to generate an aezeed 24 word mnemonic. We use this
mnemonic to generate our node key, and then encrypt that with our
password and save to disk. We then call `InitWallet` on each configured
lnd instance that is waiting to be unlocked, using the same mnemonic and
password from earlier steps.

As part of this PR, we introduce a new grpc `XudInitService` for calls
when xud is in a state of waiting for a password before it can complete
initialization. New `create` and `unlock` commands are added for
`xucli` as well.

This is a major step towards #912.
@kilrau
Copy link
Contributor Author

kilrau commented Jun 24, 2019

Closed by #1006

@kilrau kilrau closed this as completed Jun 24, 2019
@kilrau kilrau mentioned this issue Dec 5, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sangaman sangaman

Labels
configuration cryptography Issues related to encryption & signing packets or local data P1 top priority
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Lnd wallet api wrapper ExchangeUnion/xud
2 participants
@sangaman @kilrau