1.0 DAODIAL E2EE PROTOCOL OVERVIEW

VERSION: 2 BETA

End-to-End Encryption (E2EE) at DaoDial is defined as a communication architecture where only the designated cryptographic endpoints can decrypt the message payload. The intermediary relay server facilitates packet transport without maintaining access to the plaintext or the underlying secret keys.

2.0 KEY EXCHANGE PROBLEM

The basic problem with secure communication is to establish a common secret between two different parties when they have not communicated before. The key exchange method involves both parties being online at the same time, which makes it not applicable to an asynchronous message service.

This problem is addressed by DaoDial, which uses the X3DH algorithm (the Extended Triple Diffie-Hellman algorithm) of the Signal Protocol and enables users to start encrypted communications with offline users based on pre-published key bundles.

3.0 CRYPTOGRAPHIC PRIMITIVES

The following primitives are utilized within the Signal Protocol implementation on the Solana network:

4.0 WALLET IDENTITY MAPPING

The DaoDial identity model replaces legacy identifiers with a cryptographic proof of wallet ownership. The above mapping can be performed in a deterministic manner by all supported clients.

4.1 SEED DERIVATION PROCESS

Upon connection, the client signs a domain-separated constant string over the Ed25519 elliptic curve. This signature is used as a high-entropy seed for all subsequent key derivation.

5.0 KEY GENERATION FLOW

The primary key generation method yields three types of keys, which are essential for the Signal Protocol, namely:

5.1 IDENTITY KEY (IK)

A long-term key pair used for the wallet signature. The public part is uploaded to the server for verifying the authenticity of the messages.

5.2 SIGNED PRE-KEY (SPK)

A medium-term key pair that is signed with the Identity Key. It is rotated on a regular basis (default 7 days) to provide forward secrecy for the handshake procedure.

5.3 ONE-TIME PRE-KEYS (OPK)

A pool of single-use key pairs was uploaded to the server. These keys were used in the initial X3DH handshake and then deleted, which adds an extra level of forward secrecy.

5.4 OPK DELETION: ATOMIC CONSUMPTION

One-Time Pre-Keys follow a strict single-use policy with immediate and atomic deletion upon consumption. If a sender retrieves a recipient's pre-key bundle, the server processes an atomic database transaction that retrieves the key while simultaneously deleting it from the database.

Why it matters: It prevents the reuse of OPKs in attacks, restricts the exposure of the server compromise to the unconsumed keys only, and also solves the race conditions when multiple senders try to deliver messages to the target receiver at the same time.

DaoDial generates 100 OPKs initially and automatically replenishes when available keys drop below 20.

6.0 X3DH HANDSHAKE

X3DH establishes a shared secret between two parties where one may be offline. It calculates four Diffie-Hellman operations between Identity Keys, Signed Pre-Keys, and One-Time Pre-Keys.

6.1 HANDSHAKE SEQUENCE

When Oliver initiates a conversation with Charlie:

1. Oliver fetches Charlie's pre-key bundle from the server

2. Oliver generates an ephemeral key pair (EK)

3. Oliver computes the four DH operations

4. Oliver derives the shared secret using HKDF

5. Oliver sends the encrypted message along with his Identity Key and Ephemeral Key

6. Charlie receives and performs the inverse DH operations to derive the same secret

6.2 AD BINDING: CRYPTOGRAPHIC WALLET IDENTITY

Associated Data (AD) binding is what ensures that an encrypted message is cryptographically linked to particular wallet identities. In the context of the DaoDial, wallet addresses are linked via the Identity Keys used during the X3DH key exchange handshake.

The Identity Key (IK) is computed deterministically from a wallet signature. Because only a wallet owner can compute a signature, and because IK is used in both DH1 and DH2 of X3DH, a shared secret is tied to both identities in a wallet.

Security Features: Sender authentication (DH1 uses the IK private of the sender), receiver authentication (DH2 uses the IK public of the receiver), wallet binding (IK is mathematically bound to the wallet address), and ciphertext binding (prevents the redirection to other receivers).

7.0 DOUBLE RATCHET ALGORITHM

Once the initial secret is established via X3DH, the conversation transitions to the Double Ratchet state. This provides two distinct layers of security: Asymmetric (DH Ratchet) and Symmetric (Chain Ratchet).

