70/eth secpm #626

ramsesfv · 2023-10-18T15:30:39Z

No description provided.

kaiserd · 2023-10-18T15:58:09Z

ETHCHAT.md

@@ -0,0 +1,178 @@
+---
+slug: 70
+title: 70/WAKU2-ETHCHAT


This would not be specific to Waku. It should be transport agnostic.
We could name it 70/ETH-SECPM. Wdyt?

rymnc · 2023-10-20T10:21:57Z

ETHCHAT.md

+
+## 1-to-1 version
+
+In order to extend the protocol to a group chat, one uses an ADKG to replace the X3DH step in the previous combination X3DH + Double Ratchet.


since this is the first reference of ADKG, maybe an expansion would be good here!

Yes, please.

rymnc · 2023-10-20T10:22:57Z

ETHCHAT.md

+The shared key can be then used in any symmetric encryption scheme, such as AES256.
+
+
+# Implementation Suggestions


Can we also have a section on privacy/security considerations?

kaiserd

Thank you very much :). My comments are in-line.
Let's also discuss this in today's meeting.

ETHCHAT.md

kaiserd · 2023-10-23T07:42:50Z

ETHCHAT.md

+
+## Considerations on the X3DH initialization
+This scheme requires working on specific elliptic curves which differ from those used by Ethereum. 
+To be precise, Ethereum makes use of the curve secp256k1, whereas X3DH requires either X25519 or X448. For the sake of simplicity we will assume the selected curve is X25519.


In this specification we should chose a specific curve (not assume), or explicitly allow for negotiation / leave the curve generic. I'd choose a fixed curve to avoid the negotiation overhead (in noise fashion).

Yes, I also prefer specifying the curve.

ETHCHAT.md

kaiserd · 2023-10-23T07:44:54Z

ETHCHAT.md

+
+$$ IK = ik \cdot G $$
+
+The scheme X3DH will also require the generation of a public key SPK which will be generated repeating the above process: one takes $spk \in \mathbb{Z}_p$ a secret random integer and computes:


Why the S in SPK. Should briefly mention that here.

I added a few more lines on that.

ETHCHAT.md

rymnc

Nice improvements! Left a few comments re: sembr

ETHCHAT.md

rymnc · 2023-10-25T04:47:34Z

ETHCHAT.md

+SPK is a public key generated and stored at medium-term. It is called a signed prekey because Bob also needs to store a public key certificate of SPK using IK. 
+Both signed prekey and the certificate must undergo periodic replacement, a process that entails the generation of a fresh signed prekey. 
+After replacing the key, Bob keeps the old private key of SPK for a short time, in order to be able to decrypt delayed messages. 
+It is important that he deletes the old keys after that short period of time. This action is pivotal for ensuring forward secrecy, as these keys are integral for recalculating the shared secret employed in decrypting historical messages.


Suggested change

It is important that he deletes the old keys after that short period of time. This action is pivotal for ensuring forward secrecy, as these keys are integral for recalculating the shared secret employed in decrypting historical messages.

It is important that he deletes the old keys after that short period of time.

This action is pivotal for ensuring forward secrecy,

as these keys are integral for recalculating the shared secret employed in decrypting historical messages.

Are we specifying the "short period of time" in recommendations somewhere?

Nope to be honest. Let me have a thought on that.

Made some amendments on this topic. Signal's documentation requires "frequent updating" of SPKs, so I assume that it depends on the implementation. The most important fact, and I included it in the RFC, is that one should not reuse SPK.

ETHCHAT.md

rymnc · 2023-10-25T04:53:18Z

ETHCHAT.md

@@ -0,0 +1,201 @@
+---


this file should go into content/docs/rfcs/70 as README.md, and create a corresponding index in content/menu/index.md

kaiserd

Thank you :).
See comments in-line.

ETHCHAT.md

kaiserd · 2023-10-30T08:21:02Z

ETHCHAT.md

