Next-generation private messenger

Private today. Private after the quantum computer.

Balsso is an end-to-end encrypted messenger being built on hybrid post-quantum cryptography. Messages, files and calls are sealed on your device, and every session key comes from a classical and a post-quantum exchange together, so traffic recorded today cannot be opened later by breaking only one of them.

How it works Follow development
ML-KEM-768 · FIPS 203X25519 hybridPost-quantum ratchetVerified contactsZero third parties

Why now

Harvest now. Decrypt later.

Encrypted traffic is being recorded today to be broken tomorrow. Classical key exchange based on elliptic curves falls to a sufficiently large quantum computer. Anything sealed with it alone has an expiry date you don't control.

Protocol

Hybrid by design. Two locks, one key.

Every session starts with two independent key agreements, combined so that the session stays secret as long as either primitive holds. This page describes the design Balsso is being built to; the full specification and threat model will be published before launch.

01Handshake 02Session keys 03Delivery Alicesigned identity key Bobsigned identity key HKDF ( ss₁ ‖ ss₂ ‖ transcript ) X25519 · classical ML-KEM-768 · post-quantum X25519 · classical ML-KEM-768 · post-quantum Root keyDouble Ratchet k₁ k₂ k₃ PQ k₄ one key per message, deleted after use · a fresh ML-KEM secret mixed in regularly Alice’s deviceencrypts locally Balsso serverroutes ciphertext · holds no keys · deletes after delivery Bob’s devicedecrypts locally sealed envelope · XChaCha20-Poly1305 same envelope, unchanged
Design target. Specification and threat model to be published before launch.Swipe sideways to explore
  1. 01

    Hybrid key establishment

    A PQXDH-style handshake: ML-KEM-768 (FIPS 203) and X25519 secrets go through HKDF together with the transcript, so the result is bound to both parties, their devices and the protocol version, not just to the two secrets.

  2. 02

    Authenticated contacts

    Identity and prekeys are signed with Ed25519. Verify a contact with a QR code or safety number; key changes and new devices are announced, and a new device is approved from one you already trust. A key-transparency log is planned so the server cannot show different keys to different people.

  3. 03

    Keys that keep moving

    A Double Ratchet gives every message its own key, and a post-quantum ratchet injects fresh ML-KEM secrets as the conversation goes on. One leaked message key exposes no other message. If a whole session state leaks, protection returns once the parties complete an exchange the attacker did not see.

  4. 04

    Sealed envelopes

    Message bodies are AEAD-encrypted (XChaCha20-Poly1305) with purpose-separated keys. Servers route opaque ciphertext, hold no message keys, and delete envelopes once delivered.

What Balsso is

Everything encrypted. Nothing collected.

Messages, files, calls

Text, attachments, voice and video share one end-to-end encrypted session. There is no "secret chat" mode, because every chat is one.

Your number stays yours

Contacts discover each other through hashed identifiers. Your phone number is never shown to the server-side profile or to people you message.

Minimal metadata

Servers see sealed envelopes and a delivery queue. Envelopes are deleted after delivery, logs are short-lived and never leave our own machines.

Every device, its own keys

Each phone or desktop holds its own identity and prekeys. Linking a device never copies secrets through the server.

Calls that stay sealed

Voice and video frames are encrypted end to end with keys negotiated in the chat session. Our relay servers forward packets and are designed never to hold the frame keys.

Independent infrastructure

No hyperscalers, no third-party SDKs, no ads, no analytics. The servers are ours, the clients are open to inspection, and this page loads nothing from anyone else.

Status

In development, built in the right order.

Security work cannot be rushed. We finish the cryptographic core and review it against the specification before any public release.

  1. Infrastructure

    Dedicated servers, encrypted storage, monitoring and backups are running.

  2. Server API

    Authentication, devices, prekeys, discovery, sealed envelopes and calls are being built and tested.

  3. Hybrid protocol

    Implementing the ML-KEM + X25519 handshake, the Double Ratchet and the post-quantum ratchet in the protocol library.

  4. Specification and threat model

    Public document covering key agreement, authentication, message encryption and the key lifecycle.

  5. iOS and Android

    First-party apps built on the protocol library.

  6. Security review

    Protocol and implementation reviewed against the published specification; findings and fixes published.

  7. Public launch

    Early access first, then open registration.