01
PQC Double Ratchet
A post-quantum Double Ratchet runs a fresh ML-KEM-1024 + X25519 hybrid key encapsulation per message. Break one primitive and the other still protects the session.
qs-chat: Post-Quantum Secure Voice & Messaging
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).
What qs-chat Is
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 solid and shipping, 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.
Cryptographic Core (Shipping)
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.
02
PQXDH Key Agreement
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.
03
HKDF-SHA3-512
Root key derivation runs through HKDF-SHA3-512. Skipped message keys expire after five minutes as a replay-protection window.
04
AES-256-GCM on the Wire
Authenticated encryption protects every frame in transit. Tampering is detected on receipt, not after the fact.
05
Automatic Key Rotation
The ratchet re-keys automatically at MAX_SEQ_BEFORE_REKEY = 65,536 messages (roughly 22 minutes of sustained traffic), keeping forward secrecy without operator intervention.
06
Group Chat
End-to-end encrypted messaging across N participants, using the same post-quantum primitives as 1:1 voice and text.
Voice (Shipping)
Push-to-talk voice is implemented and tested. Audio is captured and played back through cpal, which speaks ALSA / PipeWire on Linux, CoreAudio on macOS, and WASAPI on Windows. The voice path runs over UDP.
- Push-to-talk (PTT): hold-to-talk, wired into the session state machine and the terminal UI.
- IMA ADPCM codec: 4:1 compression, 32 kbps at an 8 kHz sample rate.
- Call session state machine: Ringing → Active → Ended.
- Cross-platform capture and playback via
cpal(ALSA / PipeWire, CoreAudio, WASAPI). - Tested internals: 90+ unit tests cover the codec, jitter buffer, TRANSEC, and protocol parsing.
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.
Resilience & Traffic Masking (Shipping)
Secure voice is only useful if it survives a lossy link and does not betray when you are speaking. qs-chat ships both.
A
Forward Error Correction (FEC)
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.
B
TRANSEC Traffic-Flow Masking
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.
C
Message Priority Levels
Military-style precedence: Flash, Immediate, Priority, and Routine. Higher-priority traffic preempts lower priority in the jitter buffer.
D
No Cloud, No Phone-Home
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.
At a Glance
Everything below the "Shipping" line is in the code and tested. Everything under "Roadmap" is not yet shipping.
Shipping today
PQC Double Ratchet
ML-KEM-1024 + X25519
PQXDH
HKDF-SHA3-512
AES-256-GCM
Push-to-talk voice
IMA ADPCM codec
FEC
TRANSEC
Priority levels
Group chat
Terminal (TUI/CLI)
Roadmap (not shipping yet)
GUI client
Opus low-bandwidth codec
Video
Roadmap (In Development)
We label this plainly so nobody buys on a promise. These are TODO items in the codebase, not features you can use today.
In development · not shipping
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.
Who It Is For
qs-chat is built for teams whose conversations must stay secret indefinitely, and who are comfortable operating from a terminal.
- Military and defense comms teams where conversations must remain secret well past the lifetime of any classical cipher.
- Healthcare emergency response where field coordination cannot be intercepted.
- Journalists in hostile environments protecting sources.
- Executives and incident-response teams at quantum-targeted firms (finance, pharma, defense contractors).
- Anyone whose threat model includes "harvest now, decrypt later."
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.
How It Compares
Most secure-voice options fall into one of three buckets. qs-chat aims for the gap between them: real post-quantum cryptography, real production code, deployable today, on commodity hardware, with no cloud lock-in.
Easy but not quantum-safe (Signal, WhatsApp, FaceTime): great UX, classical cryptography that a future quantum computer breaks.
Quantum-safe but research-grade: academic projects with no shippable product.
Military-grade but locked away: Type 1 hardware that costs millions and is government-only.
qs-chat lands in the middle: shipping PQC, runs on commodity hardware, no cloud. The trade-off you accept today is the terminal interface and the absence of formal certification.
Licensing & Pricing
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.
Get qs-chat
Contact sales for licensing, deployment guidance, and a technical walkthrough of the shipping feature set. For security questions, protocol details, or coordinated disclosure, use the security contact.
Sales & licensing: /contact · Security: /security or security@quantumsequrity.com
Quantum-safe comms, today.
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.