AtHeartEngineer/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-07 23:04:09 -05:00
Code Issues Packages Projects Releases Wiki Activity

ETH-SECPM-DEC (#28)

Browse Source 
Co-authored-by: Jimmy Debe <91767824+jimstir@users.noreply.github.com>
Co-authored-by: Ekaterina Broslavskaya <seemenkina@gmail.com>
Co-authored-by: seugu <99656002+seugu@users.noreply.github.com>
This commit is contained in:
ramsesfv
2024-05-27 12:15:46 +02:00
committed by GitHub
parent e234e9d5a3
commit 7e3a625812
1 changed files with 732 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

732
vac/raw/decentralized-messaging-ethereum.md Normal file
View File

@@ -0,0 +1,732 @@
---
title: VAC-DECENTRALIZED-MESSAGING-ETHEREUM
name: Decentralized Key and Session Setup for Secure Messaging over Ethereum
status: raw
category: informational
editor: Ramses Fernandez-Valencia <ramses@status.im>
contributors:
---
## Abstract
This document introduces a decentralized group messaging protocol using Ethereum adresses as identifiers.
It is based in the proposal [DCGKA](https://eprint.iacr.org/2020/1281) by Weidner et al.
It includes also approximations to overcome limitations related to using PKI and the multi-device setting.
## Motivation
The need for secure communications has become paramount.
Traditional centralized messaging protocols are susceptible to various security threats,
including unauthorized access, data breaches, and single points of failure.
Therefore a decentralized approach to secure communication becomes increasingly relevant,
offering a robust solution to address these challenges.
Secure messaging protocols used should have the following key features:
1. **Asynchronous Messaging:** Users can send messages even if the recipients are not online at the moment.
2. **Resilience to Compromise:** If a user's security is compromised,
the protocol ensures that previous messages remain secure through forward secrecy (FS).
This means that messages sent before the compromise cannot be decrypted by adversaries.
Additionally, the protocol maintains post-compromise security (PCS) by regularly updating keys,
making it difficult for adversaries to decrypt future communication.
3. **Dynamic Group Management:** Users can easily add or remove group members at any time,
reflecting the flexible nature of communication within the app.
In this field, there exists a *trilemma*, similar to what one observes in blockchain,
involving three key aspects:
1. security,
2. scalability, and
3. decentralization.
For instance, protocols like the [MLS](https://messaginglayersecurity.rocks) perform well in terms of scalability and security.
However, they falls short in decentralization.
Newer studies such as [CoCoa](https://eprint.iacr.org/2022/251) improve features related to security and scalability,
but they still rely on servers, which may not be fully trusted though they are necessary.
On the other hand,
older studies like [Causal TreeKEM](https://mattweidner.com/assets/pdf/acs-dissertation.pdf) exhibit decent scalability (logarithmic)
but lack forward secrecy and have weak post-compromise security (PCS).
The creators of [DCGKA](https://eprint.iacr.org/2020/1281) introduce a decentralized,
asynchronous secure group messaging protocol that supports dynamic groups.
This protocol operates effectively on various underlying networks without strict requirements on message ordering or latency.
It can be implemented in peer-to-peer or anonymity networks,
accommodating network partitions, high latency links, and disconnected operation seamlessly.
Notably, the protocol doesn't rely on servers or
a consensus protocol for its functionality.
This proposal provides end-to-end encryption with forward secrecy and post-compromise security,
even when multiple users concurrently modify the group state.
## Theory
### Protocol overview
This protocol makes use of ratchets to provide FS by encrypting each message with a different key.
In the figure one can see the ratchet for encrypting a sequence of messages.
The sender requires an initial update secret `I_1`, which is introduced in a PRG.
The PRG will produce two outputs, namely a symmetric key for AEAD encryption, and
a seed for the next ratchet state.
The associated data needed in the AEAD encryption includes the message index `i`.
The ciphertext `c_i` associated to message `m_i` is then broadcasted to all group members.
The next step requires deleting `I_1`, `k_i` and any old ratchet state.
After a period of time the sender may replace the ratchet state with new update secrets `I_2`, `I_3`, and so on.
To start a post-compromise security update,
a user creates a new random value known as a seed secret and
shares it with every other group member through a secure two-party channel.
Upon receiving the seed secret,
each group member uses it to calculate an update secret for both the sender's ratchet and their own.
Additionally, the recipient sends an unencrypted acknowledgment to the group confirming the update.
Every member who receives the acknowledgment updates not only the ratchet for the original sender but
also the ratchet for the sender of the acknowledgment.
Consequently, after sharing the seed secret through `n - 1` two-party messages and
confirming it with `n - 1` broadcast acknowledgments,
every group member has derived an update secret and updated their ratchet accordingly.
When removing a group member,
the user who initiates the removal conducts a post-compromise security update
by sending the update secret to all group members except the one being removed.
To add a new group member,
each existing group member shares the necessary state with the new user,
enabling them to derive their future update secrets.
Since group members may receive messages in various orders,
it's important to ensure that each sender's ratchet is updated consistently
with the same sequence of update secrets at each group member.
The network protocol used in this scheme ensures that messages from the same sender are processed in the order they were sent.
### Components of the protocol
This protocol relies in 3 components:
authenticated causal broadcast (ACB),
decentralized group membership (DGM) and
2-party secure messaging (2SM).
#### Authenticated causal broadcast
A causal order is a partial order relation `<` on messages.
Two messages `m_1` and `m_2` are causally ordered, or
`m_1` causally precedes `m_2`
(denoted by `m_1 < m_2`), if one of the following contiditions hold:
1. `m_1` and `m_2` were sent by the same group member, and `m_1` was sent before `m_2`.
2. `m_2` was sent by a group member U, and `m_1` was received and
processed by `U` before sending `m_2`.
3. There exists `m_3` such that `m_1 < m_3` and `m_3 < m_2`.
Causal broadcast requires that before processing `m`,
a group member must process all preceding messages `{m' | m' < m}`.
The causal broadcast module used in this protocol authenticates the sender of each message,
as well as its causal ordering metadata, using a digital signature under the sender’s identity key.
This prevents a passive adversary from impersonating users or affecting causally ordered delivery.
#### Decentralized group membership
This protocol assumes the existence of a decentralized group membership function (denoted as DGM)
that takes a set of membership change messages and their causal order relantionships,
and returns the current set of group members’ IDs.
It needs to be deterministic and depend only on causal order, and not exact order.
#### 2-party secure messaging (2SM)
This protocol makes use of bidirectional 2-party secure messaging schemes,
which consist of 3 algorithms: `2SM-Init`, `2SM-Send` and `2SM-Receive`.
##### 2SM-Init
This function takes two IDs as inputs:
`ID1` representing the local user and `ID2` representing the other party.
It returns an initial protocol state `sigma`.
The 2SM protocol relies on a Public Key Infrastructure (PKI) or
a key server to map these IDs to their corresponding public keys.
In practice, the PKI should incorporate ephemeral prekeys.
This allows users to send messages to a new group member,
even if that member is currently offline.
##### 2SM-Send
This function takes a state `sigma` and a plaintext `m` as inputs, and
returns a new state `sigma’` and a ciphertext `c`.
##### 2SM-Receive
This function takes a state `sigma` and a ciphertext `c`, and
returns a new state `sigma’` and a plaintext `m`.
#### 2SM Syntax
The variable `sigma` denotes the state consisting in the variables below:
```
sigma.mySks[0] = sk
sigma.nextIndex = 1
sigma.receivedSk = empty_string
sigma.otherPk = pk`<br>
sigma.otherPksender = “other”
sigma.otherPkIndex = 0
```
#### 2SM-Init
On input a key pair `(sk, pk)`, this functions otuputs a state `sigma`.
#### 2SM-Send
This function encrypts the message `m` using `sigma.otherPk`,
which represents the other party’s current public key.
This key is determined based on the last public key generated for the other party or
the last public key received from the other party,
whichever is more recent.
`sigma.otherPkSender` is set to `me` in the former case and `other` in the latter case.
Metadata including `otherPkSender` and
`otherPkIndex` are included in the message to indicate which of the recipient’s public keys is being utilized.
Additionally, this function generates a new key pair for the local user,
storing the secret key in `sigma.mySks` and sending the public key.
Similarly, it generates a new key pair for the other party,
sending the secret key (encrypted) and storing the public key in `sigma.otherPk`.
```
sigma.mySks[sigma.nextIndex], myNewPk) = PKE-Gen()
(otherNewSk, otherNewPk) = PKE-Gen()
plaintext = (m, otherNewSk, sigma`.nextIndex, myNewPk)
msg = (PKE-Enc(sigma.otherPk, plaintext), sigma.otherPkSender, sigma.otherPkIndex)
sigma.nextIndex++
(sigma.otherPk, sigma.otherPkSender, sigma.otherPkIndex) = (otherNewPk, "me", empty_string)
return (sigma`, msg)
```
#### 2SM-Receive
This function utilizes the metadata of the message `c` to determine which secret key to utilize for decryption,
assigning it to `sk`.
If the secret key corresponds to one generated by ourselves,
that secret key along with all keys with lower index are deleted.
This deletion is indicated by `sigma.mySks[≤ keyIndex] = empty_string`.
Subsequently, the new public and secret keys contained in the message are stored.
```
(ciphertext, keySender, keyIndex) = c
if keySender = "other" then
sk = sigma.mySks[keyIndex]
sigma.mySks[≤ keyIndex] = empty_string
else sk = sigma.receivedSk
(m, sigma.receivedSk, sigma.otherPkIndex, sigma.otherPk) = PKE-Dec(sk, ciphertext)
sigma.otherPkSender = "other"
return (sigma, m)
```
### PKE Syntax
The required PKE that MUST be used is ElGamal with a 2048-bit modulus `p`.
#### Parameters
The following parameters must be used:
```
p = 308920927247127345254346920820166145569
g = 2
```
#### PKE-KGen
Each user `u` MUST do the following:
```
PKE-KGen():
a = randint(2, p-2)
pk = (p, g, g^a)
sk = a
return (pk, sk)
```
#### PKE-Enc
A user `v` encrypting a message `m` for `u` MUST follow these steps:
```
PKE-Enc(pk):
k = randint(2, p-2)
eta = g^k % p
delta = m * (g^a)^k % p
return ((eta, delta))
```
#### PKE-Dec
The user `u` recovers a message `m` from a ciphertext `c` by performing the following operations:
```
PKE-Dec(sk):
mu = eta^(p-1-sk) % p
return ((mu * delta) % p)
```
### DCGKA Syntax
#### Auxiliary functions
There exist 6 functions that are auxiliary for the rest of components of the protocol, namely:
#### init
This function takes an `ID` as input and returns its associated initial state, denoted by `gamma`:
```
gamma.myId = ID
gamma.mySeq = 0
gamma.history = empty
gamma.nextSeed = empty_string
gamma.2sm[·] = empty_string
gamma.memberSecret[·, ·, ·] = empty_string
gamma.ratchet[·] = empty_string
return (gamma)
```
#### encrypt-to
Upon reception of the recipient’s `ID` and a plaintext,
it encrypts a direct message for another group member.
Should it be the first message for a particular `ID`,
then the `2SM` protocol state is initialized and stored in `gamma.2sm[recipient.ID]`.
One then uses `2SM_Send` to encrypt the message and store the updated protocol in `gamma`.
```
if gamma.2sm[recipient_ID] = empty_string then
gamma.2sm[recipient_ID] = 2SM_Init(gamma.myID, recipient_ID)
(gamma.2sm[recipient_ID], ciphertext) = 2SM_Send(gamma.2sm[recipient_ID], plaintext)
return (gamma, ciphertext)
```
#### decrypt-from
After receiving the sender’s `ID` and a ciphertext,
it behaves as the reverse function of `encrypt-to` and has a similar initialization:
```
if gamma.2sm[sender_ID] = empty_string then
gamma.2sm[sender_ID] = 2SM_Init(gamma.myID, sender_ID)
(gamma.2sm[sender_ID], plaintext) = 2SM_Receive(gamma.2sm[sender_ID], ciphertext)
return (gamma, plaintext)
```
#### update-ratchet
This function generates the next update secret `I_update` for the group member `ID`.
The ratchet state is stored in `gamma.ratchet[ID]`.
It is required to use a HMAC-based key derivation function HKDF to combine the ratchet state with an input,
returning an update secret and a new ratchet state.
```
(updateSecret, gamma.ratchet[ID]) = HKDF(gamma.ratchet[ID], input)
return (gamma, updateSecret)
```
#### member-view
This function calculates the set of group members based on the most recent control message sent by the specified user `ID`.
It filters the group membership operations to include only those observed by the specified `ID`, and
then invokes the DGM function to generate the group membership.
```
ops = {m in gamma.history st. m was sent or acknowledged by ID}
return DGM(ops)
```
#### generate-seed
This functions generates a random bit string and
sends it encrypted to each member of the group using the `2SM` mechanism.
It returns the updated protocol state and
the set of direct messages (denoted as `dmsgs`) to send.
```
gamma.nextSeed = random.randbytes()
dmsgs = empty
for each ID in recipients:
(gamma, msg) = encrypt-to(gamma, ID, gamma.nextSeed)
dmsgs = dmsgs + (ID, msg)
return (gamma, dmsgs)
```
### Creation of a group
A group is generated in a 3 steps procedure:
1. A user calls the `create` function and broadcasts a control message of type *create*.
2. Each receiver of the message processes the message and broadcasts an *ack* control message.
3. Each member processes the *ack* message received.
#### create
This function generates a *create* control message and
calls `generate-seed` to define the set of direct messages that need to be sent.
Then it calls `process-create` to process the control message for this user.
The function `process-create` returns a tuple including an updated state gamma and
an update secret `I`.
```
control = (“create”, gamma.mySeq, IDs)
(gamma, dmsgs) = generate-seed(gamma, IDs)
(gamma, _, _, I, _) = process-create(gamma, gamma.myId, gamma.mySeq, IDs, empty_string)
return (gamma, control, dmsgs, I)
```
#### process-seed
This function initially employs `member-view` to identify the users who were part of the group when the control message was dispatched.
Then, it attempts to acquire the seed secret through the following steps:
1. If the control message was dispatched by the local user,
it uses the most recent invocation of `generate-seed` stored the seed secret in `gamma.nextSeed`.
2. If the `control` message was dispatched by another user, and
the local user is among its recipients,
the function utilizes `decrypt-from` to decrypt the direct message that includes the seed secret.
3. Otherwise, it returns an `ack` message without deriving an update secret.
Afterwards, `process-seed` generates separate member secrets for each group member from the seed secret by combining the seed secret and
each user ID using HKDF.
The secret for the sender of the message is stored in `senderSecret`,
while those for the other group members are stored in `gamma.memberSecret`.
The sender's member secret is immediately utilized to update their KDF ratchet and
compute their update secret `I_sender` using `update-ratchet`.
If the local user is the sender of the control message,
the process is completed, and the update secret is returned.
However, if the seed secret is received from another user,
an `ack` control message is constructed for broadcast,
including the sender ID and sequence number of the message being acknowledged.
The final step computes an update secret `I_me` for the local user invoking the `process-ack` function.
```
recipients = member-view(gamma, sender) - {sender}
if sender = gamma.myId then seed = gamma.nextSeed; gamma.nextSeed = empty_string
else if gamma.myId in recipients then (gamma, seed) = decrypt-from(gamma, sender, dmsg)
else
return (gamma, (ack, ++gamma.mySeq, (sender, seq)), empty_string , empty_string , empty_string)
for ID in recipients do gamma.memberSecret[sender, seq, ID] = HKDF(seed, ID)
senderSecret = HKDF(seed, sender)
(gamma, I_sender) = update-ratchet(gamma, sender, senderSecret)
if sender = gamma.myId then return (gamma, empty_string , empty_string , I_sender, empty_string)
control = (ack, ++gamma.mySeq, (sender, seq))
members = member-view(gamma, gamma.myId)
forward = empty
for ID in {members - (recipients + {sender})}
s = gamma.memberSecret[sender, seq, gamma.myId]
(gamma, msg) = encrypt-to(gamma, ID, s)
forward = forward + {(ID, msg)}
(gamma, _, _, I_me, _) = process-ack(gamma, gamma.myId, gamma.mySeq, (sender, seq), empty_string)
return (gamma, control, forward, I_sender, I_me)
```
#### process-create
This function is called by the sender and each of the receivers of the `create` control message.
First, it records the information from the create message in the `gamma.history+ {op}`,
which is used to track group membership changes. Then, it proceeds to call `process-seed`.
```
op = (”create”, sender, seq, IDs)
gamma.history = gamma.history + {op}
return (process-seed(gamma, sender, seq, dmsg))
```
#### process-ack
This function is called by those group members once they receive an ack message.
In `process-ack`, `ackID` and `ackSeq` are the sender and
sequence number of the acknowledged message.
Firstly, if the acknowledged message is a group membership operation,
it records the acknowledgement in `gamma.history`.
Following this, the function retrieves the relevant member secret from `gamma.memberSecret`,
which was previously obtained from the seed secret contained in the acknowledged message.
Finally, it updates the ratchet for the sender of the `ack` and
returns the resulting update secret.
```
if (ackID, ackSeq) was a create / add / remove then
op = ("ack", sender, seq, ackID, ackSeq)
gamma.history = gamma.history + {op}`
s = gamma.memberSecret[ackID, ackSeq, sender]
gamma.memberSecret[ackID, ackSeq, sender] = empty_string
if (s = empty_string) & (dmsg = empty_string) then return (gamma, empty_string, empty_string, empty_string, empty_string)
if (s = empty_string) then (gamma, s) = decrypt-from(gamma, sender, dmsg)
(gamma, I) = update-ratchet(gamma, sender, s)
return (gamma, empty_string, empty_string, I, empty_string)
```
The HKDF function MUST follow RFC 5869 using the hash function SHA256.
### Post-compromise security updates and group member removal
The functions `update` and `remove` share similarities with `create`:
they both call the function `generate-seed` to encrypt a new seed secret for each group member.
The distinction lies in the determination of the group members using `member-view`.
In the case of `remove`, the user being removed is excluded from the recipients of the seed secret.
Additionally, the control message they construct is designated with type `update` or `remove` respectively.
Likewise, `process-update` and `process-remove` are akin to `process-create`.
The function `process-update` skips the update of `gamma.history`,
whereas `process-remove` includes a removal operation in the history.
#### update
```
control = ("update", ++gamma.mySeq, empty_string)
recipients = member-view(gamma, gamma.myId) - {gamma.myId}
(gamma, dmsgs) = generate-seed(gamma, recipients)
(gamma, _, _, I , _) = process-update(gamma, gamma.myId, gamma.mySeq, empty_string, empty_string)
return (gamma, control, dmsgs, I)
```
#### remove
```
control = ("remove", ++gamma.mySeq, empty)
recipients = member-view(gamma, gamma.myId) - {ID, gamma.myId}
(gamma, dmsgs) = generate-seed(gamma, recipients)
(gamma, _, _, I , _) = process-update(gamma, gamma.myId, gamma.mySeq, ID, empty_string)
return (gamma, control, dmsgs, I)
```
#### process-update
`return process-seed(gamma, sender, seq, dmsg)`
#### process-remove
```
op = ("remove", sender, seq, removed)
gamma.history = gamma.history + {op}
return process-seed(gamma, sender, seq, dmsg)
```
### Group member addition
#### add
When adding a new group member,
an existing member initiates the process by invoking the `add` function and
providing the ID of the user to be added.
This function prepares a control message marked as `add` for broadcast to the group.
Simultaneously, it creates a welcome message intended for the new member as a direct message.
This `welcome` message includes the current state of the sender's KDF ratchet,
encrypted using `2SM`, along with the history of group membership operations conducted so far.
```
control = ("add", ++gamma.mySeq, ID)
(gamma, c) = encrypt-to(gamma, ID, gamma.ratchet[gamma.myId])
op = ("add", gamma.myId, gamma.mySeq, ID)
welcome = (gamma.history + {op}, c)
(gamma, _, _, I, _) = process-add(gamma, gamma.myId, gamma.mySeq, ID, empty_string)
return (gamma, control, (ID, welcome), I)
```
#### process-add
This function is invoked by both the sender and
each recipient of an `add` message, which includes the new group member.
If the local user is the newly added member,
the function proceeds to call `process-welcome` and then exits.
Otherwise, it extends `gamma.history` with the `add` operation.
Line 5 determines whether the local user was already a group member at the time the `add` message was sent;
this condition is typically true but may be false if multiple users were added concurrently.
On lines 6 to 8, the ratchet for the sender of the *add* message is updated twice.
In both calls to `update-ratchet`,
a constant string is used as the ratchet input instead of a random seed secret.
The value returned by the first ratchet update is stored in `gamma.memberSecret` as the added user’s initial member secret.
The result of the second ratchet update becomes `I_sender`,
the update secret for the sender of the `add` message.
On line 10, if the local user is the sender, the update secret is returned.
If the local user is not the sender, an acknowledgment for the `add` message is required.
Therefore, on line 11, a control message of type `add-ack` is constructed for broadcast.
Subsequently, in line 12 the current ratchet state is encrypted using `2SM` to generate a direct message intended for the added user,
allowing them to decrypt subsequent messages sent by the sender.
Finally, in lines 13 to 15, `process-add-ack` is called to calculate the local user’s update secret (`I_me`),
which is then returned along with `I_sender`.
```
if added = gamma.myId then return process-welcome(gamma, sender, seq, dmsg)
op = ("add", sender, seq, added)
gamma.history = gamma.history + {op}
if gamma.myId in member-view(gamma, sender) then
(gamma, s) = update-ratchet(gamma, sender, "welcome")
gamma.memberSecret[sender, seq, added] = s
(gamma, I_sender) = update-ratchet(gamma, sender, "add")
else I_sender = empty_string
if sender = gamma.myId then return (gamma, empty_string, empty_string, I_sender, empty_string)
control = ("add-ack", ++gamma.mySeq, (sender, seq))
(gamma, c) = encrypt-to(gamma, added, ratchet[gamma.myId])
(gamma, _, _, I_me, _) = process-add-ack(gamma, gamma.myId, gamma.mySeq, (sender, seq), empty_string)
return (gamma, control, {(added, c)}, I_sender, I_me)
```
#### process-add-ack
This function is invoked by both the sender and each recipient of an `add-ack` message,
including the new group member.
Upon lines 1–2, the acknowledgment is added to `gamma.history`,
mirroring the process in `process-ack`.
If the current user is the new group member,
the `add-ack` message includes the direct message constructed in `process-add`;
this direct message contains the encrypted ratchet state of the sender of the `add-ack`,
then it is decrypted on lines 3–5.
Upon line 6, a check is performed to check if the local user was already a group member at the time the `add-ack` was sent.
If affirmative, a new update secret `I` for the sender of the `add-ack` is computed on line 7 by invoking `update-ratchet` with the constant string `add`.
In the scenario involving the new member,
the ratchet state was recently initialized on line 5.
This ratchet update facilitates all group members, including the new addition,
to derive each member’s update by obtaining any update secret from before their inclusion.
```
op = ("ack", sender, seq, ackID, ackSeq)
gamma$.history = gamma.history + {op}
if dmsg != empty_string then
(gamma, s) = decrypt-from(gamma, sender, dmsg)
gamma.ratchet[sender] = s
if gamma.myId in member-view(gamma, sender) then
(gamma, I) = update-ratchet(gamma, sender, "add")
return (gamma, empty_string, empty_string, I, empty_string)
else return (gamma, empty_string, empty_string, empty_string, empty_string)
```
#### process-welcome
This function serves as the second step called by a newly added group member.
In this context, `adderHistory` represents the adding user’s copy of `gamma.history` sent in their welcome message,
which is utilized to initialize the added user’s history.
Here, `c` denotes the ciphertext of the adding user’s ratchet state,
which is decrypted on line 2 using `decrypt-from`.
Once `gamma.ratchet[sender]` is initialized,
`update-ratchet` is invoked twice on lines 3 to 5 with the constant strings `welcome` and `add` respectively.
These operations mirror the ratchet operations performed by every other group member in `process-add`.
The outcome of the first `update-ratchet` call becomes the first member secret for the added user,
while the second call returns `I_sender`, the update secret for the sender of the add operation.
Subsequently, the new group member constructs an *ack* control message to broadcast on line 6 and
calls `process-ack` to compute their initial update secret I_me.
The function `process-ack` reads from `gamma.memberSecret` and
passes it to `update-ratchet`.
The previous ratchet state for the new member is the empty string `empty`, as established by `init`,
thereby initializing the new member’s ratchet.
Upon receiving the new member’s `ack`,
every other group member initializes their copy of the new member’s ratchet in a similar manner.
By the conclusion of `process-welcome`,
the new group member has acquired update secrets for themselves and the user who added them.
The ratchets for other group members are initialized by `process-add-ack`.
```
gamma.history = adderHistory
(gamma, gamma.ratchet[sender]) = decrypt-from(gamma, sender, c)
(gamma, s) = update-ratchet(gamma, sender, "welcome")
gamma.memberSecret[sender, seq, gamma.myId] = s
(gamma, I_sender) = update-ratchet(gamma, sender, "add")
control = ("ack", ++gamma.mySeq, (sender, seq))
(gamma, _, _, I_me, _) = process-ack(gamma, gamma.myId, gamma.mySeq, (sender, seq), empty_string)
return (gamma, control, empty_string , I_sender, I_me)
```
## Privacy Considerations
### Dependency on PKI
The [DCGKA](https://eprint.iacr.org/2020/1281) proposal presents some limitations highlighted by the authors.
Among these limitations one finds the requirement of a PKI (or a key server) mapping IDs to public keys.
One method to overcome this limitation is adapting the protocol SIWE (Sign in with Ethereum) so
a user `u_1` who wants to start a communication with a user `u_2` can interact with latter’s wallet to request a public key using an Ethereum address as `ID`.
#### SIWE
The [SIWE](https://docs.login.xyz/general-information/siwe-overview) (Sign In With Ethereum) proposal was a suggested standard for leveraging Ethereum to authenticate and authorize users on web3 applications.
Its goal is to establish a standardized method for users to sign in to web3 applications using their Ethereum address and private key,
mirroring the process by which users currently sign in to web2 applications using their email and password.
Below follows the required steps:
1. A server generates a unique Nonce for each user intending to sign in.
2. A user initiates a request to connect to a website using their wallet.
3. The user is presented with a distinctive message that includes the Nonce and details about the website.
4. The user authenticates their identity by signing in with their wallet.
5. Upon successful authentication, the user's identity is confirmed or approved.
6. The website grants access to data specific to the authenticated user.
#### Our approach
The idea in the [DCGKA](https://eprint.iacr.org/2020/1281) setting closely resembles the procedure outlined in SIWE. Here:
1. The server corresponds to user D1,
who initiates a request (instead of generating a nonce) to obtain the public key of user D2.
2. Upon receiving the request, the wallet of D2 send the request to the user,
3. User D2 receives the request from the wallet, and decides whether accepts or rejects.
4. The wallet and responds with a message containing the requested public key in case of acceptance by D2.
This message may be signed, allowing D1 to verify that the owner of the received public key is indeed D2.
### Multi-device setting
One may see the set of devices as a group and create a group key for internal communications.
One may use treeKEM for instance,
since it provides interesting properties like forward secrecy and post-compromise security.
All devices share the same `ID`,
which is held by one of them, and from other user’s point of view, they would look as a single user.
Using servers, like in the paper [Multi-Device for Signal](https://eprint.iacr.org/2019/1363), should be avoided;
but this would imply using a particular device as receiver and broadcaster within the group.
There is an obvious drawback which is having a single device working as a “server”.
Should this device be attacked or without connection, there should be a mechanism for its revocation and replacement.
Another approach for communications between devices could be using the keypair of each device.
This could open the door to use UPKE, since keypairs should be regenerated frequently.
Each time a device sends a message, either an internal message or an external message,
it needs to replicate and broadcast it to all devices in the group.
The mechanism for the substitution of misbehaving leader devices follows:
1. Each device within a group knows the details of other leader devices.
This information may come from metadata in received messages, and is replicated by the leader device.
2. To replace a leader, the user should select any other device within its group and
use it to send a signed message to all other users.
3. To get the ability to sign messages,
this new leader should request the keypair associated to the ID to the wallet.
4. Once the leader has been changed,
it revocates access from DCGKA to the former leader using the DCGKA protocol.
5. The new leader starts a key update in DCGKA.
Not all devices in a group should be able to send messages to other users.
Only the leader device should be in charge of sending and receiving messages.
To prevent other devices from sending messages outside their group, a requirement should be signing each message.
The keys associated to the `ID` should only be in control of the leader device.
The leader device is in charge of setting the keys involved in the DCGKA.
This information must be replicated within the group to make sure it is updated.
To detect missing messages or potential misbehavior, messages must include a counter.
### Using UPKE
Managing the group of devices of a user can be done either using a group key protocol such as treeKEM or
using the keypair of each device.
Setting a common key for a group of devices under the control of the same actor might be excessive,
furthermore it may imply some of the problems one can find in the usual setting of a group of different users;
for example: one of the devices may not participate in the required updating processes, representing a threat for the group.
The other approach to managing the group of devices is using each device’s keypair,
but it would require each device updating these materia frequently, something that may not happens.
[UPKE](https://eprint.iacr.org/2022/068) is a form of asymetric cryptography
where any user can update any other user’s key pair by running an update algorithm with (high-entropy) private coins.
Any sender can initiate a *key update* by sending a special update ciphertext.
This ciphertext updates the receiver’s public key and also, once processed by the receiver, will update their secret key.
To the best of my knowledge,
there exists several efficient constructions both [UPKE from ElGamal](https://eprint.iacr.org/2019/1189) (based in the DH assumption) and
[UPKE from Lattices]((https://eprint.iacr.org/2023/1400)) (based in lattices).
None of them have been implemented in a secure messaging protocol, and this opens the door to some novel research.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
## References
- [DCGKA](https://eprint.iacr.org/2020/1281)
- [MLS](https://messaginglayersecurity.rocks)
- [CoCoa](https://eprint.iacr.org/2022/251)
- [Causal TreeKEM](https://mattweidner.com/assets/pdf/acs-dissertation.pdf)
- [SIWE](https://docs.login.xyz/general-information/siwe-overview)
- [Multi-device for Signal](https://eprint.iacr.org/2019/1363)
- [UPKE](https://eprint.iacr.org/2022/068)
- [UPKE from ElGamal](https://eprint.iacr.org/2019/1189)
- [UPKE from Lattices](https://eprint.iacr.org/2023/1400)