mirror of
https://github.com/RedWizardsLab/EchoHub.git
synced 2026-09-04 16:46:08 +02:00
deploy: 1f4af9a543
This commit is contained in:
HueByte
@@ -0,0 +1,271 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<title>Encrypted Rooms (Password-Protected Channels) | EchoHub Documentation </title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="title" content="Encrypted Rooms (Password-Protected Channels) | EchoHub Documentation ">
|
||||
|
||||
|
||||
<link rel="icon" href="../images/hue_icon.svg">
|
||||
<link rel="stylesheet" href="../public/docfx.min.css">
|
||||
<link rel="stylesheet" href="../public/main.css">
|
||||
<meta name="docfx:navrel" content="../toc.html">
|
||||
<meta name="docfx:tocrel" content="toc.html">
|
||||
|
||||
<meta name="docfx:rel" content="../">
|
||||
|
||||
|
||||
<meta name="docfx:docurl" content="https://github.com/HueByte/EchoHub/blob/master/docs/#L1">
|
||||
<meta name="loc:inThisArticle" content="In this article">
|
||||
<meta name="loc:searchResultsCount" content="{count} results for "{query}"">
|
||||
<meta name="loc:searchNoResults" content="No results for "{query}"">
|
||||
<meta name="loc:tocFilter" content="Filter by title">
|
||||
<meta name="loc:nextArticle" content="Next">
|
||||
<meta name="loc:prevArticle" content="Previous">
|
||||
<meta name="loc:themeLight" content="Light">
|
||||
<meta name="loc:themeDark" content="Dark">
|
||||
<meta name="loc:themeAuto" content="Auto">
|
||||
<meta name="loc:changeTheme" content="Change theme">
|
||||
<meta name="loc:copy" content="Copy">
|
||||
<meta name="loc:downloadPdf" content="Download PDF">
|
||||
|
||||
<script type="module" src="./../public/docfx.min.js"></script>
|
||||
|
||||
<script>
|
||||
const theme = localStorage.getItem('theme') || 'auto'
|
||||
document.documentElement.setAttribute('data-bs-theme', theme === 'auto' ? (window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light') : theme)
|
||||
</script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="tex2jax_ignore" data-layout="" data-yaml-mime="">
|
||||
<header class="bg-body border-bottom">
|
||||
<nav id="autocollapse" class="navbar navbar-expand-md" role="navigation">
|
||||
<div class="container-xxl flex-nowrap">
|
||||
<a class="navbar-brand" href="../index.html">
|
||||
<img id="logo" class="svg" src="../images/hue_icon.svg" alt="EchoHub">
|
||||
EchoHub
|
||||
</a>
|
||||
<button class="btn btn-lg d-md-none border-0" type="button" data-bs-toggle="collapse" data-bs-target="#navpanel" aria-controls="navpanel" aria-expanded="false" aria-label="Toggle navigation">
|
||||
<i class="bi bi-three-dots"></i>
|
||||
</button>
|
||||
<div class="collapse navbar-collapse" id="navpanel">
|
||||
<div id="navbar">
|
||||
<form class="search" role="search" id="search">
|
||||
<i class="bi bi-search"></i>
|
||||
<input class="form-control" id="search-query" type="search" disabled placeholder="Search" autocomplete="off" aria-label="Search">
|
||||
</form>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
</header>
|
||||
|
||||
<main class="container-xxl">
|
||||
<div class="toc-offcanvas">
|
||||
<div class="offcanvas-md offcanvas-start" tabindex="-1" id="tocOffcanvas" aria-labelledby="tocOffcanvasLabel">
|
||||
<div class="offcanvas-header">
|
||||
<h5 class="offcanvas-title" id="tocOffcanvasLabel">Table of Contents</h5>
|
||||
<button type="button" class="btn-close" data-bs-dismiss="offcanvas" data-bs-target="#tocOffcanvas" aria-label="Close"></button>
|
||||
</div>
|
||||
<div class="offcanvas-body">
|
||||
<nav class="toc" id="toc"></nav>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="content">
|
||||
<div class="actionbar">
|
||||
<button class="btn btn-lg border-0 d-md-none" type="button" data-bs-toggle="offcanvas" data-bs-target="#tocOffcanvas" aria-controls="tocOffcanvas" aria-expanded="false" aria-label="Show table of contents">
|
||||
<i class="bi bi-list"></i>
|
||||
</button>
|
||||
|
||||
<nav id="breadcrumb"></nav>
|
||||
</div>
|
||||
|
||||
<article data-uid="">
|
||||
<h1 id="encrypted-rooms-password-protected-channels">Encrypted Rooms (Password-Protected Channels)</h1>
|
||||
|
||||
<p>An <strong>encrypted room</strong> is a channel whose entire content — every message and every file — is
|
||||
end-to-end encrypted with a key derived from a shared passphrase. Only people who know the
|
||||
passphrase can read the room. <strong>Not even the server owner can read the content</strong>, yet the server
|
||||
can still gate who joins, and it can count and measure what's stored (message count, file sizes,
|
||||
timestamps) without ever seeing the plaintext.</p>
|
||||
<p>This is a stronger guarantee than the <a href="encryption.html">transport and at-rest encryption</a> described
|
||||
elsewhere, where the server decrypts every message to process it. Here the server is treated as
|
||||
<em>untrusted</em> for content: it holds only ciphertext and wrapped keys.</p>
|
||||
<blockquote>
|
||||
<p><strong>The passphrase is the only key.</strong> There is no recovery. If everyone who knows a room's
|
||||
passphrase forgets it, that room's history is permanently unreadable — by design.</p>
|
||||
</blockquote>
|
||||
<h2 id="what-the-server-can-and-cannot-see">What the server can and cannot see</h2>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>The server <strong>can</strong> see</th>
|
||||
<th>The server <strong>cannot</strong> see</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>That the channel is encrypted</td>
|
||||
<td>Message text</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Message count and timestamps</td>
|
||||
<td>File contents</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Who sent each message (sender identity)</td>
|
||||
<td>Image previews (ASCII art)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Each attachment's <strong>file name</strong> and byte size</td>
|
||||
<td>The passphrase, the room key, or the key-encryption key</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>The estimated total size (via <code>/meta</code>)</td>
|
||||
<td>Anything that would let it decrypt the above</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>File <strong>names are stored in plaintext</strong> so the file list stays usable — treat a file name itself as
|
||||
non-secret. Everything <em>inside</em> the file is encrypted.</p>
|
||||
<h2 id="key-hierarchy">Key hierarchy</h2>
|
||||
<p>Three keys are derived from one passphrase. The passphrase, the key-encryption key, and the room
|
||||
content key <strong>never leave the client</strong>.</p>
|
||||
<pre><code class="lang-mermaid">flowchart TD
|
||||
P[Passphrase] -->|PBKDF2-SHA256, 210k iterations, per-room salt| OKM[64-byte output]
|
||||
OKM --> AK["Auth key (first 32 bytes)"]
|
||||
OKM --> KEK["Key-encryption key / KEK (last 32 bytes)"]
|
||||
AK -->|sent as lowercase hex| SRV1["Server: BCrypt-hash as the join gate"]
|
||||
RCK["Room Content Key (random 256-bit)"] -->|encrypts all content| CONTENT[Messages + files + previews]
|
||||
RCK -->|AES-256-GCM wrap under KEK| WRAP["Wrapped room key"]
|
||||
WRAP -->|stored| SRV2["Server: stores wrapped key + salt only"]
|
||||
</code></pre>
|
||||
<ul>
|
||||
<li><strong>Auth key</strong> — the join credential. Derived from the passphrase, sent to the server as hex, and
|
||||
stored only as a <strong>BCrypt hash</strong>. Proving knowledge of it is what lets you join; it reveals
|
||||
nothing about the content key.</li>
|
||||
<li><strong>Key-encryption key (KEK)</strong> — never sent. Used locally to <em>wrap</em> (encrypt) and <em>unwrap</em> the room
|
||||
content key.</li>
|
||||
<li><strong>Room Content Key (RCK)</strong> — a random 256-bit key generated once, at room creation. It encrypts
|
||||
every message and file. The server stores it only in wrapped form, so it can hand the wrapped key
|
||||
to a joiner but can never unwrap it itself.</li>
|
||||
</ul>
|
||||
<p>All content encryption is <strong>AES-256-GCM</strong> with a random 12-byte nonce and a 16-byte authentication
|
||||
tag per item, so identical inputs never produce identical ciphertext, and any tampering is detected.</p>
|
||||
<p>Room-encrypted text carries a self-describing prefix so clients and the server can tell it apart
|
||||
from plaintext:</p>
|
||||
<pre><code class="lang-text">$RC1$base64(nonce || tag || ciphertext)
|
||||
</code></pre>
|
||||
<h2 id="creating-a-room">Creating a room</h2>
|
||||
<p>The client does all the cryptography locally, then hands the server only what it needs to gate joins
|
||||
and store (but not read) the content.</p>
|
||||
<pre><code class="lang-mermaid">sequenceDiagram
|
||||
participant Client
|
||||
participant Server
|
||||
|
||||
Client->>Client: generate salt + random Room Content Key (RCK)
|
||||
Client->>Client: DeriveKeys(passphrase, salt) → auth key + KEK
|
||||
Client->>Client: wrap RCK under KEK
|
||||
Client->>Server: create channel { authKey(hex), salt, wrappedRoomKey }
|
||||
Server->>Server: BCrypt-hash auth key, store salt + wrapped key
|
||||
Note over Server: Server never receives passphrase, KEK, or RCK
|
||||
</code></pre>
|
||||
<h2 id="joining-a-room">Joining a room</h2>
|
||||
<pre><code class="lang-mermaid">sequenceDiagram
|
||||
participant Client
|
||||
participant Server
|
||||
|
||||
Client->>Server: GET /crypto → { isEncrypted, salt }
|
||||
Client->>Client: DeriveKeys(passphrase, salt) → auth key + KEK
|
||||
Client->>Server: join { authKey(hex) }
|
||||
Server->>Server: BCrypt-verify against stored hash
|
||||
alt correct passphrase
|
||||
Server->>Client: history (ciphertext) + wrapped room key
|
||||
Client->>Client: unwrap RCK with KEK, then decrypt everything locally
|
||||
else wrong passphrase
|
||||
Server->>Client: rejected (join gate fails)
|
||||
end
|
||||
</code></pre>
|
||||
<p>A wrong passphrase fails the BCrypt gate, so the server never even hands out the wrapped key. Even if
|
||||
it did, an attacker without the KEK cannot unwrap it.</p>
|
||||
<h2 id="what-gets-encrypted">What gets encrypted</h2>
|
||||
<p>When you send a message or attach files to an encrypted room, the client encrypts each part with the
|
||||
room content key <strong>before</strong> uploading:</p>
|
||||
<ul>
|
||||
<li><strong>Message text</strong> → <code>$RC1$…</code> ciphertext.</li>
|
||||
<li><strong>Files</strong> (any kind) → the whole blob is AES-256-GCM encrypted client-side; the server stores an
|
||||
opaque ciphertext blob.</li>
|
||||
<li><strong>Image ASCII previews</strong> → rendered on the client, then room-encrypted. The server never sees the
|
||||
rendered art.</li>
|
||||
</ul>
|
||||
<p>The server records each attachment's <strong>kind</strong>, <strong>file name</strong>, and <strong>byte size</strong> (of the ciphertext
|
||||
blob) as metadata, and broadcasts the ciphertext to other members, who decrypt locally.</p>
|
||||
<h2 id="changing-the-passphrase">Changing the passphrase</h2>
|
||||
<p><code>/passwd <old> <new></code> rotates the passphrase. Because only the <em>wrapping</em> of the room content key
|
||||
changes — not the RCK itself — <strong>all existing history stays readable</strong>:</p>
|
||||
<ol>
|
||||
<li>The client proves knowledge of the old passphrase (old auth key).</li>
|
||||
<li>It unwraps the RCK with the old KEK, then re-wraps it under the new KEK (new salt).</li>
|
||||
<li>It uploads the new auth key + salt + re-wrapped key. The content is never re-encrypted.</li>
|
||||
</ol>
|
||||
<h2 id="inspecting-a-room">Inspecting a room</h2>
|
||||
<p>Use <code>/meta</code> in any channel to see what the server knows about it, including encrypted rooms:</p>
|
||||
<pre><code class="lang-text">Room info for #private-room:
|
||||
Room ID 3f2a…-…-…
|
||||
Created 7/16/2026 2:31 PM
|
||||
Messages 128
|
||||
Unique users 4
|
||||
Est. size 42.5 MB
|
||||
Protection end-to-end encrypted
|
||||
</code></pre>
|
||||
<p><code>Est. size</code> is the sum of stored attachment blob sizes plus message text length — an estimate of the
|
||||
room's footprint, computed entirely from metadata the server holds without reading any content.</p>
|
||||
<h2 id="limitations--security-notes">Limitations & security notes</h2>
|
||||
<ul>
|
||||
<li><strong>No recovery.</strong> A lost passphrase means unrecoverable history. Keep it safe; there is no reset.</li>
|
||||
<li><strong>File names are plaintext.</strong> They stay readable so the file list works — don't put secrets in a
|
||||
file name.</li>
|
||||
<li><strong>IRC is disabled for encrypted rooms.</strong> The IRC gateway forwards plaintext and cannot participate
|
||||
in the room's key scheme, so encrypted channels are not bridged to IRC.</li>
|
||||
<li><strong>Metadata is visible.</strong> Message counts, timestamps, sender identities, file names, and sizes are
|
||||
intentionally readable so the server can moderate at the metadata level and report <code>/meta</code>.</li>
|
||||
<li><strong>Endpoint trust.</strong> End-to-end encryption protects content from the server and the network, not
|
||||
from a compromised client device that already holds the passphrase.</li>
|
||||
</ul>
|
||||
<h2 id="related">Related</h2>
|
||||
<ul>
|
||||
<li><a href="encryption.html">Message Encryption</a> — transport (<code>$ENC$v1$</code>) and optional at-rest database
|
||||
encryption, where the server <em>does</em> decrypt content for processing. Encrypted rooms are a separate,
|
||||
stronger layer that sits on top.</li>
|
||||
</ul>
|
||||
|
||||
</article>
|
||||
|
||||
<div class="contribution d-print-none">
|
||||
<a href="https://github.com/HueByte/EchoHub/blob/master/docs/#L1" class="edit-link">Edit this page</a>
|
||||
</div>
|
||||
|
||||
<div class="next-article d-print-none border-top" id="nextArticle"></div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="affix">
|
||||
<nav id="affix"></nav>
|
||||
</div>
|
||||
</main>
|
||||
|
||||
<div class="container-xxl search-results" id="search-results"></div>
|
||||
|
||||
<footer class="border-top text-secondary">
|
||||
<div class="container-xxl">
|
||||
<div class="flex-fill">
|
||||
<div class='footer-custom'><div class='footer-inner'><span class='footer-brand'>EchoHub</span><span class='footer-sep'>·</span><a href='https://github.com/HueByte/EchoHub'>GitHub</a><span class='footer-sep'>·</span><a href='https://echohub.voidcube.cloud'>Website</a></div></div>
|
||||
</div>
|
||||
</div>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
@@ -197,7 +197,7 @@
|
||||
<h3 id="limitations">Limitations</h3>
|
||||
<ul>
|
||||
<li><strong>TLS-inspecting proxies</strong> — if a corporate proxy terminates TLS with a trusted root CA, it can intercept the key exchange (<code>GET /api/server/encryption-key</code>) and read all traffic. A future upgrade to ECDH key exchange would address this.</li>
|
||||
<li><strong>Server has full access</strong> — the server decrypts all messages for processing. This is not end-to-end encryption between users; it's transport encryption between client and server.</li>
|
||||
<li><strong>Server has full access</strong> — the server decrypts all messages for processing. This is not end-to-end encryption between users; it's transport encryption between client and server. For true end-to-end encryption where the server cannot read content, use <a href="encrypted-rooms.html">encrypted rooms</a>.</li>
|
||||
<li><strong>IRC clients receive plaintext</strong> — IRC is an open protocol and third-party clients cannot participate in the encryption scheme.</li>
|
||||
</ul>
|
||||
<h2 id="troubleshooting">Troubleshooting</h2>
|
||||
|
||||
@@ -32,6 +32,9 @@
|
||||
<li>
|
||||
<a href="encryption.html" name="" title="Encryption">Encryption</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="encrypted-rooms.html" name="" title="Encrypted Rooms">Encrypted Rooms</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="notification-sounds.html" name="" title="Notification Sounds">Notification Sounds</a>
|
||||
</li>
|
||||
|
||||
+1
-1
@@ -1,2 +1,2 @@
|
||||
|
||||
{"items":[{"name":"Guides","items":[{"name":"Getting Started","href":"getting-started.html","topicHref":"getting-started.html"},{"name":"Docker","href":"docker.html","topicHref":"docker.html"},{"name":"Architecture","href":"architecture.html","topicHref":"architecture.html"},{"name":"Configuration","href":"configuration.html","topicHref":"configuration.html"},{"name":"Encryption","href":"encryption.html","topicHref":"encryption.html"},{"name":"Notification Sounds","href":"notification-sounds.html","topicHref":"notification-sounds.html"}]},{"name":"Flows","includedFrom":"~/flows/toc.yml","items":[{"name":"Authentication","href":"../flows/authentication.html","topicHref":"../flows/authentication.html"},{"name":"Connection","href":"../flows/connection.html","topicHref":"../flows/connection.html"},{"name":"Messaging","href":"../flows/messaging.html","topicHref":"../flows/messaging.html"},{"name":"Channels","href":"../flows/channels.html","topicHref":"../flows/channels.html"},{"name":"Moderation","href":"../flows/moderation.html","topicHref":"../flows/moderation.html"},{"name":"Media & Services","href":"../flows/media.html","topicHref":"../flows/media.html"}]}]}
|
||||
{"items":[{"name":"Guides","items":[{"name":"Getting Started","href":"getting-started.html","topicHref":"getting-started.html"},{"name":"Docker","href":"docker.html","topicHref":"docker.html"},{"name":"Architecture","href":"architecture.html","topicHref":"architecture.html"},{"name":"Configuration","href":"configuration.html","topicHref":"configuration.html"},{"name":"Encryption","href":"encryption.html","topicHref":"encryption.html"},{"name":"Encrypted Rooms","href":"encrypted-rooms.html","topicHref":"encrypted-rooms.html"},{"name":"Notification Sounds","href":"notification-sounds.html","topicHref":"notification-sounds.html"}]},{"name":"Flows","includedFrom":"~/flows/toc.yml","items":[{"name":"Authentication","href":"../flows/authentication.html","topicHref":"../flows/authentication.html"},{"name":"Connection","href":"../flows/connection.html","topicHref":"../flows/connection.html"},{"name":"Messaging","href":"../flows/messaging.html","topicHref":"../flows/messaging.html"},{"name":"Channels","href":"../flows/channels.html","topicHref":"../flows/channels.html"},{"name":"Moderation","href":"../flows/moderation.html","topicHref":"../flows/moderation.html"},{"name":"Media & Services","href":"../flows/media.html","topicHref":"../flows/media.html"}]}]}
|
||||
|
||||
Reference in New Issue
Block a user