Enkrypted Chat — Complete Whitepaper

Work in progress — not audited

This document is an initial draft by Positive Intentions. Enkrypted Chat has not been independently audited. Do not rely on it for sensitive communications or production use.

Document status: Initial draft (informal v0.1) · Product: Enkrypted Chat · Organization: Positive Intentions

This page combines every specification chapter for one-shot printing. Use Print → Save as PDF and enable Background graphics so Mermaid diagrams render.

Document overview

Product specification and whitepaper for Enkrypted Chat: goals, architecture, transport, encryption, session model, messages, privacy, deployment, threat model, implementation map, limitations, and references. For the navigable multi-page version, see the Whitepaper section in the sidebar.

1. Goals and Terminology

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

1.1 Goals

Enkrypted Chat aims to provide:

1. Direct peer messaging — Browser-to-browser communication over WebRTC without a central message store.
2. Layered end-to-end encryption — Application-level cascade (MLS, Signal, ML-KEM, AES) on top of WebRTC transport cryptography.
3. User-controlled keys — Keys generated and held on the client; no registration server for identity.
4. Modular delivery — Shared cryptography, P2P, and UI logic via Module Federation across apps (chat, files, calls).
5. Self-hostable infrastructure — Signaling broker, static bundles, and TURN/STUN can be operated by the user or third parties.

1.2 Non-goals (v1 specification scope)

The following are out of scope for this specification version unless noted as future work:

• QR / offline manual signaling — Connection establishment via broker only (see Chapter 3).
• Interoperability with Signal, Matrix, or other clients — single implementation only.
• Formal compliance certification — No HIPAA/GDPR certification claims; privacy-by-design goals only (Chapter 7).
• Tor-native routing — WebRTC is not documented for Tor; see Chapter 11.
• Monetization or business model — Product FAQ covers project economics separately.

1.3 Product scope

This specification covers the Enkrypted Chat product surface, including features present in code (some experimental):

Feature area	Specification treatment
1:1 messaging	Core, normative
Group chat	Documented; partial / experimental
File sharing & OPFS	Documented; encryption at rest WIP
Document editor & calendar	Documented at architecture level
Voice/video calls	Documented; SFrame E2EE experimental
PWA / browser deployment	In scope
Tauri Android / desktop	Out of scope for current deployment

1.4 Terminology

Term	Definition
Peer	A browser instance identified by a peer ID and participating in WebRTC.
Peer ID	Opaque client-generated identifier used for signaling and routing; not a long-term cryptographic identity by itself.
Signaling server	PeerJS-compatible broker; relays SDP/ICE for connection setup only.
TURN relay	Relay server used when direct P2P fails; may see encrypted traffic and metadata.
Application ciphertext	Payload after cascading cipher encryption, before WebRTC framing.
Cascade / cascading cipher	Sequential application of multiple cipher layers (see Chapter 4).
MLS	Message Layer Security (RFC 9420); group-oriented protocol used as a cascade layer.
Signal Protocol	X3DH key agreement + Double Ratchet; implemented in Rust/WASM.
ML-KEM	Module-lattice KEM (post-quantum layer in cascade).
Semi-trusted	Infrastructure that must not learn plaintext but may learn metadata or deliver untrusted code if compromised.
TCB	Trusted computing base — here, the user’s browser/OS assumed for crypto execution.

1.5 Normative language

When this specification uses MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT, they are to be interpreted as described in RFC 2119.

1.6 Privacy-by-design principles

Positive Intentions designs Enkrypted Chat toward:

• Data minimization — No central archive of message plaintext.
• Purpose limitation — Infrastructure components used only for connectivity and static delivery, not analytics on message content.
• User control — Local storage, optional relay/TURN configuration, disablement of metadata-heavy features where implemented.
• Transparency — Open documentation of trust boundaries and known limitations.

These are design goals, not regulatory certifications.

2. Architecture and Trust

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

2.1 Design stance

Enkrypted Chat is not “serverless.” It is message-serverless: there is no central service that stores or decrypts conversation content. Limited infrastructure remains for signaling, NAT traversal, and static asset delivery. Honest documentation of those components is required for professional review.

2.2 High-level architecture

2.3 Layered stack (summary)

