From f502778edbb102309f165def2980b80da47a77ca Mon Sep 17 00:00:00 2001 From: Andrea Franz Date: Wed, 1 Aug 2018 15:49:38 +0200 Subject: [PATCH] add initial description of idea 292 --- ...92-decouple-whisper-key-from-wallet-key.md | 177 ++++++++++++++++++ ...yz-decouple-whisper-key-from-wallet-key.md | 134 ------------- 2 files changed, 177 insertions(+), 134 deletions(-) create mode 100644 ideas/292-decouple-whisper-key-from-wallet-key.md delete mode 100644 ideas/xyz-decouple-whisper-key-from-wallet-key.md diff --git a/ideas/292-decouple-whisper-key-from-wallet-key.md b/ideas/292-decouple-whisper-key-from-wallet-key.md new file mode 100644 index 0000000..e45ac42 --- /dev/null +++ b/ideas/292-decouple-whisper-key-from-wallet-key.md @@ -0,0 +1,177 @@ +--- +id: 292-decouple-whisper-wallet-keys +title: Decouple whisper key from wallet key +status: draft +created: 2018-08-01 +category: core +lead-contributor: pilu (Andrea Franz) +contributors: + - cammellos +exit-criteria: no +success-metrics: no +clear-roles: no +future-iteration: no +roles-needed: + - QA + - PM + - UXR + - Clojure dev + - Go dev + - Designer + - Community +okrs: + - + - +--- + +## Preamble + +Idea: 292 +Title: Decouple whisper key from wallet key +Status: Draft +Created: 2018-08-01 + +## Summary + +For security and privacy reasons, we want to decouple the whisper key from the wallet key, so that users don't expose their Ethereum address while chatting in one-to-one and public chats. + +## Swarm Participants + +> Here all roles in swarm are defined and filled, one of the contributors should +> responsibility of the Idea as Lead. +> +> Lead Contributor is the Owner of the Idea. If required, they can get support +> from a PM, but should be responsible for end to end execution of the Idea. +> This includes ensuring appropriate resources are allocated, setting realistic +> timelines and milestones, and any post-launch metrics or bug fixes that are +> attributed to the Idea +> +> A swarm requires at minimum 3 contributors. For user-facing swarms +> PM/UX(R)/Eng functions have to be present. +> +> For swarms lead by core contributors, swarm lead is evaluator by default. +> +> 'Contributor' should be replaced with a descriptive role type. + +- Lead Contributor: [@pilu](https://github.com/pilu) +- Contributor: [@cammellos](https://github.com/cammellos) +- Evaluator (defaults to lead contributor): +- Contributor: +- Contributor: +- QA: +- PM (required for user-facing): +- UX(R) (required for user-facing swarms): + +## Product Overview + +In the current implementation, the same key pair is used for the whisper identity and the wallet. +The Status contact code is an uncompressed public key, and users share it with other people to be contacted. +In public chats, anyone can see the public key of a user by clicking on the avatar near the message. + +### Problem + +Since the whisper key pair is the same that we use for the wallet, it means that from the Status contact code, anyone can derive the wallet address and easily check a user's balance and transaction history. +Any user with a fair amount of value in their wallet can be target of phishing attacks, especially in public chats where any malicious user can track the wallets of all the active users. + +### Technical solution + +Status already implements a Hierarchical Deterministic wallet (HD Wallet) that allows us to derive multiple determinist keys from the same 12 mnemonic words. +For the wallet keys, we can continue to use the current derivation path, which is the one described by BIP44: `m/44'/60'/0'/0/0`. +We can then extend the key store structure to have an additional key used for the whisper identity and derived with a different derivation path that needs to be decided. + +### Changes in the chat/wallet flow + +In the current implementation, users can send ETH/SNT via the chat without asking the wallet address of the recipient, since it can be easily derived from the chat contact code, which is the public key. +If we add a different key for the chat/whisper identity, we need to implement a protocol such that user A need to request the address of user B before being able to start a transaction. User B can decide to approve the request and reveal or not the wallet address. + +### Compatibility + +The key pair used for the wallet will remain the same, so the wallet address won't change. + +The chat contact will change so after the upgrade, users will need to exchange their contact again to be able to chat. + +### Problems to solve for old clients + +1 - user A is using an old client +2 - user B is using a new client +3 - user A is chatting with user B and sends a transaction from the chat +4 - the transaction from the old client will be sent to the address derived from the chat contact code of user B +5 - user B won't see the transaction in the wallet because the wallet address is derived from a different key. + +(funds are not really lost since the chat key is still a valid ethereum key) + +### User Stories + +TODO + +> What user stories are you solving? + +### Requirements & Dependencies + +TODO + +> Are there bugs or feature requests in other repositories that are part of this +> Idea? + +### Security and Privacy Implications + +TODO + +> If the security and privacy implications of the idea are non-trivial, +> elaborate on the problem space and a plan for resolving it here. + +## Dates + +> Description of deliverables at a given date, for example each Town Hall (default). +> Add more iterations as required. +> +> Evaluator accepts responsbility to checkin at Goal dates, forces discussion to +> continue implementation or recommend disband and post-mortem. +> +> Upcoming Town Halls this quarter: +> 2018-04-23, 2018-05-07, 2018-05-21, 2018-06-04, 2018-06-18 + +### Minimum Viable Product + +TODO + +> Mandatory, completes the Idea in the fastest route possible, can be hacky, +> needed to feel progress. See https://imgur.com/a/HVlw3 + +Goal Date: + +Description: + +### Iteration 1 + +Goal Date: + +Description: + +## Success Metrics + +TODO + +> Assuming the idea ships, what would success look like? What are the most +> important metrics that you would move? +> +> Example: Onboarding conversion rate. Target >30% full funnel + +## Exit criteria + +TODO + +> Example: Launch new onboarding UI flow + +## Supporting Role Communication + +TODO + +> Once Requirements and Goals are fleshed out, then it should be communicated to +> supporting organelles if required + +## Copyright + +Copyright and related rights waived +via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + diff --git a/ideas/xyz-decouple-whisper-key-from-wallet-key.md b/ideas/xyz-decouple-whisper-key-from-wallet-key.md deleted file mode 100644 index 00a4cb8..0000000 --- a/ideas/xyz-decouple-whisper-key-from-wallet-key.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -id: 000-template -title: Swarm Template -status: draft -created: YYYY-MM-DD -category: core -lead-contributor: -contributors: - - - - - - -exit-criteria: no -success-metrics: no -clear-roles: no -future-iteration: no -roles-needed: - - QA - - PM - - UXR - - Clojure dev - - Go dev - - Contracts dev - - Designer - - Community -okrs: - - - - ---- - -## Preamble - - Idea: - Title: - Status: <Draft | In Progress | Closed > - Created: <date created on, in ISO 8601 (yyyy-mm-dd) format> - Requires (*optional): <Idea number(s)> - Replaces (*optional): <Idea number(s)> - -## Summary - -> "If you can't explain it simply, you don't understand it well enough." Provide -> a simplified and layman-accessible explanation of the Idea. - -## Swarm Participants - -> Here all roles in swarm are defined and filled, one of the contributors should -> responsibility of the Idea as Lead. -> -> Lead Contributor is the Owner of the Idea. If required, they can get support -> from a PM, but should be responsible for end to end execution of the Idea. -> This includes ensuring appropriate resources are allocated, setting realistic -> timelines and milestones, and any post-launch metrics or bug fixes that are -> attributed to the Idea -> -> A swarm requires at minimum 3 contributors. For user-facing swarms -> PM/UX(R)/Eng functions have to be present. -> -> For swarms lead by core contributors, swarm lead is evaluator by default. -> -> 'Contributor' should be replaced with a descriptive role type. - -- Lead Contributor: -- Evaluator (defaults to lead contributor): -- Contributor: -- Contributor: -- QA: -- PM (required for user-facing): -- UX(R) (required for user-facing swarms): - -## Product Overview - -> A short (~200 word) description and motivation of the Idea. Without clear -> explanation the Idea should not proceed. - -### User Stories - -> What user stories are you solving? - -### Requirements & Dependencies - -> Are there bugs or feature requests in other repositories that are part of this -> Idea? - -### Security and Privacy Implications - -> If the security and privacy implications of the idea are non-trivial, -> elaborate on the problem space and a plan for resolving it here. - -## Dates - -> Description of deliverables at a given date, for example each Town Hall (default). -> Add more iterations as required. -> -> Evaluator accepts responsbility to checkin at Goal dates, forces discussion to -> continue implementation or recommend disband and post-mortem. -> -> Upcoming Town Halls this quarter: -> 2018-04-23, 2018-05-07, 2018-05-21, 2018-06-04, 2018-06-18 - -### Minimum Viable Product - -> Mandatory, completes the Idea in the fastest route possible, can be hacky, -> needed to feel progress. See https://imgur.com/a/HVlw3 - -Goal Date: - -Description: - -### Iteration 1 - -Goal Date: - -Description: - -## Success Metrics - -> Assuming the idea ships, what would success look like? What are the most -> important metrics that you would move? -> -> Example: Onboarding conversion rate. Target >30% full funnel - -## Exit criteria - -> Example: Launch new onboarding UI flow - -## Supporting Role Communication - -> Once Requirements and Goals are fleshed out, then it should be communicated to -> supporting organelles if required - -## Copyright - -Copyright and related rights waived -via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).