Enkrypted Chat — Technical Specification
This specification is an initial draft by Positive Intentions. Enkrypted Chat is experimental software: it has not been independently audited or professionally reviewed. Do not rely on it for sensitive communications or production use. Features described here may be partial, unstable, or change without notice.
Document status: Initial draft (informal v0.1)
Product: Enkrypted Chat
Organization: Positive Intentions
Abstract
Enkrypted Chat is a browser-based, peer-to-peer messaging application. Users connect directly over WebRTC; a lightweight signaling broker (PeerJS-compatible, self-hostable) helps establish connections but does not carry message plaintext. Above the transport layer, the product applies a cascading application cipher—combining MLS, the Signal Protocol (X3DH + Double Ratchet via Rust/WASM), ML-KEM (post-quantum layer), and AES-GCM—so that compromise of one layer does not automatically expose content.
The system is built as federated microfrontends (Webpack Module Federation): shared UI, P2P, and cryptography modules load at runtime into the main chat shell. Static assets are served from commodity hosting (e.g. AWS S3/CDN); users may self-host bundles to reduce supply-chain risk.
This document is a hybrid specification: a readable overview for decision-makers, plus normative technical sections (RFC 2119 keywords where stated) for security researchers and engineers.
Executive summary
Centralized messengers route traffic and metadata through operator-controlled servers. Enkrypted Chat targets a different tradeoff: direct browser-to-browser delivery for message payloads, with encryption applied in layers from application code down to WebRTC’s DTLS/SCTP protections.
| Property | Enkrypted Chat approach |
|---|---|
| Message path | P2P over WebRTC data channels (when connected) |
| Application E2EE | Cascading cipher: MLS → Signal → ML-KEM → AES (configurable) |
| Transport E2EE | WebRTC (DTLS, SRTP for media) |
| Identity | Client-generated peer IDs (no account server) |
| Infrastructure | Signaling broker, STUN/TURN, static CDN — semi-trusted, not message stores |
| Audit status | No independent audit; in-house analysis and formal verification work in progress |
Who should read this
- Security researchers and cryptographers evaluating design and limitations
- CTOs and architects comparing P2P vs centralized models
- Policy and investor audiences needing an accurate (non-marketing) system description
Prerequisites for deep chapters
If you are new to Diffie–Hellman, X3DH, or the Double Ratchet, start with:
Document map
| Chapter | Topic |
|---|---|
| Full protocol spec (print / PDF) | All normative protocol chapters on one page for PDF export |
| Full whitepaper (print / PDF) | All product chapters (1–12) on one page for PDF export |
| Protocol spec gap analysis | Comparison to Noise / WireGuard; auditor checklist |
| CHANGELOG-SPEC | Specification revision history |
| Protocol (normative) | |
| P0. Design rationales | Why JSON, cascade order, scope |
| P1. Protocol overview and profile | EnkryptedChat-Profile-v0 |
| P2. Signaling | Broker / WSS |
| P3. Session establishment | Handshake order |
| P4. PDU catalog | JSON type schemas |
| P5. Cascade wire encoding | cascadedPayload |
| P6. Processing rules | Encrypt / decrypt MUSTs |
| P7. State machines | Connection + crypto FSM |
| P8. Limits and errors | Sizes, failures |
| Appendix A. Test vectors | Conformance references |
| Appendix B. P2P Signal deltas | Normative vs standard Signal |
| Appendix C. Glossary | Terms |
| Appendix D. SFrame (WIP) | Informative media encryption |
| Product specification | |
| 1. Goals and terminology | Scope, definitions, non-goals |
| 2. Architecture and trust | Components, trust boundaries, module federation |
| 3. Transport (WebRTC) | PeerJS, ICE, STUN/TURN, broker-only connection |
| 4. Application encryption | Cascade order, layers, properties table |
| 5. Session and identity | Peer IDs, P2P Signal handshake |
| 6. Messages and attachments | Wire format, files, fast transfer |
| 7. Metadata and privacy | What leaks, privacy-by-design |
| 8. Deployment and supply chain | Hosting, CSP, self-host |
| 9. Threat model | Adversaries, mitigations |
| 10. Implementation map | Repositories and modules |
| 11. Limitations and roadmap | Honest gaps, future work |
| 12. References | RFCs, blogs, related docs |
Related documentation
This specification does not replace existing technical pages. Use them for implementation depth:
- Decentralized architecture
- P2P messaging technical breakdown
- Signal Protocol formal verification
- Enkrypted Chat FAQ
Security disclosure
Report vulnerabilities via GitHub Security Advisories on the positive-intentions/chat repository. There is no formal bug bounty at this time.
PDF / print version
The specification is split across multiple pages in the sidebar. To save a single PDF for each part:
Protocol spec
- Open Full protocol spec (print / PDF) — gap analysis, P0–P8, and appendices on one page.
- Click Print / Save as PDF (or use the browser menu: File → Print).
- Choose Save as PDF as the destination.
- Enable Background graphics so Mermaid diagrams print correctly.
Whitepaper
- Open Full whitepaper (print / PDF) — chapters 1–12 on one page.
- Follow the same print steps as above.
Locally: run npm run start in the website repository, then open
http://localhost:3000/docs/technical/whitepaper/complete-protocol-spec or
http://localhost:3000/docs/technical/whitepaper/complete-whitepaper.
Printing individual chapter pages will produce separate documents; use the complete pages for a single file per section.