Layer	Responsibility
Presentation	React UI (ui, app shell)
Session / P2P	MLSProvider, PeerJS, WebRTC data channels
Application crypto	Cascading cipher + Signal WASM
Transport crypto	WebRTC DTLS, SRTP (media)
Local persistence	OPFS, IndexedDB (files, keys — at-rest encryption WIP)

Full encrypt order: Chapter 4. Transport detail: Chapter 3.

2.4 Module federation

Module Federation is central to the architecture. The chat shell dynamically loads:

• ui — Components (contacts, chat, QR connect UI, file browser, etc.)
• p2p — MLSProvider, messaging, calls, file transfer
• cryptography — MLS, Signal WASM, cascading cipher, SFrame managers

Implications:

• Runtime dependency on remote entry URLs (supply-chain risk).
• Version skew between shell and remotes MUST be managed in deployments.
• Self-hosting MUST include all federated entry points, not only the shell bundle.

See Decentralized architecture and Statics as infrastructure.

2.5 Trust boundaries

Component	Trust level	Rationale
Remote peer	Untrusted	Malicious peer may send invalid ciphertext; crypto must fail closed.
Signaling server	Semi-trusted	Sees peer IDs, SDP, ICE candidates, connection timing; MUST NOT receive message plaintext.
TURN relay	Semi-trusted	May see IPs, packet sizes/timing; in relay-mode carries ciphertext blobs only.
CDN / static host	Semi-trusted	Can serve trojaned JS if compromised; mitigated by self-host, CSP, SRI (Chapter 8).
Federation remotes	Semi-trusted	Same class as CDN for code integrity.
Browser / OS	TCB	Executes all crypto; spec assumes non-malicious browser.
Local storage (OPFS)	User-trusted	Protected by at-rest encryption when enabled (Chapter 6).

2.6 Infrastructure truth table

Component	Used today	Self-hostable	Carries message plaintext?
Signaling (PeerJS broker)	Yes	Yes	No
Static hosting (S3/CDN)	Yes	Yes	No (serves code only)
STUN/TURN	Yes	Yes (user keys)	No (encrypted payloads)
Central message store	No	N/A	N/A
Offline message relay	No (planned)	Planned	Future spec

2.7 Comparison: centralized vs Enkrypted Chat

Aspect	Centralized (e.g. Signal, WhatsApp)	Enkrypted Chat
Message routing	Through operator servers	Direct P2P when connected
Pre-key / async delivery	Server-backed	Requires both peers online (broker signaling only)
Operator metadata	Typically collected	Reduced for content; signaling/TURN metadata remains
Account system	Phone/email identity	Peer ID only (no registration server)
Video E2EE	Product-dependent	WebRTC + experimental SFrame layer

Extended comparison tables: Chapter 11 and migrated analysis in project audit materials.

2.8 Multi-device (partial prototype)

Multi-device sync is a partial prototype. The specification documents intended direction in Chapter 11; normative requirements for production multi-device are not defined in this draft.

3. Transport (WebRTC)

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

3.1 Overview

Enkrypted Chat uses WebRTC for peer connectivity. PeerJS wraps WebRTC for peer discovery and signaling. Application messages travel over encrypted data channels (SCTP over DTLS). Media for calls uses SRTP (DTLS-SRTP).

Application-level E2EE (cascade) is in addition to transport encryption, not a replacement.

3.2 Connection establishment (v1)

This specification documents online broker signaling only:

1. Each peer connects to a signaling server with its peer ID.
2. Caller initiates connection to callee’s peer ID via the broker.
3. Peers exchange SDP and ICE candidates through the broker.
4. WebRTC establishes a direct or relayed path.
5. Application keys and ciphertext are exchanged over the established data channel.

Out of scope for v1: QR-based or fully offline SDP exchange (implemented in UI components but not specified here per product direction).

3.3 ICE, STUN, and TURN

Mechanism	Role
STUN	Discovers server-reflexive addresses for NAT traversal
TURN	Relays traffic when direct P2P fails
ICE	Selects best candidate pair

Deployments MAY configure custom STUN/TURN servers. Default third-party TURN (e.g. metered.ca) is semi-trusted.

