Security

This page describes what Chatalot protects, what it doesn't, and how to report problems responsibly. Honest disclosures — no marketing claims about "military-grade" anything.

Cryptographic architecture

End-to-end encryption

Direct messages and group channels 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

Cryptography runs client-side, compiled to WebAssembly. The server cannot read plaintext message content because it never holds the decryption keys.

Key verification

Every conversation exposes a fingerprint users can compare out-of-band. Chatalot uses trust-on-first-use (TOFU) by default; identity-key changes trigger a visible warning in the conversation UI. Fingerprint comparison is the authoritative signal — if it matches, you're talking to who you think you are.

Passwords

Passwords are hashed with Argon2id (time=3, memory=64MB) before storage. The server stores only the hash; the plaintext password never touches disk and is discarded from memory after authentication. Nobody can recover a forgotten password — admins can reset it, but cannot read it.

Two-factor authentication

TOTP (RFC 6238) is supported. Secret values are encrypted at rest with ChaCha20-Poly1305 using a per-instance key. An admin who breaches the database without also holding the encryption key gets useless ciphertext.

Transport

All HTTP and WebSocket traffic terminates at TLS. The server enforces HSTS; modern TLS suites only (no legacy cipher fallbacks). WebRTC voice/video uses DTLS-SRTP.

What Chatalot does NOT protect

End-to-end encryption covers message content between two users or within a group. The following are explicitly NOT end-to-end encrypted:

• Webhook messages. Incoming webhook payloads are stored as plaintext in the database. If your workflow posts secrets via webhooks, that's a plaintext exposure the server admin can see. (Tracked for future hardening.)
• Message metadata. Sender, recipient, timestamp, and size are visible to the server. This is fundamental to how the server routes messages; metadata protection would require a different protocol (e.g., onion routing).
• Account identifiers and roles. Your username, email (if provided), and role assignments are cleartext in the database.
• File uploads. Uploaded files are stored unencrypted server-side (with filesystem-level access controls). End-to-end encryption of files is a planned feature.

These are architectural limits documented honestly rather than hidden behind "fully encrypted" marketing. Future releases narrow these gaps where feasible.

Reporting a vulnerability

Please do not open a public issue for security bugs. Instead:

• GitHub Security Advisories (preferred): use the Security Advisories tab to report privately.
• Email: seglamater@pm.me

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.

Release signing

Every Chatalot release manifest and container image is signed with cosign. The public key is published at /.well-known/keys/chatalot.pub (SHA-256 f1ff3f7ff3a1a7fe53620bbd8db0e362e55dcf622780e271740bc27d1850d082). Clients verify signatures before pulling an update; a compromised distribution channel cannot deliver a malicious release without the signature check failing.

Independent review

Chatalot has not yet had an independent third-party cryptographic audit. The code is open for community review and scrutiny is welcome. Planned: commission a cryptographic audit once the protocol and E2EE implementation stabilize.