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 — planned) | Content-hash + Bunny CDN bytes | Communities / Broadcast / OHG dedup; not sealed |
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: text under server-held keys; media planned as CDN-stored with signed access (dedup plan) |
| Screenshot immunity | Secure View hardens UX; OS-level capture is never absolute on all devices |
Key hierarchy (conceptual)
12-word mnemonic
└── identity keypair (secp256k1)
├── published identity / signed prekeys / one-time prekeys
├── X3DH → root / chain keys → Double Ratchet message keys
├── sealed-sender open (identity private key)
└── (optional) Bitcoin wallet derivation — same phrase; treat as high value
Buzzio ID is a separate random address, not a hash of the mnemonic.
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 crypto reference
Educational Dart package (GPL-2.0): github.com/ve-21/buzzio-crypto-open-source
Shows how a Signal-protocol-class stack can be built (secp256k1, X3DH, Double Ratchet, AES-GCM, sealed envelopes, sender keys). Not the production app — production salts/peppers, CA private key, Firebase paths, and the 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 (dart pub get → dart test → demo → 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. When an audit report is published, this page 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.