Relay-mode: When enabled, traffic may be proxied through TURN continuously. This improves connectivity but increases exposure to traffic analysis on the relay. Users MAY combine relay-mode with a trusted VPN as a hardening measure (user-operated, not provided by the app).

3.4 What the transport layer protects

Property	WebRTC transport	Notes
Confidentiality on wire	DTLS (data), SRTP (media)	Browser-dependent
Integrity	DTLS/SRTP
Forward secrecy (transport)	DTLS key agreement	Browser implementations vary
Hiding peer IPs	Partial	TURN/VPN may help; not guaranteed

Application plaintext MUST NOT be assumed protected by transport alone if application crypto is disabled (debug builds).

3.5 Signaling security

The signaling server:

• MUST NOT be relied upon to keep conversations confidential (it does not hold MLS/Signal keys).
• SHOULD be operated over HTTPS/WSS.
• SHOULD be self-hosted for high-threat users.

Compromise of signaling enables metadata analysis and MITM on connection setup unless peers verify out-of-band (future TOFU/QR work).

3.6 Tor, VPN, and anonymity

• Tor: WebRTC is generally unsuitable over Tor; treated as a non-goal for this product.
• VPN: Optional user hardening; does not replace E2EE.
• Onion routing: Listed as future investigation in project roadmap, not implemented.

3.7 Performance

No formal benchmarks are published in this draft. Latency depends on P2P path, TURN use, and cascade depth. Fast file transfer (optional) uses a dedicated data channel path documented in Chapter 6.

4. Application Encryption

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

4.1 Layered model

Enkrypted Chat applies encryption in two major planes:

1. Application cascade (this chapter) — MLS, Signal, ML-KEM, AES-GCM
2. WebRTC transport — DTLS/SCTP and SRTP (Chapter 3)

Production Enkrypted Chat (glitr-chat) enables the cascade with:

cipherLayers = ["MLS", "Signal", "ML-KEM", "AES"]
enableCascadingCipher = true
enableSignalProtocol = true

(Default in the p2p library module alone may differ; the product configuration above is authoritative for Enkrypted Chat.)

Normative profile name and layer table: P1. Wire serialization: P5.

4.2 Encrypt order

For a text message, CascadingCipherManager applies layers in array order (first layer innermost on plaintext):

Plaintext
  → MLS layer
  → Signal Protocol (Double Ratchet)
  → ML-KEM layer
  → AES-GCM layer
  → WebRTC data channel (DTLS)

This matches cipherLayers = ["MLS", "Signal", "ML-KEM", "AES"] in the Enkrypted Chat shell.

Decryption applies the reverse order. Each layer consumes the output of the previous layer as its input ciphertext.

Deep dives: Cascading cipher, P2P Signal Protocol, Quantum-resistant encryption.

4.3 Layer summaries

Layer	Role	Implementation notes
AES-GCM	Symmetric AEAD wrapper	Web Crypto API; keys from cascade key material
ML-KEM	Post-quantum KEM wrapper	CRYSTALS-Kyber / ML-KEM family; see quantum doc
Signal	Forward secrecy + break-in recovery	Rust core, WASM in browser; X3DH adapted for P2P
MLS	Group-oriented AEAD (RFC 9420)	Used as cascade layer; also supports group state

Signal implementation source: positive-intentions/signal-protocol (federated as cryptography module).

4.4 P2P Signal adaptations

Without a central pre-key server:

• Peers exchange key material during live WebRTC session setup (see Chapter 5).
• Asynchronous offline messaging is not provided by Signal’s server queue model.
• One-time prekeys are impractical in pure P2P; design relies on online handshake.

4.5 MLS and group chat

MLS appears in the cascade for 1:1 and group contexts. Group chat in the product is partial / experimental — UI and state exist, but reviewers MUST NOT assume production-grade group security until independently validated.

4.6 Security properties by layer

Property	WebRTC	AES	ML-KEM	Signal	MLS	Cascade (combined)
Confidentiality (payload)	Yes	Yes	Yes	Yes	Yes	Defense in depth
Integrity	Yes	Yes	Yes	Yes	Yes	Yes
Forward secrecy (message)	Partial (DTLS)	No alone	No alone	Yes	Epoch-based	Strongest from Signal/MLS
Post-quantum confidentiality	No	No	Intended	No	No	ML-KEM layer
Break-in recovery	Limited	No	No	Yes	Partial	Signal primary

