Title: Non_wallet_usage_of_keys_derived_from_BIP_32_trees
Category: Web

Author: bitgamma
Date: 2018-11-06T11:30:14.924Z

Software interacting with the blockchain, including wallets, do not only revolve around pure asset transfer transactions but might have additional functionalities. In the case of Status that would be chat, but it can be anything like authentication, file encryption, etc. Using keys under the BIP32 tree for these purposes would allow the user to migrate the whole identity from one software to the other using the BIP39 mnemonic alone, since everything else would be derived from there.
We plan to propose a short EIP (ERC maybe?) to formalize a key subtree which would be reserved for this. I have written a draft at https://notes.status.im/UPVhoAKjT0irxIPjs5x8IA and would like to have some feedback on this before submitting it.
A short summary is that we define a separate (from the usual 44’) subtree under master and then have a key type and a key index. The format would thus be m/XXXX’/key_type’/key_index. The XXXX would be the EIP/ERC number.
The list of allocated key type must be maintained in a way similar to the allocated coin types for BIP44.

Author: ligi
Date: 2018-11-10T22:37:32.093Z

Great idea! Just missing in the purpose section of the notes the thing you mention in this post:

The format would thus be m/XXXX’/key_type’/key_index. The XXXX would be the EIP/ERC number.

Author: bitgamma
Date: 2018-11-13T06:46:39.132Z

Thanks for the feedback! I have added that explaination in the document as well now.

Author: bitgamma
Date: 2019-01-30T09:22:14.849Z

Another update to the draft, regarding the key_index field has been posted https://eips.ethereum.org/EIPS/eip-1581

Author: 3esmit
Date: 2019-10-02T20:50:46.216Z

I want to just give a breakdown to clarify things. Seems like some confusion around EIP 1775, and also I suggest that we have a ERC1581+ERC1775 .
@danfinlay @Bunjin
ERC1581 vs ERC1775
ERC1581:
Fix the weakness of using the same public key for ethereum address and chat key.

“non wallet” public key

path m/43'/60'/1581'/ [key type]' / [key_index]

dapps can be authorized to view “chat identity” public key
dapps can be authorized to sign messages at will “chat identity”

ERC1775:
Fix the privacy weakness of reusing the same ethereum address for several dapps.

dapp specific ethereum address

path m/43'/60'/1775'/ [persona path]' / [application uniquely assigned path]' / [app's custom subpath]

dapps can be authorized to view dapp specific eth address
authorized dapps can request signatures for each transaction or ERC191 message

ERC1581+ERC1775:
Fix the privacy weakness of reusing the same public key for several dapps.

dapp specific “non wallet” public key

path m/43'/60'/1581'/1775'/ [persona path]' / [application uniquely assigned path]' / [app's custom subpath]

dapps can be authorized to view “dapp specific chat identity” public key
dapps can be authorized to sign messages at will

Author: fubuloubu
Date: 2020-05-08T14:17:58.799Z

Similar proposal: Extensible crypto for wallets

Author: fryorcraken
Date: 2021-09-09T05:49:48.875Z

Replied mirror in https://github.com/status-im/js-waku/issues/73#issuecomment-915782020 with links because I am not allowed more than 2 links per post as a new user
The current proposed API in EIP1775:
const appKey = await provider.send({
  method: 'wallet_getAppKeyForAccount',
  params: [address1]
});

Implies that access to a dApp specific private key is given to the dApp. I believe this is not ideal as it means the dApp now needs to properly handle the private key.
I agree with you that it’d be ideal if the dApp could instead request signing/decrypting messages to the wallet, using the dedicated dApp key. Potentially using a permission based design such as EIP-2255.
However, the challenge is that the decryption/signature method provided by a wallet may not fit the dApp needs.
In regards of the signature scheme, EIP-712 could be a one-fit-all candidate.
However, in terms of decryption, we can see that various schemes are used in the ecosystem and it may be difficult to pick one:

Metamask uses X25519_XSalsa20_Poly1305.
Geth uses ECIES
Waku, originating from Whisper/Geth, also uses ECIES


Another solution would be to provide a generic API that supports several encryption. An idea would be to use CryptoSubtle as the API reference and assume that in the Browser world, some of the encryption supported by Crypto Subtle should be supported by the Wallet API.