Skip to main content

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:

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.