This table describes design intent. No guarantee is implied without audit.

4.7 Cascading cipher — benefits and caveats

Rationale (defense in depth):

• Independent algorithms reduce reliance on a single primitive.
• Post-quantum layer hedges long-term confidentiality concerns.

Professional caveats (honest disclosure):

• Cryptographers often caution that naive cascade does not automatically multiply security and may increase attack surface and complexity.
• Implementation bugs in any layer can void theoretical benefits.
• This project treats the cascade as experimental pending independent review.

Enkrypted Chat documents both the intent and the controversy so reviewers can judge risk appropriately.

4.8 Video — SFrame (experimental)

The cryptography module includes SFrame support for frame-level media encryption in call demos. Status:

• Implemented in module code and stories.
• Not independently audited for production video E2EE claims.
• WebRTC SRTP still provides transport encryption; SFrame is an additional application-layer experiment.

4.9 Formal verification (summary)

In-house work applies ProVerif, Hax/F*, Rocq, and Lean to the Signal Protocol Rust core. Results are not a substitute for product-level audit. See Signal Protocol formal verification and Chapter 12.

5. Session and Identity

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

5.1 Identity model

Enkrypted Chat identifies peers with a peer ID:

• Generated client-side (cryptographically random, collision-resistant).
• Used for signaling registration and connection targeting.
• Not equivalent to a Signal-style stable identity key registered with a server.

Display names and local contacts are stored locally and are not authenticated by a global namespace.

5.2 Session establishment (broker path)

Normative handshake order, PDU types, and completion criteria are defined in:

• P3. Session establishment — ordered handshake steps
• P7. State machines — connection and crypto FSM

Summary: after the data channel opens, peers exchange MLS, Signal, and ML-KEM PDUs until encryptionReady; only then may encrypted message PDUs be sent.

5.3 Reconnection

See P3 §3.6 and P7 §7.4. WebRTC MUST be re-established; crypto state MAY resume if both peers retain local state.

5.4 Key rotation

• Signal ratchet: Per Signal Protocol (automatic per message).
• MLS: Epoch rotation on membership changes.
• AES layer: rotation-timestamp-broadcast PDU updates password suffix — see P4.

5.5 Out-of-order messages

Signal ratchet rules apply; chunk PDUs use chunkIndex. See P6 §6.5 and the Double Ratchet tutorial.

5.6 Trust on first use (TOFU)

Components exist for QR-assisted verification (TOFUVerification in p2p, ConnectByQRCode in ui). Not specified in v1 transport path. Future specifications may normative-bind QR payloads to identity keys.

5.7 Multi-device (partial prototype)

Multi-device profile sync is under development. This draft does not define:

• Cross-device key synchronization protocol
• Conflict resolution for concurrent sends

Status: partial prototype — see Chapter 11.

6. Messages and Attachments

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

6.1 Application message path

1. User plaintext composed in UI.
2. Serialized to an application envelope (JSON-based in current implementation).
3. Encrypted through the cascade (Chapter 4).
4. Sent over WebRTC data channel via MLSProvider / PeerJS.

6.2 Wire format

Normative PDU catalog and schemas: P4. PDU catalog.

Cascade envelope: P5. Cascade wire encoding.

Processing rules (encrypt/decrypt): P6. Processing rules.

Encoding: JSON UTF-8 on WebRTC data channels; every PDU has a type string. Profile: EnkryptedChat-Profile-v0 (single implementation; not an interoperability standard yet).

Peers MUST reject messages that fail decryption at any cascade layer (P6).

6.3 Text messages

Text messages use the full cascade when enableCascadingCipher is true in the product shell.

6.4 File transfer

Two paths exist:

6.4.1 Standard path (cascade + chunking)

• Files are split into chunks sized for data channel limits.
• Chunks are encrypted with the same cascade as messages.
• Reassembly occurs on the receiver.

Suitable when full application E2EE is required.

6.4.2 Fast file transfer (optional)

When enableFastFileTransfer is enabled:

• A optimized WebRTC data channel path may transfer file data with reduced or bypassed cascade overhead for performance.
• User toggles this in settings (persisted in localStorage).

