Skip to main content

Identity and pairing

Research, not an audit
These pages are research and development and may not match the live app. Do not treat this as an audit. Shared for testing and demo only. Please use responsibly.

How a person becomes a contact, how a second device joins, and which secrets move while that happens.

Trust on first use​

A new live peer sends ChatFrame::Hello. The receiver calls POST /peer/hello. evaluate_hello returns Store, Match, or Mismatch.

Safety numbers are SHA-256 over both sides’ RSA public key and protocolBundles (GLITR-2026-015).

GLITR-2026-019 — hello Match/Store → active​

Info

On Store or Match, promote_contact_active_after_hello sets connectionStatus: active and binds peerProfileId when provided. Git send and live send then share the same gate. Mismatch still surfaces the safety number and does not auto-accept.

Contact details (GUI and TUI) expose a Keys section: current safety number, accept/reject on mismatch (POST /peer/accept-key, which also clears the sealed ProtocolSession), and mutual live session rotate over Tor/WebRTC (ChatFrame::sessionRotate with both-peer confirm, then POST /peer/reset-session and a sealed re-handshake). Rotate is live-only; the safety number is unchanged unless identity material changes.

GLITR-2026-009 — plaintext invites​

Accepted

wu1: and on1: are QR or paste and are not cascaded.

GLITR-2026-015 — safety numbers​

Info

Positive control: hello mismatch surfaces a number derived from RSA SPKI and protocolBundles.

Fixes: Remediation. Catalog: Findings.