# Encryption & Zero Trust Model

Sudo’s Encryption & Zero Trust Model is designed to make interception, unauthorized access, and surveillance practically impossible—both for malicious actors and the platform itself. This approach combines battle-tested cryptographic protocols with decentralized identity and data storage principles.

\
**1. End-to-End Encryption (E2EE)**

Sudo’s encryption stack uses the Libsignal Protocol, considered the industry standard for secure messaging. Its design ensures that even if communication channels are intercepted, the attacker cannot decrypt past or future messages.

* Double Ratchet Algorithm: Generates new keys for each message, ensuring perfect forward secrecy.<br>
* X3DH Key Agreement: Establishes initial secure sessions without exposing private keys.<br>
* AES-256-GCM: Provides robust encryption for message content.<br>
* Curve25519: Used for secure elliptic-curve key exchange.\
  All encryption and decryption happen on the user’s device, ensuring that no server ever has access to plaintext content.<br>

#### 2. Wallet-Based Self-Custody Identity

Instead of phone numbers, emails, or centralized accounts, Sudo uses wallet addresses as the sole user identity.

* No central database of user credentials exists.<br>
* Sign-in occurs via cryptographic signature requests through supported wallets (MetaMask, Trust Wallet, WalletConnect).<br>
* This method removes the possibility of mass credential leaks or centralized account control.

\
**3. Zero Trust Architecture Principles**

Sudo’s infrastructure assumes that every component could be compromised—and designs security so no single component holds enough data to break user privacy.

|        Area        |                                    Mechanism                                   |
| :----------------: | :----------------------------------------------------------------------------: |
|   Message Access   | Private keys never leave the user’s device; only sender and recipient decrypt. |
|    Data at Rest    |             Stored only as encrypted ciphertext; no plaintext logs.            |
| Transport Security |   TLS encryption by default; optional Waku for fully decentralized transport.  |
|   Smart Contracts  |           Contract linking restricted to wallet-signed verification.           |
|  Username Control  |               Usernames exist as NFTs or decentralized Sudo IDs.               |

### Messaging, Channels, and Group Logic

Sudo’s messaging architecture is engineered for scalability, security, and seamless integration with Web3 ecosystems. It supports both private communication and decentralized community interactions, combining familiar chat experiences with the unique capabilities of smart contract–linked groups and channels.

\
**1. Message Types**

Sudo supports multiple communication modes, each tailored for specific use cases:

|       **Type**       |                                       **Description**                                      |
| :------------------: | :----------------------------------------------------------------------------------------: |
|  Direct Message (DM) |               One-to-one encrypted chat between two wallet-identified users.               |
|      Group Chat      |                   Multi-user conversation created by any wallet address.                   |
|        Channel       |        One-way announcement stream where the creator posts and others can only read.       |
| Smart Contract Group | Automatically synchronized group tied to an on-chain smart contract’s interacting wallets. |

\
**2. Message Routing Logic**

Every message in Sudo carries structured metadata to enable precise and efficient delivery.

|    **Field**   | **Example Value**       | **Purpose**                                                        |
| :------------: | ----------------------- | ------------------------------------------------------------------ |
| sender\_wallet | 0xabc...123             | Verifies the sender’s identity via wallet signature.               |
| receiver\_type | dm / group / channel    | Determines routing to a private chat, group, or broadcast channel. |
|   target\_id   | Group#90210 or User#xyz | Identifies the recipient group, channel, or user.                  |
|    timestamp   | 1683892321 (UNIX)       | Ensures correct ordering and time-to-live (TTL) handling.          |
|  message\_type | text, image, file, etc. | Defines the message format for UI rendering.                       |

This routing framework allows Sudo to maintain low-latency delivery, even at scale.

#### 3. Group & Channel Ownership

Groups and channels in Sudo are owned by the wallet that creates them:

* The creator wallet becomes the owner with full administrative rights.<br>

**Owners can:**<br>

* Appoint additional admins.<br>
* Define join permissions (open, invite-only, token/NFT-gated).<br>
* Configure message expiry rules.<br>
* Enable meeting and conferencing features.<br>

Ownership is on-chain and can be transferred or sold using NFT-like ownership logic (optional upgrade).\
\
This on-chain ownership model gives creators a verifiable, tradable stake in their communities.

#### 4. Smart Contract Groups

Sudo enables auto-synced groups linked directly to on-chain smart contracts, unlocking new ways for protocols and projects to engage their communities.

* Supports contracts for DEXs, NFT collections, DAOs, staking pools, and more.
* Automatically syncs all unique wallet addresses that have interacted with the linked contract.<br>

**Utilizes both:**<br>

* Off-chain indexers like The Graph for historical and large-scale data retrieval.
* Internal caching for low-latency lookups and real-time updates.<br>

**Ideal for:**<br>

* Community building.
* Protocol support channels.
* DAO governance and proposal discussions.<br>

#### 5. Privacy Settings (User Level)

Users have granular control over their visibility and interactions:

| Action                    | Options                         |
| ------------------------- | ------------------------------- |
| Username Visibility       | Public / Private                |
| Last Seen / Online Status | Everyone / Contacts Only / None |
| Message Read Receipts     | Enabled / Disabled              |
| Group Discoverability     | Searchable / Invite Only        |

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sudochat.app/sudo-whitepaper/overview/publish-your-docs/vision-and-mission/encryption-and-zero-trust-model.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.