Security tradeoff: Fast path prioritizes throughput over full cascade protection. The specification requires this behavior to be documented in UI and user-controlled.

6.5 Local files, OPFS, and editor

Enkrypted Chat stores files in OPFS (Origin Private File System) by default, with optional folder mount. Features include in-browser preview and document editing.

6.6 Encryption at rest (work in progress)

At-rest encryption is in active development. Intended design:

Element	Behavior
Data encryption key (DEK)	Cryptographically random, encrypts local vault
DEK wrapping	User unlock via passkey, passcode, or password
Recovery password	Generated at setup; user prompted to back up

Until shipped, local data MAY be stored without at-rest encryption depending on build flags — treat as high risk on shared devices.

6.7 Calendar and plan data

Calendar events are managed locally in the browser for the Plan feature. They inherit the same at-rest posture as other local app data.

6.8 Multimedia in chat

Images, video, and animations sent as chat attachments follow the file/message paths above. Large media SHOULD prefer chunked standard path unless user enables fast transfer.

7. Metadata and Privacy

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

7.1 What this chapter covers

Metadata is data about communication, not the message plaintext. Enkrypted Chat minimizes metadata where practical but cannot eliminate all leakage in a WebRTC + broker architecture.

7.2 Metadata inventory

Metadata	Who may observe	Intentional?	Mitigation
Peer IDs	Signaling server, peers	Required for connectivity	Random IDs; self-hosted broker
IP addresses	TURN, peers, ISP	Unavoidable for WebRTC	VPN (user); TURN policy
Connection times / online	Peers, possibly broker	Partially unavoidable	—
SDP / ICE details	Signaling server	Required for setup	WSS, self-host
Message timing & size	Network, TURN in relay mode	Unavoidable	Padding (future); traffic analysis awareness
Typing indicators	Peers if enabled	Optional feature	Disable where implemented
Read receipts	Peers if enabled	Optional feature	Disable where implemented
Static asset fetch logs	CDN operator	Unavoidable for web delivery	Self-host bundles
Analytics (if enabled)	Site operator	Product-dependent	Documented separately

7.3 Intentional vs unavoidable

• Intentional (product choices): Optional UX metadata (typing, read receipts), federated module telemetry if configured, nLevel analytics on website (see deployment docs).
• Unavoidable (protocol): IP exposure, traffic timing, signaling presence while connected to broker.

7.4 Privacy-by-design and regulation

Positive Intentions aligns design with common privacy principles:

Principle	How architecture supports it
Data minimization	No central message archive
Purpose limitation	Brokers used for connectivity, not content mining
Storage limitation	Ephemeral sessions; local persistence user-controlled
Integrity & confidentiality	Layered E2EE (experimental, unaudited)
Transparency	This specification and public docs

GDPR / CCPA / HIPAA: Mentioned as design alignment only. Enkrypted Chat is not certified for regulated health or enterprise compliance. Organizations MUST perform their own DPIA and legal review before use.

7.5 Comparison to “no metadata” claims

Marketing language implying zero metadata is inaccurate for this system. Accurate statement:

Message content is not stored on Positive Intentions message servers because none exist; metadata may still be visible to peers, relays, signaling operators, and network observers.

7.6 User controls

Users SHOULD:

• Self-host signaling and static assets when threat model requires it.
• Configure trusted TURN servers; understand relay-mode implications.
• Disable optional metadata features where available.
• Not clear site data without backing up recovery material (when at-rest encryption ships).

8. Deployment and Supply Chain

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

8.1 Deployment model

Enkrypted Chat ships as static assets:

• HTML shell and federated remoteEntry.js files hosted on S3/CDN (or equivalent).
• Browsers download and execute JavaScript at runtime.
• No application server processes user messages.

Supported deployment targets today: browser and PWA. Tauri/Android builds exist in development but are outside this specification’s deployment claims.

8.2 Module federation topology

A complete deployment MUST publish:

Remote	Typical role
Chat shell (glitr-chat / chat)	Host application
ui	Shared React components
p2p	WebRTC + MLSProvider
cryptography	MLS, Signal WASM, cascade, SFrame

All remotes MUST be version-compatible. Mismatched versions MAY break encryption handshakes.

