Security is the architecture, not an afterthought.
Q-Audion is built end-to-end encrypted from the first line of code, with a hybrid classical and post-quantum key exchange, hardware-backed key storage on every platform, and an engineering process held to published, independently authored security standards.
A hybrid key exchange built for the next twenty years, not just today.
Every session is protected by two independent cryptographic problems at once. Breaking it — including with a future quantum computer — means breaking both.
Post-quantum key agreement
ML-KEM-1024, the NIST-standardized post-quantum key encapsulation mechanism (FIPS 203), combined with classical X25519 in a hybrid construction — security never regresses below what X25519 alone already provides.
FIPS 203 · Category 5Authenticated identity
Every device signs its own key material with Ed25519 (RFC 8032). Identity is verifiable end to end — including in person, via safety-number comparison and NFC tap-to-verify.
Hardware-rooted keys
Private key material is generated and used inside StrongBox on Android and the Secure Enclave on iOS wherever the device supports it — the key material itself never leaves that hardware boundary.
Forward-secret sessions
Message and call keys ratchet forward continuously. A key recovered from one moment does not expose the conversations that came before or after it.
Designed so there's less of you to leak.
Privacy failures are usually metadata failures. Our server infrastructure is built to hold as little as possible about who is talking to whom.
Sealed sender
Push notifications carry an opaque, salted identifier — never a sender name, a content preview, or anything a notification pipeline outside our control could read.
Encrypted attachments
Photos, voice notes and files are sealed with XChaCha20-Poly1305 before they ever leave the device, then held under a second, hardware-keyed AES-256-GCM layer for as long as they're cached on disk.
Ephemeral by choice
Disappearing-message and attachment timers are enforced the same way on every platform, with peer devices kept in sync.
Phone numbers, hashed
Contact discovery works from a salted, one-way hash of a phone number — never the raw number itself — so contact lists stay unreadable to the service that matches them.
The parts you never see, held to the same bar.
A messenger is only as trustworthy as the pipeline that builds and ships it. Every commit passes through the same automated gates before it reaches a device.
Certificate pinning, continuously checked
Every client pins the server's TLS certificate — and an automated daily job independently verifies the live certificate still matches what's pinned, on every platform, so drift is caught the same day.
Pinned, verified dependencies
Every third-party library is locked to an exact, checksum-verified version. A build cannot merge with an unpinned or unverified dependency — the pipeline refuses it automatically.
Continuous security scanning
Source code across every client and the server runs through automated security scanning on an ongoing basis, watching for the vulnerability classes that matter most in a networked, cryptographic application.
Secrets never in source
Production credentials live only in the runtime environment of the machine that needs them, injected at process start — never committed, never templated into a config file in the repository.
We measure ourselves against the same bar auditors would.
Rather than declare our own definition of "secure," we hold our engineering process to frameworks written and maintained by the wider security community — and reassess against them as the product evolves.
The industry reference for what a security-conscious mobile app should get right — from local data storage to platform interaction and cryptography.
Applied to our backend services: authentication, session handling, access control and API design, verified against the same checklist independent auditors use.
Guides how we govern, identify, protect, detect, respond and recover as an engineering organization — not just how a single feature is coded.
How to read this: these are internal self-assessments, performed against publicly published frameworks and refreshed as the codebase changes — not a certificate issued by a third party. Where a formal, independently audited badge exists for a claim we make, we'll name the auditor and link the credential directly.
Contact
Will be published here alongside the public key block before the public 1.0 release.
Open a draft security advisory in the Security tab of the relevant Q-Audion repository (GitHub private vulnerability reporting).
What we commit to
- Acknowledgement within 48 business hours of receipt
- Triage and severity classification within 5 business days
- 90-day coordinated disclosure window by default, extended only with reporter agreement when a complex fix is required
- Public credit in release notes unless you ask for anonymity
Bug bounty
A managed bug bounty program will be live before the public 1.0 release. Until then, we offer good-faith rewards on a case-by-case basis for high-impact findings.
Scope
- +All Q-Audion server code (identity, key management, transport, group, prekey, file storage)
- +All published Q-Audion clients on Android, iOS and Desktop (Windows / macOS / Linux when shipped)
- +Cryptographic protocol design (PQ handshake, post-quantum double ratchet, sender-identity metadata protection, Sigsum Key Transparency)
- +Wire-spec drift causing cross-platform unsafe behavior
- −Issues requiring physical access to an unlocked device
- −Self-inflicted XSS without crossing a trust boundary
- −Outdated browser/OS versions per vendor support windows
- −Volumetric DDoS without a logic flaw
- −Social engineering of Q-Audion staff
- −Reports based on automated scanner output without a working proof-of-concept
Open wire specification
The cross-platform protocol contract is byte-identical across all Q-Audion clients. The spec is mirrored across the client repositories and the server repository as the gating commit for any wire change. Independent reviewers can read it before opening a session — and library implementations (liboqs, BouncyCastle, @noble/post-quantum) are cross-validated against shared KAT vectors.
Reproducible builds (1.0 target)
All 1.0 release artifacts (APK, IPA, Desktop installers) will be Sigstore-signed. Independent reproducibility from source is a release-go criterion: anyone can verify the shipped binary matches the public source.