Cryptography overview
Buzzio’s sealed messaging cryptography follows Signal-protocol-class designs implemented in the Flutter client (CryptoEngine, SealedSender, SenderKeyEngine) using secp256k1 and AES-GCM — not a third-party libsignal package binding in-tree.
This overview orients readers; protocol pages go deeper.
Primitive stack
| Layer | Mechanism | Role |
|---|---|---|
| Identity curve | secp256k1 ECDH / ECDSA | Identity keys, signatures, sealed ECDH |
| Session agreement | X3DH (4-DH) + HKDF | Bootstrap shared secret between users |
| Session secrecy | Double Ratchet | Forward secrecy / break-in recovery style key evolution |
| Message AEAD | AES-GCM | Encrypt message payloads and sealed outer envelopes |
| Group E2EE | Sender keys + ECDSA | One ciphertext per group message; members share sender chains |
| Sealed envelope | Eph ECDH → HKDF → AES-GCM | Hide sender identity from outer relay metadata |
| Sender cert | HMAC-SHA256 CA (Cloud Functions) | Abuse controls without trusting client from |
| Local history | SQLCipher | Encrypt readable history at rest on device |
| Media (sealed / Stories) | Chunk AES-GCM (hardware-accelerated where available) | File/media encryption helpers |
| Media (shared rooms) | Content-hash + Bunny CDN bytes | Communities / Broadcast / OHG dedup (rolling out); not sealed |
| Vault / backup account wrap | HKDF-SHA256 with separate domain labels | Optional seed-level account encryption without uploading the phrase |
| Vault / backup / self-note files | Random file keys + AES-GCM / hardware-assisted GHCH chunk containers where supported | Client-side ciphertext before upload |
HKDF labels in use include X3DH (session bootstrap) and buzzio_sealed_sender_v1 (outer envelope).
What cryptography guarantees (sealed surfaces)
| Guarantee | Meaning |
|---|---|
| Confidentiality of content | Buzzio operators cannot read sealed message bodies |
| Integrity / authenticity (session) | Ratchet + AEAD bind ciphertext to session keys |
| Forward secrecy (ratchet) | Compromising current keys does not expose past message keys (Signal-style goal) |
| Envelope sender concealment | Preferred sealed path avoids plaintext sender on outer RTDB/from and FCM |
| Local at-rest protection | Device DB encryption for readable history |
What cryptography does **not** guarantee alone
| Non-guarantee | Why |
|---|---|
| Network anonymity | Firebase/FCM/CDN see IPs and connection patterns |
| Absolute metadata silence | Undelivered queues, account rows, push wakes (“R at time T”) |
| Safety from compromised endpoints | Malware on the phone sees plaintext after decrypt |
| Shared-mode secrecy from operator | Communities / OHG / Broadcast use TLS in transit, but text is plaintext at rest and media is CDN-stored without at-rest encryption; Buzzio can read it (dedup) |
| Screenshot immunity | Secure View hardens UX; OS-level capture is never absolute on all devices |
Key hierarchy (conceptual)
12-word mnemonic
└── account master key (on device)
├── identity keypair (secp256k1)
│ ├── published identity / signed prekeys / one-time prekeys
│ ├── X3DH → root / chain keys → Double Ratchet message keys
│ └── sealed-sender open (identity private key)
├── Vault wrapping key (optional, domain-separated)
├── backup wrapping key (optional, domain-separated)
└── Bitcoin wallet derivation (optional) — same phrase; treat as high value
Buzzio ID is a separate random address, not a hash of the mnemonic.
Vault and backup can instead use separate user-generated 64-character recovery keys. Seed-derived Vault and backup keys use different HKDF labels and are not reused as messaging keys.
Protocol pages
- How to verify — build/run tests, envelope shape, claim vs non-claim
- X3DH and Double Ratchet
- Sealed sender
- Groups and sender keys
- Shared media deduplication (Communities / Broadcast / OHG media plan)
Open-source references
Educational crypto package (GPL-2.0): github.com/ve-21/buzzio-crypto-open-source
Educational client reference (Phase 1–2, offline UI): github.com/ve-21/buzzio-client-open-source
The crypto package shows how a Signal-protocol-class stack can be built (secp256k1, X3DH, Double Ratchet, AES-GCM, sealed envelopes, sender keys). The client package includes sanitized encryption banners / verification UI stubs. Neither is the production app — production salts/peppers, CA private key, Firebase paths, and the full mobile client remain closed. Package HKDF labels are generic and are not guaranteed to match live Buzzio wire format.
Hands-on checklist: How to verify (crypto tests → client tests → claim ceilings).
Independent audit status
No third-party security audit of Buzzio (app or this reference package) has been published yet. Prefer citing mechanisms and the open reference over slogans.
Status, scoped plan, and future public summary: Independent security audit. When a report is published, that page, this page, Security disclosure, and the product Security page will link it.
Report issues via Security disclosure and the Buzzio Forum.
Implementation note for auditors
Production client crypto lives primarily under lib/core/crypto/ in the closed app. Empty or stub libsignal/ paths do not imply libsignal is the runtime engine. Prefer reading crypto_engine.dart, sealed_sender.dart, and sender_key_engine.dart (and the open educational package above) as the conceptual source of truth for algorithms.