See Statics as a chat app infrastructure.

8.3 Signaling and TURN

Operators SHOULD deploy:

• PeerJS-compatible signaling over WSS
• STUN/TURN with credentials under operator control

Default public TURN endpoints are convenient but semi-trusted.

8.4 Supply-chain controls

Normative requirements (deployers)

Control	Requirement
HTTPS	Static and signaling MUST be served over TLS in production
Self-host option	Deployers SHOULD offer self-hosted bundle mirrors for high-threat users
CSP	Deployments SHOULD use a strict Content-Security-Policy limiting script origins
SRI	Deployments SHOULD use Subresource Integrity on static scripts where federation allows
Update transparency	Product SHOULD provide explicit control to fetch or pin static versions (roadmap)

Recommendations (users)

• Verify hosting origin before entering sensitive data.
• Prefer self-hosted or known-good mirrors.
• Clear browser data only after backing up recovery secrets (when at-rest encryption is enabled).

8.5 Service workers and offline statics

Investigation continues for service-worker-cached statics and offline use. Not normative in this draft.

8.6 Multicloud / redundancy

Architecture goal: multiple static mirrors (multicloud) so one CDN outage does not brick the app. Implementation is ongoing — see decentralized architecture.

8.7 JavaScript delivery concerns

Because security logic runs in the browser:

• Compromise of hosted JS equals full compromise of sessions.
• Obfuscation (used in some builds) is not a security control.

This is documented openly for professional reviewers evaluating browser-based E2EE.

9. Threat Model

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

9.1 Purpose

This chapter is the canonical threat model for Enkrypted Chat on the website. It supersedes informal “zero server” claims and consolidates themes from in-house security-audit and threat-model materials in the p2p repository.

9.2 Adversaries in scope

Adversary	Capability	In scope
Passive network observer	Traffic analysis, metadata	Yes
Active network attacker	MITM on non-crypto paths	Yes
Malicious peer	Send malformed ciphertext, protocol abuse	Yes
Compromised signaling server	SDP/ICE manipulation, presence tracking	Yes
Malicious CDN / federated host	Serve trojaned JavaScript	Yes
State-level / APT	Resource-rich compromise	Yes (design consideration)

9.3 Primary assets

Asset	Sensitivity	Loss impact
Message plaintext	Critical	Confidentiality breach
Signal/MLS private keys	Critical	Session compromise
File contents	Critical	Data exfiltration
Local OPFS vault	High	Device compromise
Peer IDs & contact graph	Medium	Metadata deanonymization
Federated module integrity	Critical	Full platform compromise

9.4 Threat scenarios and mitigations

9.4.1 Signaling MITM

Threat: Attacker on signaling path substitutes SDP to redirect media/data to themselves.

Mitigations:

• Use WSS and trusted self-hosted broker.
• Future: bind identity keys to signaling (TOFU/QR — not v1 spec).
• Application E2EE limits impact on content if session keys already established; initial handshake is highest risk.

9.4.2 Malicious JavaScript supply chain

Threat: CDN or federation host serves backdoored bundle.

Mitigations:

• Self-host all remotes (Chapter 8).
• CSP, SRI where applicable.
• Subresource integrity review on deploy.

9.4.3 Malicious peer

Threat: Peer sends invalid frames to crash or confuse parser.

Mitigations:

• Strict decryption failure handling (no plaintext on error).
• Input validation on envelopes.
• Fuzzing and audit (planned).

9.4.4 TURN traffic analysis

Threat: Relay operator correlates timing and volume.

Mitigations:

• Direct P2P when possible.
• User-operated TURN.
• VPN (user responsibility).

9.4.5 Local device compromise

Threat: Malware reads OPFS or memory keys.

Mitigations:

• At-rest encryption (WIP).
• OS-level device security (out of app scope).

9.5 STRIDE summary

Category	Example	Control
Spoofing	Fake peer ID on broker	Peer ID is not authenticated globally — limitation
Tampering	Ciphertext bit flip	AEAD at cascade + transport
Repudiation	Deniable messages	Signal-style deniability (layer-dependent)
Information disclosure	Metadata at TURN	Disclosure + user config
Denial of service	Flood data channel	Rate limits (partial)
Elevation	N/A browser sandbox	Browser isolation

