Security Architecture
How Veiled protects your conversations. Technically.
Last Updated: February 10, 2026
Design principle: Security through architecture, not promises. Every protection described here is verifiable in our open-source codebase.
1. Encryption
End-to-End Encryption (E2EE)
All direct messages and private channels use end-to-end encryption. Messages are encrypted on your device before transmission and can only be decrypted by intended recipients. Veiled servers handle ciphertext only — we are mathematically unable to read your messages.
Transport Security
All connections use TLS 1.3 with strong cipher suites. Certificate pinning is implemented in official clients to prevent MITM attacks.
At-Rest Encryption
The minimal metadata we do retain (account keys, channel membership) is encrypted at rest using AES-256. Database encryption keys are managed through hardware security modules (HSMs) where available.
2. Architecture
Veiled's security model is layered:
Layer 1: Network Edge
IP addresses are stripped at the network boundary. Connection metadata is not logged. Rate limiting and DDoS protection operate without identifying individual users.
Layer 2: Authentication
Accounts are identified by cryptographic keypairs, not personal information. Authentication uses challenge-response protocols — your private key never leaves your device. There are no passwords to breach.
Layer 3: Message Handling
Messages transit our servers as encrypted blobs. They are routed to recipients and then purged. We do not maintain message archives. Server-side code has no access to decryption keys.
Layer 4: Client Safety
Client-side CSAM hash matching runs locally on your device against known databases. Matches are reported through our NCMEC pipeline. No scanning of message content occurs server-side.
3. What We Protect Against
- Mass surveillance — E2EE and zero data retention mean bulk collection yields nothing
- Data breaches — You can't leak data you don't store
- Insider threats — Server-side code cannot access message content
- Network eavesdropping — TLS 1.3 + certificate pinning
- Account takeover — Keypair auth eliminates credential stuffing
- Metadata analysis — Minimal metadata, encrypted at rest
4. What We're Honest About
No system is perfect. Here's what we acknowledge:
- Metadata exists — We minimize it, but message timing and channel membership are necessary for routing. We encrypt this data, but it exists.
- Client-side trust — E2EE means your device is the trust boundary. If your device is compromised, encryption cannot help. Use device-level security.
- Self-hosted variance — We control our infrastructure. Self-hosted instances may have different security properties depending on the operator.
- Targeted attacks — We defend against mass surveillance and opportunistic attacks. State-level actors with physical device access are beyond any platform's protection.
5. Child Safety Architecture
Our approach to child safety is designed to be effective without compromising user privacy:
Client-Side Hash Matching
Before any image is transmitted, the client computes a perceptual hash and checks it against a locally-stored database of known CSAM material hashes (provided by NCMEC/PhotoDNA). Matches are blocked from sending and flagged for reporting.
Reporting Pipeline
Veiled maintains a mandatory reporting pipeline to NCMEC as required by 18 U.S.C. § 2258A. Reports include only the minimum information necessary and are transmitted through secure channels.
Moderation Tools
Server owners have access to robust moderation tools including role-based permissions, content filters, audit logs (visible only to server admins), and user reporting mechanisms.
6. Open Source Audit
Every security claim on this page can be verified by inspecting our source code. We encourage:
- Independent security audits — We will publish all audit results
- Bug bounty program — Responsible disclosure is rewarded (coming soon)
- Community review — Our AGPL-3.0 license ensures the code remains inspectable
7. Incident Response
In the event of a security incident:
- We will notify affected users within 72 hours
- We will publish a full postmortem including root cause analysis
- We will detail the remediation steps taken
- All incident reports will remain permanently available
8. Responsible Disclosure
Found a vulnerability? We want to hear from you.
- Email: security@veiled.chat (coming soon)
- We ask for 90 days responsible disclosure
- We will credit researchers (with permission) in our security advisories