Security

This page is the honest version of Chatalot’s security posture: what is protected, what isn’t, and how to report a problem. No “military-grade” language, no certifications we don’t hold, no claims we can’t back up.

Cryptographic architecture

End-to-end encryption

Direct messages, group messages, and channel messages use the Signal protocol:

• X3DH (Extended Triple Diffie-Hellman) for initial key agreement
• Double Ratchet for per-message forward secrecy and post-compromise recovery
• Sender Keys for group messaging efficiency
• EdDSA identity keys for long-term authentication

The cryptography runs client-side, compiled to WebAssembly. The server cannot read plaintext message content because it never holds the decryption keys. This is an architectural property, not a policy promise.

E2EE scope

Within a Chatalot instance, content moves through three rough zones:

1. End-to-end encrypted, server cannot read — direct messages, group messages, channel messages, voice and video media (DTLS-SRTP), and file attachments to encrypted messages.
2. Server-readable but encrypted at rest — TOTP secrets (ChaCha20-Poly1305 with a per-instance key), sessions, password hashes (Argon2id; the password itself is unrecoverable).
3. Server-readable plaintext — metadata (sender, recipient, timestamps, sizes), account identifiers, role assignments, webhook payloads, the current server-side search index.

If the bottom row matters to your threat model, read the disclosed limitations below before deploying.

Key verification

Every conversation surfaces a fingerprint. Users compare it out of band to confirm they’re talking to who they think they’re talking to. Chatalot uses trust-on-first-use by default; identity-key changes raise a visible warning in the conversation UI. Fingerprint match is the authoritative signal — UI affordances are convenience, the cryptographic identity is the truth.

Passwords

Hashed with Argon2id (time=3, memory=64 MB) before storage. The plaintext never touches disk and is wiped from memory after authentication. Password recovery is not possible — admins can reset, they cannot read.

Two-factor authentication

TOTP per RFC 6238. Secrets are encrypted at rest with ChaCha20-Poly1305 using a per-instance key held in secrets/. A database breach without the encryption key yields useless ciphertext.

Transport

TLS for all HTTP and WebSocket traffic, HSTS enforced, modern cipher suites only. WebRTC media uses DTLS-SRTP.

Disclosed limitations

The security story is only useful if it’s accurate. Chatalot publishes the following honest gaps and the work tracked against each.

Webhook plaintext (CHAT-9)

Inbound webhook payloads — alerts from monitoring tools, CI status, third-party integrations — are stored as plaintext in the database. The sender is not a Chatalot client and cannot participate in the E2EE handshake, so end-to-end encryption is structurally impossible for that path. CHAT-9 tracks a hardening proposal where webhook content is encrypted to a per-channel key the server still has access to, narrowing exposure to a single channel rather than the whole database. Until that ships, treat webhook content as plaintext that the server admin can read.

Server-side search (CHAT-8)

Full-text search currently runs against a server-side index. A WASM client-side search rebuild is in design as CHAT-8. Until that lands, an operator with database access can read indexed message text. The encrypted message bodies on disk remain ciphertext; the search index is the leak.

Message metadata

Routing requires the server to see who is messaging whom and when. Metadata privacy requires a different protocol family (onion routing, mixnets) and Chatalot does not currently claim it. If metadata is in your threat model, Chatalot is not the right fit alone — pair it with a network-layer privacy tool.

File uploads outside E2EE messages

Files attached to encrypted messages are themselves encrypted. Files uploaded to other contexts (e.g., webhook media, profile assets) are stored unencrypted server-side with filesystem access controls.

Release signing

Every release manifest and container image is signed with cosign.

• Private signing key — held offline by the maintainer. It does not live on any server, in any container, or in any CI runner. Releases are signed on a workstation; the workstation does not autonomously push.
• Public verification key — published at the updates origin and SHA-256 pinned by every client at build time. Clients refuse to apply an update whose signature does not verify against the pinned key.
• Verification on every install and every update — the managed updater verifies signature before extracting the bundle, before swapping containers, before considering the update applied. A compromised distribution channel cannot deliver a malicious release without also compromising the offline signing key.

The pinned public key for the current release line:

URL:     https://updates.seglamater.app/.well-known/keys/chatalot.pub
SHA-256: f1ff3f7ff3a1a7fe53620bbd8db0e362e55dcf622780e271740bc27d1850d082

To verify on your own machine:

curl -s https://updates.seglamater.app/.well-known/keys/chatalot.pub | sha256sum

The output should match the SHA-256 above. If it does not, do not use the key.

Audit trail

• The Chatalot source code is open. Once the GitHub mirror is public, every commit, every release tag, and every signed artifact is verifiable end to end.
• Release manifests are immutable once published — channel files at https://updates.seglamater.app/chatalot/channels/<channel>/latest.json are append-only in version history; a rollback is a new manifest, not an edit.
• Managed-tier customers can request a signed bill of materials for any deployed version.

Chatalot has not yet had an independent third-party cryptographic audit. The protocol implementation follows the published Signal specifications, the code is open for review, and an external audit is planned once the protocol surface stabilizes.

Reporting a vulnerability

Please do not open a public issue for security bugs.

• Email: security@seglamater.com is the disclosure channel. We'll acknowledge within one business day and keep you informed on remediation timing. Encrypted disclosure on request — reach out via email first.

What to expect

• Acknowledgment within 48 hours.
• Coordinated disclosure timeline agreed before any public announcement.
• Credit in the release notes if you wish.

What to include

• Description of the vulnerability and potential impact.
• Steps to reproduce.
• Affected versions, if known.
• Any suggested mitigations.