9.6 Audit and verification status

• Independent security audit: Not yet completed; arrangements in progress.
• In-house audit docs: Available in p2p/security-audit/ (engineering reference).
• Formal verification: Signal core — see formal verification; does not cover full web stack.

9.7 Residual risk statement

Even if all mitigations work as designed, Enkrypted Chat MAY NOT protect against:

• Compromised endpoint (browser extension, malware)
• Sophisticated traffic analysis on TURN/VPN exit
• Social engineering of peer IDs
• Undiscovered implementation vulnerabilities

Users with high-threat models SHOULD wait for independent audit results or deploy self-hosted infrastructure with expert review.

10. Implementation Map

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

10.1 Repositories → normative sections

Repository	Role	Spec sections
glitr-chat	Enkrypted Chat shell — cascade enabled	P1.3, ch. 1–2
p2p	MLSProvider, messaging, files, calls	P3–P8, P4
ui	Shared UI, QR connect	ch. 5 (product)
chat	Security reporting, related apps	P1.8, SECURITY.md
signal-protocol	Rust Signal core, WASM	Appendix B
cryptography	MLS, cascade, SFrame	P5, Appendix A
website	This specification	CHANGELOG-SPEC

10.2 Key implementation files

Concern	Location
Product cascade config	glitr-chat/src/providers/P2PProvider.tsx
WebRTC + encryption core	p2p/src/core/MLSProvider.tsx
File transfer / fast path	p2p/src/features/filetransfer/
Group state	glitr-chat + p2p group members state
QR connect UI	ui/src/components/molecules/ConnectByQRCode/
Security audit notes	p2p/security-audit/

10.3 Public APIs

Enkrypted Chat does not expose a stable external SDK or public integration API. The specification describes behavior, not a supported third-party contract.

10.4 Test vectors

See Appendix A:

• cryptography — golden-vectors.test.js (V1, V2), cascading-cipher-manager.test.js
• p2p — protocol-golden-vectors.test.js (V4–V7), MLSProvider.*.test.tsx
• signal-protocol — WASM / ratchet tests

Golden hex V1–V7 are published; live cascade V8 deferred to Profile-v1.

10.5 Build and delivery

• Webpack Module Federation for remotes
• Production builds may apply JavaScript obfuscation (does not affect spec semantics)
• Android/Capacitor scripts exist in glitr-chat but are not production-targeted in this spec

11. Limitations and Roadmap

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

11.1 Mandatory limitations (read before use)

The following MUST be understood by any professional evaluator:

1. No independent security audit of the full product stack.
2. Experimental / WIP software — not a replacement for Signal, WhatsApp, or enterprise messengers.
3. No offline messaging — both peers must be online for delivery (relay planned, not specified).
4. Broker dependency for v1 — QR/offline signaling not in this spec.
5. Group chat partial — do not rely on group security guarantees.
6. Browser JS trust model — hosted bundle compromise equals full compromise.
7. Metadata remains — peer IDs, timing, TURN/signaling exposure (Chapter 7).
8. Cascading cipher controversy — defense-in-depth intent vs expert caution (Chapter 4).
9. Fast file transfer — optional reduced protection path.
10. At-rest encryption — not complete.
11. SFrame video E2EE — experimental, not audit-backed.
12. No interoperability with other clients.
13. Tor unsupported for WebRTC.

11.2 Use cases (from product vision)

Enkrypted Chat is intended for:

• Privacy-conscious individuals exploring P2P messaging
• Researchers studying P2P + Signal adaptations
• Developers evaluating modular federated architecture
• Organizations prototyping self-hosted secure comms (with their own legal/security review)

It is not positioned today for regulated healthcare, government classified comms, or high-risk journalism without additional review.

11.3 Competitive positioning (summary)

Platform	Architecture	E2EE messaging	True P2P payload path	Notes
Enkrypted Chat	P2P + broker + static CDN	Cascade + WebRTC	Yes (when connected)	Experimental, unaudited
Signal	Centralized server	Signal Protocol	No (server relay)	Mature audit culture
Matrix/Element	Federated homeservers	Olm/Megolm	No	Server stores ciphertext
Briar/Session	P2P / onion variants	Various	Strong P2P focus	Different stack
WhatsApp	Centralized	Signal-derived	No	Metadata to Meta
Zoom/Meet	Centralized SFU	Variable	No	Enterprise focus

