Skip to content
This repository has been archived by the owner on Jun 14, 2024. It is now read-only.

Do not derive Eth-DM Key from Ethereum Key #411

Closed
wants to merge 2 commits into from
Closed

Do not derive Eth-DM Key from Ethereum Key #411

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
51948f8
Do not derive Eth-DM Key from Ethereum Key
D4nte Jun 29, 2021
c443f18
Attempt to clarify cryptography used
D4nte Jun 30, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 4 additions & 18 deletions content/docs/rfcs/20/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,26 +63,12 @@ or verify her identity.

## Eth-DM Key Generation

First, Bob needs to generate an Eth-DM keypair.
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'`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@kdeme kdeme Jun 30, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

This private key will be used as the Eth-DM encryption key.

This key pair is like any other Ethereum key pair apart that it will not be used to store assets.

To generate his Eth-DM keypair, Bob MUST use his Ethereum private key 'b' to sign the Eth-DM salt message:
`Salt for Eth-Dm, do not share a signature of this message or others could decrypt your messages`.

The resulting signature 's' is then concatenated with itself once and hashed using keccak256.
The resulting hash is Bob's Eth-DM private key `b'`:

```
b' = keccak256(s + s)
```

The signature process is as per the current Ethereum best practice:

1. Convert the salt message to a byte array using utf-8 encoding,
2. Use [`eth_sign`](https://eth.wiki/json-rpc/API#eth_sign) Ethereum JSON-RPC command or equivalent.
The application MAY provide a way for the user to securely backup this key pair for future usage.

# Eth-DM Public Key Broadcast

Expand Down