7.1 SYMMETRIC RATCHET

Each message propels the symmetric ratchet forward, generating a new Message Key (MK) and erasing the former one. Thus, even if a single message key is compromised, it will not have any effect on past or future messages.

7.2 DH RATCHET

Each peer's response causes a DH ratchet cycle. Both sides send a new ephemeral public key and a new DH output that is used to refresh the root key. This offers post-compromise security.

7.3 RATCHET STATE

7.4 SKIPPED MESSAGE KEYS: OUT-OF-ORDER HANDLING

The network conditions may also cause the messages to be received in the wrong order. The Double Ratchet algorithm overcomes the problem of receiving messages in the wrong order through the use of "skipped" message keys, which allow the decryption of the messages once they have arrived.

In case the message has a sequence number greater than the one anticipated, the system calculates and stores the keys for the intermediate messages. For the delayed messages, the keys are used for decryption and then deleted (one-time use).

Security Limit: DaoDial maintains a maximum of 1,000 keys for skipped messages in a session. This provides protection against memory exhaustion attacks, yet also takes into account the tolerance of acceptable network delay. Crossing the limit would enable resetting a session via an X3DH handshake.

8.0 SESSION MANAGEMENT

Session management in DaoDial is responsible for the management of the cryptographic sessions between the communication parties. Each session holds a ratchet state, message counters, and chain keys that are specific to the session.

8.1 SESSION INITIALIZATION

During the start of a conversation initiated by Oliver with Charlie, the first thing the system checks is whether a session already exists. If a session does not exist, the pre-key bundle for Charlie is obtained from the server by the client of Oliver, and X3DH is performed to create a session. The Double Ratchet state is seeded with a shared secret.

8.2 SESSION PERSISTENCE

The sessions are persisted locally in encrypted storage. A session record holds the ratchet keys, message counters, and skipped keys for out-of-order delivery. The session data is encrypted with a key derived from the wallet signature of the user.

8.3 SESSION RESET PROTOCOL

When cryptographic desynchronization occurs (e.g., corrupted state or reinstallation), the system implements automatic session reset. The starting party then makes a new X3DH message to notify the other party to initiate new session state while preserving a conversation flow.

9.0 MULTI-DEVICE ARCHITECTURE

Multiple devices are supported per wallet address in DaoDial. Each device supports a separate cryptographic session, and a compromised device does not affect security on other devices.

9.1 DEVICE REGISTRATION

When the user adds a new device, it generates its Identity Key pair. It then registers an independent pre-key bundle to the server. It is associated with the wallet address by the process of signature verification.

9.2 PER-DEVICE ENCRYPTION

When Oliver sends a message to Charlie, Oliver's client asks the server for all device identifiers that belong to Charlie's wallet. The message is encrypted individually for each of Charlie's devices using their respective pre-key bundles.

9.3 DEVICE LINKING VIA QR

Existing devices will be able to authorize a new device through a secure transfer via a QR code. This code holds a single-use authorization code that enables a new device to register its keys using a wallet identity without requiring a private key transfer.

9.4 PRE-KEY BUNDLE SCHEMA

10.0 GHOST USER MIGRATION

Ghost User Migration handles the transition of users who received messages before completing their E2EE setup. This ensures no messages are lost during the onboarding process.

10.1 GHOST USER STATE

A ghost user exists when someone sends a message to a wallet address that has not yet registered pre-keys. The server stores encrypted message metadata and queues delivery for when the recipient completes registration.

10.2 MIGRATION FLOW

A migration event is triggered as the ghost user registers his pre-keys with the server. The senders, who have queued messages, are notified to re-encrypt and resend the messages using the pre-key bundle that is now available. The original plaintext is obtained from local storage and re-encrypted with the new session key.

10.3 FALLBACK ENCRYPTION

During the ghost state, messages may be stored with temporary server-side encryption. Upon migration, these messages are again encrypted end-to-end and their server-encrypted copies are deleted.

11.0 PROTOCOL SIMULATOR

Use the interactive simulator below to observe the X3DH handshake and Double Ratchet message encryption in real-time. Enter plaintext and execute the transmission to see the protocol in action.