Strategic tradeoff: Enkrypted Chat sacrifices convenience (online-only, setup complexity) for reduced central message custody.

11.4 Thematic roadmap (not dated)

Future work themes (no commitment dates):

• Independent security audit
• Offline / self-hosted message relay
• Multi-device decentralized profile
• Encryption at rest (passkey/passcode/password wrapping DEK)
• Self-destructing messages
• Improved group messaging
• Multicloud static redundancy
• Service worker static pinning
• Onion routing investigation (non-Tor WebRTC constraints)
• Expanded formal verification coverage

11.5 Vision

Long-term direction: a browser-based, user-sovereign communication suite (messaging, files, documents, calendar) with minimal central custody of content, transparent security documentation, and optional self-hosting at every infrastructure tier.

Progress is incremental; this specification will be revised as implementations mature and audits complete.

11.6 Profile-v1 protocol checklist (next implementation steps)

Before labeling EnkryptedChat-Profile-v1, the project MUST complete:

Step	Deliverable	Status
1	Golden hex test vectors (handshake, cascade mock, MLS fallback, chunk math)	Done — Appendix A; golden-vectors.test.js, protocol-golden-vectors.test.js
2	Live MLS+Signal+ML-KEM+AES hex (V8)	Deferred — Profile-v1
3	Implement type: "protocol-error" on decrypt/oversize/unknown-type paths	Done — p2p/src/utils/protocolError.ts
4	Mandatory specVersion: "1.0" on all PDUs	Pending
5	Freeze PDU schemas (no breaking required fields)	Pending
6	Independent security audit or documented waiver	Pending

Completed in documentation pass (v0): P0 rationales, Appendix B/C, full PDU field reference in P4.13, formal security matrix, broker compromise list, recommended timeouts.

Not planned near-term (per product decision): Broker token/mTLS signaling auth — roadmap only (P2.9).

12. References

Work in progress — not audited

This chapter is part of an initial draft specification. Enkrypted Chat has not been independently audited. Content may change.

12.1 Standards and specifications

Reference	Topic
RFC 2119	Key words for requirements
RFC 8825–8829	WebRTC architecture
RFC 9420	Message Layer Security (MLS)
Signal specifications	X3DH, Double Ratchet
NIST ML-KEM	Post-quantum KEM (FIPS 203)

12.2 Protocol specification (normative)

Document	Description
Protocol gap analysis	vs Noise / WireGuard
P1–P8	EnkryptedChat-Profile-v0
Appendix A	Test vectors

12.3 Positive Intentions documentation

Document	Description
P2P Signal Protocol	P2P adaptations for Signal
Cascading cipher encryption	Cascade design
Signal Protocol formal verification	ProVerif, Hax, etc.
Quantum-resistant encryption	ML-KEM layer
Decentralized architecture	PWA + federation
P2P messaging breakdown	Feature status
Enkrypted Chat FAQ	Product Q&A

12.4 Tutorials (on-site)

• Signal Protocol tutorial
• MLS Protocol tutorial
• Cascading cipher tutorial
• ML-KEM tutorial

12.5 Blog posts (positive-intentions.com)

• Decentralised architecture
• Statics as a chat app infrastructure
• Introducing Enkrypted Chat
• Cascading cipher

12.6 Source repositories

• github.com/positive-intentions/chat
• github.com/positive-intentions/p2p
• github.com/positive-intentions/ui
• github.com/positive-intentions/signal-protocol
• github.com/positive-intentions/cryptography

12.7 Security reporting

• GitHub Security Advisories — chat repo

12.8 In-house audit material (engineering)

The p2p repository contains security-audit/ and security-audit/whitepaper/ drafts. This website specification rewrites those drafts for accuracy (layered crypto, infrastructure truth). Raw audit files remain useful for engineers but may contain outdated MLS-primary language.

12.9 Research and community threads

Selected external discussions linked from project docs (Reddit, etc.) appear in P2P messaging breakdown and FAQ — consult those pages for evolving community feedback; they are not normative.