Do not derive Eth-DM Key from Ethereum Key #411
Conversation
|
Cc @arnetheduck |
content/docs/rfcs/20/README.md
Outdated
| To avoid Bob having to save an additional private key or recovery phrase for Eth-DM purposes, | ||
| we generate the Eth-DM keypair using Bob's Ethereum account. | ||
| This will allow Bob to recover his Eth-DM private key as long as he has access to his Ethereum private key. | ||
| First, Bob MUST generate a new Ethereum private key, `B'`. |
There was a problem hiding this comment.
I don't understand the point of this protocol anymore. More specifically, why is there still the link with Ethereum keys?
There was the (privacy related) discussion in the past in the original PR as to why it is called Eth-DM and why Ethereum keys are being used: #365 (review)
I understood that it was because of specific use cases related to assets on the account that is receiving end of the messages.
Now it is changed so that the receiving end (Bob) must use a newly generated key-pair, and not store assets there.
I get the point of privacy obviously, but that was the initial remark also.
There was a problem hiding this comment.
Reading your initial comment: #365 (review)
It could make sense to change from "Direct" to "Private" -> Ethereum Private Message -> Eth-PM.
You are write, it does not need to be Ethereum Key for the purpose of asymmetrical encryption of the messages. I got carried away, will correct.
There was a problem hiding this comment.
Thank you for the comment!
I am not clear on the issue you are highlighting. Please allow me to clarify few things so you can point me to the issue you are seeing.
I don't understand the point of this protocol anymore. More specifically, why is there still the link with Ethereum keys?
What link are you referring too?
The user story is still: As Alice, I want to be able to send a encrypted message to Bob. I only know Bob's Ethereum address. I am using a Web3 wallet.
Due to the limitation of Web3 API, it is not possible to:
- Extract the wallet public key.
- Extract the wallet private key.
- encrypt or decrypt messages using the wallet public or private key.
Because of this limitation, we need to generate a new key pair for encryption and decryption purposes, let's call it eth-dm keypair.
Initially, the eth-dm keypair was hackish-ly derived from the Ethereum account, this is being removed with this PR after @arnetheduck's feedback.
Because Alice only knows Bob's Ethereum address, then Bob needs someway to give his eth-dm public key to Alice, and prove that he is the owner of his Ethereum address. He signs his eth-dm public key with his Ethereum account and publishes it to the network
Thanks to that, Alice can retrieve his eth-dm public key and use it to encrypt her message.
Bob then decrypt the message using his eth-dm private key.
For convenience purposes, the Eth-DM key pair is a SECP256k1 keypair. I agree that the initial wording was confusing, please let me know if the latest update helps.
Also, if this explanation clarified the issue, can you please let me know what part is unclear in the spec?
There was the (privacy related) discussion in the past in the original PR as to why it is called Eth-DM and why Ethereum keys are being used: #365 (review)
Yes the privacy concerns still hold. See The Limitations section.
The aim here is to provide an example on how a given DApp could add encryption using js-waku, it is not to redo the work done by Status in terms of privacy.
I hope that one day we'll be able to ship a module that brings in the status chat protocol for dev to simply plug in to Status chats in their dApp, but this day is not today.
I understood that it was because of specific use cases related to assets on the account that is receiving end of the messages.
Yes, the user story is Alice wants to message Bob only knowing Bob's Ethereum address.
Now it is changed so that the receiving end (Bob) must use a newly generated key-pair, and not store assets there.
I hope the first section clarified.
Because we are restricted by Web3 API, Bob has no choice but generate a new keypair that the dAPP can have full control on.
Please note that Metamask provide an encryption/decryption API that I will look into and would allow Bob to not have to generate a new keypair.
I get the point of privacy obviously, but that was the initial remark also.
I hope my comments above helps. Please let me know if I am missing something.
Again, thank you for taking the time to review.
There was a problem hiding this comment.
What link are you referring too?
I meant just the fact that you use "Ethereum" keys, or rather, that you name it Ethereum / Eth-DM, while it are just secp256k1 key-pairs.
But, that was a misunderstanding on my side, as there is still an actual link that I missed, the signature as proof of account holder. See further down in this comment.
Because of this limitation, we need to generate a new key pair for encryption and decryption purposes, let's call it eth-dm keypair.
Initially, the eth-dm keypair was hackish-ly derived from the Ethereum account, this is being removed with this PR after @arnetheduck's feedback.
When you need to create a new key-pair, which has no link with your wallet (or at least, it doesn't need to as you are not allowed to use it for storing assets), I was curious as to why it is still called Eth-dm keypair, as it is simply a secp256k1 key-pair.
Originally this protocol was using the Ethereum root HD public key for being able to initiate communication. I have failed to follow-up the further development of this protocol, and blindly assumed that due to dropping most of that original development, and just generating a new key-pair, that this original link with the Ethereum account got dropped. I understand now that there is still the signature part that gets published over the network.
The aim here is to provide an example on how a given DApp could add encryption using js-waku, it is not to redo the work done by Status in terms of privacy.
Right, this use case was not evident for me from just the specification.
So this Ethereum account linkability is there to have an initial way of identification?
And then the user/DApp needs to listen on the published messages containing the public key + signature, so it can start from there.
This is rather different from what Status chat does, and thus not really the "simple, less privacy, example" equivalent. That should be made clear. It is a different use case.
There was a problem hiding this comment.
So this Ethereum account linkability is there to have an initial way of identification?
Yes
And then the user/DApp needs to listen on the published messages containing the public key + signature, so it can start from there.
Yes
This is rather different from what Status chat does, and thus not really the "simple, less privacy, example" equivalent. That should be made clear. It is a different use case.
I am not sure we want to flag all toy specs as "this is not used in Status Chat", especially when the spec already states
The main purpose of this specification is to demonstrate how Waku v2 can be used for direct messaging purposes.
In the current state, the protocol has privacy and features [limitations](#limitations), has not been audited
and hence is not fit for production usage.
We hope this can be an inspiration for developers wishing to build on top of Waku v2.
@oskarth, thoughts?
|
Please let me know your opinion on whether we should rename this to "Ethereum Private Message". |
@D4nte |
I believe |
|
I would like to merge this, implement #413 in js-waku, make it work with Eth-DM and then update this spec again. Also, Eth-DM now behaves at this PR so I'd prefer to keep code and spec align by merging the present PR. |
|
I personally don't really want to spend time reviewing a PR related to crypto that doesn't build in our current best understanding of how it works or should work. I'm not going to block merge, but I don't know who wants to approve it when it is still probably wrong? |
No worries. Closing until eth-dm uses 26/WAKU-PAYLOAD. |
No description provided.