Musings on Key Management (aka 'Whisper Decoupling')

Posting here related discussions about unique dApps keypair paths scheme happening around EIP1775 and EIP1581

See discussion here EIP ERC App Keys: application specific wallet accounts - EIPs - Fellowship of Ethereum Magicians
and discussion here
and the EIP itself

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 .

ERC1581 vs ERC1775


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”
  • is exported from keycard if login is saved/biometric


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
  • cannot be exported from keycard


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
  • is exported from keycard if login is saved/biometric

Must be 1581+1775 (1775 in top of 1581), not 1775+1581 (1581 in top of 1775). Because if 1775+1581, for every new dapp asking key then keycard/password will need to be given, even if is a nonwallet key. In case of 1581+1775 , Status already know the 1581 key, so it can derive the dapp specific key without asking keycard/password.



cc @andre

1 Like

This is a great update on the current state @ricardo3!

About 1775, how would funding a dapp specific Ethereum address work? Do you see any ways to allow transactions using this address to draw funds from another account?

Ideally I imagine these addresses to be generated on the fly when using a dapp. Basically offering the user to choose from a list to use

  • an existing account (possibly defaulting to 'last used with this dapp)
  • a new account

Where ‘a new account’ is most likely to be dapp specific as it’s the only way to know it hasn’t been used anywhere else. The issue then being that this new account doesn’t hold funds.

The alternative of first creating and funding an account before sharing that address would rely on the user be hygienic in creating dedicated accounts for dapps they might use, which I don’t see likely to happen.

1 Like

this does not answer @hester question which is a hell of a good question, but I encourage those who have not to check metamask mobile (released a month ago) UX

The UX to manage mutliaccount and in particular to let know the user, while in the browser, which account he’s using, and if he’s got assets on this account is really clear and simple.

1 Like

What about use “Themes” for different accounts or “personas”? We can make that each new account gets a random theme, and the browser gets this theme whenever user is exposing that account.
Not sure of this one.

The solution I see would be:

  • Each tab is a session (unique authorization/storage per domain)
  • New tab always have clean storage/cookies and no authorizations
  • Tabs can be “archived” or “removed”
  • Sessions always show the IDs that are authorized in a visible place (maybe next to history arrows and chat button)
  • When changing authorizations user is warning that mixing accounts might lead to privacy leak
  • Tabs can have their own “homepage”

Therefore this creates an way of user setting up a new session for each dapp, and archiving or deleting old ones, just like users would do with apps installed from a store.

I’ll be happy in discussing further how we can make a better DApp experience for users and developers.

It’s like everything always used “privacy mode”, and we can totally do that because we dont need anymore cookies to login, because for dapps login is digital signature coming from user identity. However cookies and local storage of browser might still be used for dapps, e.g. to save information about secrets on ENS bid-reveal, e.g. cryptokitties uses cookies to dont request signature everytime again, so server knows user is owner of one address