+
+## Using X3DH in Double Ratchet
+
+According to the specifications  [https://signal.org/docs/specifications/doubleratchet/](https://signal.org/docs/specifications/doubleratchet/) 


Suggested change

According to the specifications [https://signal.org/docs/specifications/doubleratchet/](https://signal.org/docs/specifications/doubleratchet/)

According to the [signal specifications](https://signal.org/docs/specifications/doubleratchet/)

All links should be like this: showing an expressive name, hiding the URL.
You can check other RFCs for that. We can also go over this in the upcoming meeting.

ETHCHAT.md

kaiserd · 2023-10-30T08:23:25Z

ETHCHAT.md

+
+Once this initialization has been set, Alice and Bob can start exchanging messages with forward secrecy and authentication.
+
+## Considerations with regards to the Noise protocol


Suggested change

## Considerations with regards to the Noise protocol

## Specification as a Noise protocol

kaiserd · 2023-10-30T08:27:18Z

ETHCHAT.md

+
+When it comes to the KDF ratchet, 
+and the associated encryption process does not correspond exactly to any particular Noise pattern,
+but one observes that KDF and encryption/decryption functions considered by the double ratchet protocol are included in Noise: 


This sentence is gramatically odd. It is not obvious what is meant here.
Please rephrase 🙏

I simplified the explanations.

ETHCHAT.md

kaiserd · 2023-10-30T08:48:21Z

ETHCHAT.md

+
+Using the above approach leads to a situation where a group of users can set a group for 1-to-1 messages, meaning that any group member external to a communication between any other two members will not be able to read the contents of the messages.
+
+An approach to generalize this situation to the setting of a group of users exchanging messages without any kind of restriction is using asynchornous ratcheting trees such ([https://eprint.iacr.org/2017/666](https://eprint.iacr.org/2017/666)) where a group of people can derive a shared secret key even in the event of if no two users are ever online at the same time. 


Suggested change

An approach to generalize this situation to the setting of a group of users exchanging messages without any kind of restriction is using asynchornous ratcheting trees such ([https://eprint.iacr.org/2017/666](https://eprint.iacr.org/2017/666)) where a group of people can derive a shared secret key even in the event of if no two users are ever online at the same time.

An approach to generalize this situation to the setting of a group of users exchanging messages without any kind of restriction is using asynchornous ratcheting trees such as ([https://eprint.iacr.org/2017/666](https://eprint.iacr.org/2017/666)) where a group of people can derive a shared secret key even in the event of if no two users are ever online at the same time.

ETHCHAT.md

kaiserd · 2023-10-30T08:51:56Z

ETHCHAT.md

+-   The DKG suggested makes assumes the existence of a PKI. In case of requiring removing such assumption, one can replace the VSS scheme with the Alhaddad, Varia, and Zhang’s proposal ([https://eprint.iacr.org/2021/118](https://eprint.iacr.org/2021/118)) at the price of increasing the complexity.
+-   The output of the DKG may be an integer (modulo a prime), meaning that one should apply a KDF to that output in order to obtain a result which could be used as an input for the double ratchet.
+-   This approach share similarities with Farcaster’s point of view ([https://github.com/farcasterxyz/protocol/discussions/99](https://github.com/farcasterxyz/protocol/discussions/99)).
+


This are not really implementation considerations and should be part of the spec above.

kaiserd · 2023-10-30T08:53:20Z

ETHCHAT.md

+- https://github.com/sourav1547/htadkg
+- https://github.com/farcasterxyz/protocol/discussions/99
+
+


All links should be of the format:
20/TOY-ETH-PM

see comment above.

seugu · 2023-11-01T08:20:00Z

ETHCHAT.md

+-   XEdDSA for digital signatures involved in the X3DH key generation.
+-   SHA256 for hashing and the generation of HMACs.
+-   AES256-CBC for the encryption/decryption of messages.
+


Are these algorithms strict, or is it possible to choose one like a cipher suite like in TLS?

They would be fixed.
Noise allows you to instantiate specific handshake protocols, with a fixed cipher suite.
The choosing happens in the design phase of the respective protocol.

seugu · 2023-11-01T08:23:27Z

ETHCHAT.md

+
+Before sending an initial message to Bob, Alice will generate an AD vector as described in the documentation:
+
+$$ AD = Encode(IK_A)|| Encode(IK_B) $$


Should we specify what is the Encoding function?

Comment added

seugu · 2023-11-01T08:26:32Z

ETHCHAT.md

+
+$$ AD = Encode(IK_A)|| Encode(IK_B) $$
+
+Alice will also need to generate ephemeral key pairs (ek, EK) following the above mechanisms, that is: ek is a random integer modulo p, and EK is the associated public key obtained from the produc


Do we need to explain that modulo p is the modulo of X448?

Would be even better to make that explicit :). Yes.

seugu · 2023-11-01T08:27:39Z

ETHCHAT.md

+
+$$ AD = Encode(IK_A)|| Encode(IK_B) $$
+
+Alice will also need to generate ephemeral key pairs (ek, EK) following the above mechanisms, that is: ek is a random integer modulo p, and EK is the associated public key obtained from the produc


Suggested change

Alice will also need to generate ephemeral key pairs (ek, EK) following the above mechanisms, that is: ek is a random integer modulo p, and EK is the associated public key obtained from the produc

Alice will also need to generate ephemeral key pairs (ek, EK) following the above mechanisms, that is: ek is a random integer modulo p, and EK is the associated public key obtained from the product

seugu · 2023-11-01T08:29:58Z

ETHCHAT.md

+This function will have inputs the secret key of the user running the function, and the public key of the external user. 
+Receiver and sender MUST generate valid key pairs, i.e. points of the X448, using the Noise function GENERATE_KEYPAIR().
+
+The KDF ratchet and the associated encryption protocols used by the double ratchet are also included by the Noise framework: 


Do we need to write the long form of KDF as a Key Derivation Function?

ETHCHAT.md

kaiserd · 2023-11-01T15:33:47Z

Thank you @rymnc and @seugu for the feedback :).

kaiserd · 2023-11-01T15:36:05Z

@ramsesfv Currently, this PR adds a file names ETHCHAT.md to the root folder.
The file should be called REAME.md and live in a directory called 71 within this directory: https://github.com/vacp2p/rfc/tree/70/ETH-SECPM/content/docs/rfcs

You can look at the other RFCs as an example.

(Please move the file within this pull request and do not open a new one.)

content/docs/rfcs/71/README.md

kaiserd

Thank you for the continued work on this RFC :).
There is still a lot to develop here, in specific going more towards a Noise protocol useing the proper noise primitives as discussed.
However, for a first raw version, this is good to merge (the commits have to be signed for that to work),
and can serve as a basis for discussion.

Let's open a follow up draft PR right away to continue improving this spec.

Raw version of the RFC on the Ethereum messaging service

Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>

Co-authored-by: Aaryamann Challani <43716372+rymnc@users.noreply.github.com>

Co-authored-by: seugu <99656002+seugu@users.noreply.github.com>

Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com>

Signed-off-by: ksr <kaiserd@users.noreply.github.com>

fryorcraken · 2023-11-08T03:29:20Z