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.