ChatVia Security: Encryption at Rest & the v1.0 Model

ChatVia is pre-launch. This page describes exactly what the current system does today, with a separate, explicit description of what ships at v1.0 and an independent third-party audit at v1.0 to verify it. We'd rather be specific about the gap between today and launch than write a stronger promise than the system currently backs.

How to read this page. Each section is tagged today (what the current system does) or v1.0 (what ships at public launch). A third-party cryptographic and infrastructure audit is on the v1.0 plan; its report will be published in full on this page when it lands.

Where ChatVia is today

Today, ChatVia stores message data on India-resident infrastructure, encrypted at rest with AES-256-GCM. Transport between your device and the API is TLS-protected. Authentication uses signed JWT access tokens with refresh tokens stored in your OS's secure storage.

Today, ChatVia operators retain technical access to message contents for incident response. That means a court order under Indian law could, in principle, compel us to produce message data. We mention this not because we plan to (we don't) but because the architecture today does not yet make that compulsion mathematically impossible, and you deserve to know what posture you're actually trusting.

Permanence is the default: your full chat history lives on the server, encrypted at rest, and rehydrates automatically when you sign in on a new device. Deletion is your call. Anything you permanently delete is permanently deleted server-side.

What ships at v1.0

Before public launch, the following land. These are the commitments we will be measured against, and what the third-party audit will be against:

End-to-end encryption with per-conversation keys. Each conversation gets a unique symmetric key (AES-256-GCM), derived on your device and never seen by our servers in plaintext form. The infrastructure for this (X25519 ECDH wrapping, key versioning, per-conversation AAD) is already in the backend; the client wiring to use it as the default path lands in v1.0.
No operator access to message content. Once the per-conversation key path is the only path, ChatVia operators lose the technical ability to read message contents. Only metadata (who you message, when, from which devices) remains producible under legal process.
Third-party cryptographic and infrastructure audit. An external review of the encryption and infrastructure model, with the report published in full on this page.
Transparency report. Starting in the first calendar year of public operation, the number of legal requests received, complied with, and rejected, by category.
Signed releases. Client builds are code-signed and distributed with signature verification, so what you install is provably what we shipped.

Permanence is not surveillance

The reflexive worry about a "keep everything forever" product is the right one: kept where, by whom, readable by whom, subpoenaed by whom?

Kept where: on infrastructure inside India, encrypted at rest.
By whom: Immersive Mobile Designs Private Limited, operating under Indian law.
Readable by whom (today): ChatVia operators retain technical access for incident response; transport encryption protects messages from anyone in between you and the server.
Readable by whom (v1.0): only the people in the conversation. Operators lose technical access once the per-conversation key path becomes the default.
What a lawful request can compel (today): message data and metadata. (v1.0): metadata only, who you message, when, from which devices. Message contents become mathematically out of reach.
Your right to delete: always yours, at any time, server-side, permanent. Permanent doesn't mean undeletable.

Encryption: what the code does today

The cipher and AAD shape are already production:

Cipher: AES-256-GCM (the aes-gcm Rust crate).
AAD format: chatvia:v1:message:<conversation_id>:<sender_id>:<key_version>:<client_message_id>:AES-256-GCM. Every message carries the conversation, sender, key version, and client message id as authenticated context.
Wrapping primitive (backend): X25519 ECDH + HKDF-SHA256 for per-recipient envelope wrapping. The infrastructure to deliver per-conversation keys to devices is in place; the client uses it for envelope delivery today and switches to it as the sole encryption path in v1.0.
What the server stores: ciphertext, IV, auth tag, AAD, conversation id, sender id, timestamps. No content column, no plaintext field anywhere in the schema.

Transport security

All API and WebSocket traffic is TLS-protected. The exact TLS version floor and HSTS posture are governed by the deployment-layer configuration (CDN + reverse proxy), not by the application source, and will be published as part of the v1.0 audit. WebSocket runs over WSS.

Authentication

Sign-in uses signed JWT access tokens backed by longer-lived refresh tokens. Refresh tokens are stored in your OS's secure storage: Keychain on macOS and iOS, Android Keystore on Android, and the corresponding secure storage on Windows. Revoking a device from settings invalidates its tokens at the next refresh.

Access-token TTL today: configurable, currently defaulting to several days. v1.0 shortens this to a typical short-lived window, with background refresh handling the experience.

India-resident infrastructure [shipping]

Every byte of ChatVia data is stored on servers physically located in Mumbai, India, today, not at some future launch. Encryption keys (for at-rest encryption today, plus the per-conversation key vault at v1.0) are stored in India-resident infrastructure. Backups don't leave the country. More on the why and how: Built in India.

Cross-device sign-in

Today, signing in on a new device rehydrates your full history because at-rest encryption keys for message data are managed server-side under operator control. The experience is "sign in and everything's there". The trade-off is the operator-access caveat described above.

At v1.0, signing in on a new device works via per-conversation key delivery from your existing devices: the new device registers its public key, existing devices wrap conversation keys to it, and the new device decrypts history locally. Recovery from a state where you have no existing devices online will be governed by a passphrase-protected recovery vault, and its design and rollout will be documented before launch.

What we see, and what we don't

Today:

We see: your email and display name; which conversations exist and who's in them; timestamps and sizes of messages; your device list; message data (encrypted at rest, accessible by operators for incident response).
We don't see: your contact graph beyond the people you actually message; drafts (those never leave your device); message data in transit (TLS-protected).

At v1.0:

We see: everything in the "today" list except message data. The encryption keys move off the operator side; we hold encrypted blobs we cannot read.
We don't see: message contents, at all, ever, even with a court order. Only metadata remains accessible.

Independent audit

ChatVia is closed-source, so verification comes from an independent third party rather than public code. Before public launch, an external cryptography and infrastructure firm will audit the encryption model, the per-conversation key delivery path, and the AAD construction described above. The full report will be published here at v1.0, and we'll keep this page updated as findings are addressed.

Responsible disclosure

If you find a security issue, please report it privately to security@chatvia.in before making it public. We'll acknowledge within 72 hours and credit you in the release notes once a fix is shipped.