A second QNSQY product. Quantum-safe voice and messaging for operators and technical teams who need conversations that cannot be recorded today and decrypted later. Every key, every message, every voice frame is post-quantum. Today it runs in the terminal (TUI/CLI).
qs-chat is the sister product to the QNSQY post-quantum cryptography toolkit, built on the same post-quantum primitives and the same hardening philosophy. Think of it as a Signal-style protocol where every layer is post-quantum: the initial key agreement, the per-message ratchet, and the voice path. On top of that it adds TRANSEC, so the shape of your traffic on the wire does not leak when you are actually talking. No cloud, no third-party servers, no phone-home, no analytics.
Be clear-eyed about what it is today: qs-chat runs as a terminal application (TUI and CLI). It is an operator and technical-team comms tool, not a finished consumer messenger. A graphical client is on the roadmap. If your team lives in a terminal or on an SSH session, it works for you right now. If you need a polished mobile app for non-technical users, that is not what ships today.
Honest posture: the cryptography is implemented and tested, but qs-chat is not FIPS 140-3 validated and not formally certified by any government body. For Type 1 secrecy you still need certified hardware. This is a tool, not a guarantee. Bring your own threat model.
The same post-quantum building blocks QNSQY uses for files protect every qs-chat session. Both a quantum and a classical primitive must be broken for an attacker to succeed.
A post-quantum Double Ratchet: each message gets its own key from a hash chain, and each change of speaker runs a fresh ML-KEM-1024 + X25519 hybrid key encapsulation. Break one primitive and the other still protects the session.
Post-Quantum X3DH for the initial handshake. Start a conversation asynchronously: send the first message before the other side is online, with quantum-safe key agreement.
Root key derivation runs through HKDF-SHA3-512. Skipped message keys expire after five minutes as a replay-protection window.
Authenticated encryption protects every frame in transit. Tampering is detected on receipt, not after the fact.
Voice keys rotate automatically every 1,500 packets, about every 30 seconds at the constant 50 packets per second, without operator intervention.
End-to-end encrypted messaging across N participants, using the same post-quantum primitives as 1:1 voice and text.
Push-to-talk voice is implemented and tested. Audio is captured and played back through cpal (ALSA / PipeWire on Linux). The audio library also supports macOS and Windows, but we have not built or tested qs-chat there. The voice path runs over UDP.
cpal: ALSA / PipeWire on Linux. macOS and Windows builds are not tested.Scope note: voice modules have unit tests, but there is not yet an automated end-to-end test proving two peers complete a full call. End-to-end calls are validated manually today. We call that out rather than imply coverage we do not have.
Secure voice is only useful if it survives a lossy link and does not betray when you are speaking. qs-chat has both.
Lost packets are recovered without retransmission. The jitter buffer reconstructs missing packets from previous FEC data, and is tested against drop, reorder, and duplicate scenarios.
Constant 50 packets/sec at 20 ms frames, a fixed 256-byte padded packet size, dummy packets during silence, and timing jitter. An observer cannot tell from the wire shape when you are actually talking. Three modes: Off, DummyPackets, and Full.
Military-style precedence: Flash, Immediate, Priority, and Routine. Higher-priority traffic preempts lower priority in the jitter buffer.
Peer-to-peer or your own relay. No STUN, no TURN, no external dependencies, zero telemetry. The transport uses TCP for text and UDP for voice.
Everything under "In the code and tested" is implemented and has tests; qs-chat has no public download; it is provided under a separate licence. Everything under "Roadmap" is not built yet.
We label this plainly so nobody buys on a promise. These are TODO items in the codebase, not features you can use today.
GUI client. qs-chat is terminal-only today. A graphical client for non-technical users is planned but not yet built.
Opus codec. The current voice codec is IMA ADPCM. Opus is declared in the protocol enum, but the integration is not done and there is no Opus dependency wired in. A low-bandwidth Opus mode for satellite/HF links would follow once it ships. Do not assume low-bandwidth or satellite voice works today.
Video. No code yet. Voice ships first; video is not implemented.
qs-chat is built for teams whose conversations must stay secret indefinitely, and who are comfortable operating from a terminal.
Reality check: because qs-chat is terminal-based today, it suits operators and technical teams. It is not positioned as a drop-in consumer replacement for Signal or WhatsApp. The GUI that would change that is on the roadmap.
Most secure-voice options fall into one of three buckets. qs-chat aims for the gap between them: post-quantum cryptography in working, tested code, on commodity hardware, with no cloud lock-in.
Consumer messengers (Signal, WhatsApp, FaceTime): Signal and iMessage use post-quantum key agreement; all of these apps run through their vendors' servers. qs-chat runs peer-to-peer or through your own relay, with traffic-flow masking and precedence levels.
Quantum-safe but research-grade: academic projects with no shippable product.
Certified but locked away: Type 1 hardware, government-only.
qs-chat lands in the middle: post-quantum cryptography, commodity hardware, no cloud. The trade-off you accept today is the terminal interface and the absence of formal certification.
qs-chat is licensed separately from the QNSQY file-encryption product. Pricing is handled per engagement rather than as a self-serve tier. Reach out and we will scope it with you.
Contact sales for licensing, deployment guidance, and a technical walkthrough of the implemented feature set. For security questions, protocol details, or coordinated disclosure, use the security contact.
Sales & licensing: /contact · Security: /security or [email protected]
Post-quantum voice and messaging for operators and technical teams. Licensed separately from QNSQY. Contact sales to scope a deployment, or read the security posture first.