How to verify
This is a hands-on checklist, not a reading list. Use it to check what is public today: the educational crypto package, documented envelope shape, and honest claim ceilings.
Open-source crypto: github.com/ve-21/buzzio-crypto-open-source (GPL-2.0)
Product security page: buzzio.dev/buzzio/security-overview
Disclosure / report bugs: Security disclosure · Forum
One-pager PDF: Protocol one-pager · Download PDF
1. Build and run the open-source crypto tests
Requires a local Dart SDK.
git clone https://github.com/ve-21/buzzio-crypto-open-source.git
cd buzzio-crypto-open-source
dart pub get
dart test
dart run example/demo.dart
| Step | Pass means |
|---|---|
dart pub get |
Package resolves |
dart test |
Unit tests for key agreement / ratchet / envelope helpers with generated keys succeed |
dart run example/demo.dart |
Demo path runs end-to-end in the reference package |
Also read the repo README.md and SECURITY.md (what is intentionally omitted).
2. What sealed envelopes look like (conceptual)
Production sealed path (docs detail): Sealed sender.
Outer layer (concept):
ephemeralPub || AES-GCM( HKDF( ECDH(eph, recipientIK), info ), payload )
Inner payload (concept): certificate material + inner message (real sender + ratchet ciphertext) — only the recipient’s identity private key opens the outer layer.
| Surface | What you should expect |
|---|---|
| Outer relay / preferred path | No durable plaintext from naming the sender |
| FCM wake (sealed) | Omits plaintext sender_id where sealed wakes apply |
| Open package HKDF labels | Generic (e.g. sealed_sender_v1) — not guaranteed identical to live Buzzio wire labels |
| Live app labels | Documented production-oriented strings such as buzzio_sealed_sender_v1 on Cryptography overview |
The open package shows how envelopes can be built. It is not a byte-identical dump of production wire format.
3. What we claim vs what we do not claim
We claim (sealed surfaces)
| Claim | Mechanism to cite |
|---|---|
| Operator-blind content for sealed chats | Device keys; X3DH + Double Ratchet / sender keys; AES-GCM |
| Blind-relay style for private 1:1 | Delete-on-delivery + short undelivered TTL |
| Envelope sender concealment on preferred path | Sealed outer envelope; minimized FCM correlators |
| Phone-free account root | Buzzio ID + mnemonic (not a SIM phone requirement) |
| Local-first private history | SQLCipher on device by default |
| No sale of messages / IDs / chats | Product policy — Privacy guarantees |
We do **not** claim
| Non-claim | Why |
|---|---|
| Tor-grade network anonymity | Firebase / FCM / CDN see IPs and connection patterns |
| Absolute “zero metadata” everywhere | Scoped only — definition |
| Shared rooms are operator-blind | Communities / Broadcast / open-history groups store more by design |
| Open package ≡ production binary | Salts, peppers, CA key, Firebase wiring, mobile app are closed |
| A published third-party audit (today) | None published yet — Security disclosure |
4. Quick verify matrix
| Check | How | Pass / fail note |
|---|---|---|
| Crypto package builds | dart pub get + dart test |
Fail → environment or package issue |
| Demo runs | dart run example/demo.dart |
Fail → follow repo README |
| Envelope design readable | Sealed sender | Conceptual shape documented |
| Sealed vs shared labeled | Sealed vs shared | Feature matrix honest |
| Threat model present | Threat model | Adversary / ceilings listed |
| Audit honesty | Security disclosure | “No public audit yet” stated |
5. What this checklist cannot prove alone
- That production uses identical HKDF info strings or demo salts
- That Cloud Functions / RTDB rules match a reviewer’s mental model without closed-source access
- That any specific Play Store binary was built from a given commit of the educational package
For bugs and ideas after verifying: join forum.buzzio.dev — see Security disclosure.