BTP — Berkeley Transport Protocol

A clean-break post-quantum successor to HTTP+TLS. Maintained by Cristian Cezar Moisés. Part of the SecurityOps ecosystem.

Project page	https://btp.securityops.co
Documentation	https://btp.securityops.co/docs/
Source	https://git.securityops.co/cristiancmoises/btp
License	Apache-2.0 (impl) · CC-BY 4.0 (spec) · "BTP" registered trademark
Trademark licensing	sac@securityops.co
Contact	sac@securityops.co
OpenPGP key	https://securityops.co/.well-known/security.asc
Security policy	SECURITY.md · https://securityops.co/.well-known/security.txt

---

Status: Reference implementation, v0.7.0 (pre-1.0). 204/204 library tests green, 21/21 Python SDK tests green, 18/18 JS/WASM SDK tests green, 29/29 conformance MUST-level vectors passing. 0 warnings, 0 unsafe in crates/btp/ safety-critical paths. 46 documented audit sprints with 0 CRITICAL, 0 HIGH, 0 unmitigated MEDIUM, 0 unmitigated LOW findings. The wire format and document format are stable and conformance-tested. The whitepaper is on Zenodo with DOI 10.5281/zenodo.20278231. Of the six v1.0 release gates, one (conformance suite published) is now half-closed; the remaining five are operational rather than implementation work — see BTP-AUDIT.md. See SECURITY-VERIFICATION.md for the verification framework, DEPLOYMENT.md for VPS deployment, BTP-AUDIT.md for the per-sprint audit narrative, and THREAT-MODEL.md for the adversary model.

In Code We Trust.

---

Why a new protocol

HTTPS is thirty years of accreted compromises. TLS 1.3 is excellent classical cryptography, and PQ-TLS is being retrofitted, but the rest of the stack — cookies, headers, JavaScript-served crypto, CT bolted on after the fact, cross-origin coalescing — was never designed for the threat model we live in now.

BTP starts over with five non-negotiable design rules:

1. Post-quantum by construction. ML-DSA-87 (FIPS 204) signatures, ML-KEM-1024 (FIPS 203) key exchange. No classical fallback in the canonical release build (--no-default-features). No negotiation.
2. No cookies. No User-Agent. No Referer. Privacy is a property of the protocol, not a setting.
3. Content-addressed. Every response body is identified by its BLAKE3-256 digest. Cache by digest. Verify by digest.
4. Capability-based authorization. Macaroon-style. No bearer tokens. No sessions.
5. Mandatory key transparency. Every origin's signing key must appear in a public Merkle log, cosigned by independent witnesses across multiple jurisdictions, before a client trusts it.

The result is small, closed, auditable, and post-quantum from the wire up.

---

Architecture

┌──────────────────────────────────────┐
│  btpview  (terminal renderer)        │  signature verified before display
├──────────────────────────────────────┤
│  .btp document format                │  signed, content-addressed, block-oriented
├──────────────────────────────────────┤
│  BTP application protocol            │  request/response, capabilities, KT log,
│                                      │  witness cosigs, trust policy
├──────────────────────────────────────┤
│  PQ transport                        │  ML-KEM-1024 + ChaCha20-Poly1305
│                                      │  per-direction keys, padded plaintexts
├──────────────────────────────────────┤
│  TCP / IP                            │  length-prefixed framing
└──────────────────────────────────────┘

Identity is enforced at the application layer, not the transport layer. The PQ transport gives confidentiality and integrity for the channel only. Identity binding flows through: signed .btp document → author public key → KT log inclusion proof → witnessed STH → trust policy. This separation is the inverse of HTTPS+CT, which conflates channel and identity into TLS.

---

What's in the repository

btp/
├── README.md                       this file
├── SPEC.md                         normative protocol specification
├── SPEC-ATTACHMENTS-v0.7.md        attachment subsystem (v0.7+)
├── SPEC-WITNESS-BOOTSTRAP.md       CWM (Cosignature Witness Manifest)
├── SPEC-OPERATOR-WITNESS-API.md    HTTP API contracts
├── SPEC-HTML-PROFILE.md            sandboxed HTML profile v1
├── SPEC-EVELIN-MIGRATION.md        post-quantum transport (Evelin) migration
├── THREAT-MODEL.md                 adversary model and out-of-scope properties
├── BTP-AUDIT.md                    security audit narrative (per development sprint)
├── FORMAL-VERIFICATION.md          Kani / property-testing approach
├── SECURITY-VERIFICATION.md        layered verification framework
├── IANA-RR-TYPE-REQUEST.md         prepared RFC 6895 submission
├── DEPLOYMENT.md                   operator deployment guide
├── SECURITY.md                     vulnerability disclosure policy
├── TRADEMARK.md                    "BTP" name trademark policy
├── CHANGELOG.md                    versioned change history
├── crates/
│   ├── btp/                        library (cryptography, frames, capabilities,
│   │                               documents, KT log, transports, trust policy,
│   │                               sandboxed HTML profile)
│   ├── btp-bundle/                 trust-bundle assembly and operator/witness CLI
│   ├── btp-cli/  →  btpctl         general command-line tool
│   ├── btp-witness/                witness daemon (cosigning server)
│   ├── btpd/     →  btpd           reference origin daemon
│   ├── btpview/  →  btpview        terminal renderer (lightweight)
│   ├── btpview-gui/ → btpview-gui  desktop graphical client (Tauri, ~10 MB
│   │                                binary, Linux/macOS/Windows)
│   └── btplib-python/             official Python SDK (PyO3 bindings,
│                                    published to PyPI as `btplib`)
│   └── btplib-js/                  official JavaScript / WebAssembly SDK
│                                    (wasm-bindgen, published to npm as `btplib`)
├── btp-stack/                       turnkey Docker deployment for hosting a
│                                    BTP origin (btpd + portal). See its own
│                                    README for the 5-minute deploy guide.
├── examples/
│   ├── site/                        a sample .btp site (used in tests)
│   └── docker-compose-quickstart.md
├── scripts/
│   ├── build-docs.py               regenerates site/docs/ from .md
│   └── demo-trust.sh               end-to-end trust-bundle demo
├── site/                           the project landing page (HTML/CSS/JS, 10 languages)
│   ├── index.html
│   ├── README.md
│   └── docs/                       generated from the .md files at root
├── well-known/                     RFC 9116 disclosure files (security.txt etc.)
├── .forgejo/workflows/             CI (Forgejo Actions)
└── crates/btp/fuzz/                seven cargo-fuzz targets

Approximately 9,700 lines of Rust. Builds clean on rustc stable; fuzz targets require nightly.

---

Deploy to your VPS (5 minutes)

ssh root@your-vps.example.com
apt update && apt install -y git
git clone https://git.securityops.co/cristiancmoises/btp /opt/btp
cd /opt/btp
./deploy/install.sh

The install script provisions everything: builds binaries, creates unprivileged users, installs man pages, drops systemd units, configures nginx, and starts services. See DEPLOYMENT.md for the full guide covering TLS certs, hardening, multi-host topology, backup/restore, and disaster recovery.

After install:

man btpd                              # daemon docs
man btpctl                            # CLI docs
man btp                               # file format docs
systemctl status btpd                 # service health
journalctl -u btpd -f                 # live logs
curl http://127.0.0.1:4434/health     # liveness probe

To uninstall: ./deploy/uninstall.sh (add --purge to delete data).

---

Quickstart

There are three paths depending on your role:

Path 1 — Host a BTP origin (5 min, Docker)

# Build the binaries
cargo build --release --no-default-features -p btpd -p btp-bundle -p btpview

# Bring the turnkey stack up
cd btp-stack
cp .env.example .env && nano .env       # set BTP_ORIGIN_HOST etc.
./examples/build-example-site.sh         # generates key + signs example page
docker compose up -d --build

See btp-stack/README.md for the full guide.

Path 2 — Read BTP pages (desktop GUI)

# Linux (Debian/Ubuntu)
sudo apt install -y libwebkit2gtk-4.1-dev build-essential pkg-config libssl-dev
cargo build --release -p btpview-gui

# macOS
xcode-select --install
cargo build --release -p btpview-gui

# Windows
# Install Visual Studio Build Tools + Rust, then:
cargo build --release -p btpview-gui

# Run it
./target/release/btpview-gui

See crates/btpview-gui/README.md for bundling into AppImage / .app / MSI installers.

Path 3 — Hack on the protocol

The canonical release build is post-quantum only, no Ed25519 fallback:

# 1. Build the post-quantum release binary
cargo build --workspace --release --no-default-features

# 2. Run the test suite (213 tests across all crates)
cargo test --workspace --release --no-default-features

# 3. Compose a signed BTP document
./target/release/btpctl genkey --out signer
echo "# Hello, post-quantum world" > hello.md
./target/release/btpctl doc new --key signer --title "Hello" --input hello.md --out hello.btp

# 4. Serve a directory
mkdir site && mv hello.btp site/index.btp
./target/release/btpd --bind 127.0.0.1:4434 --root ./site &

# 5. Fetch
./target/release/btpctl fetch btp://127.0.0.1:4434/ > /dev/null

# 6. Render in the terminal — signature verified before display
./target/release/btpview btp://127.0.0.1:4434/

DNS-resolved fetch (port resolved from BTP_HOSTS-style file, fingerprint enforced):

# btp.hosts file:  name  host:port  fingerprint-hex
echo "example.btp 127.0.0.1:4434 <author-fingerprint>" > btp.hosts
BTP_HOSTS=$PWD/btp.hosts ./target/release/btpctl fetch btp://example.btp/

Trust-bundle fetch (anchored origin required, witness threshold enforced):

./target/release/btpctl fetch --trust bundle.json btp://example.btp/

For a complete deployment guide see the project page at https://btp.securityops.co/docs/.

---

Cryptographic facts pinned by tests

• ML-DSA-87 public key: exactly 2592 bytes (FIPS 204 §4)
• ML-DSA-87 signature: exactly 4627 bytes (FIPS 204 §4)
• Signature domain-separation context: b"BTP/v1"
• ML-KEM-1024 encapsulation key: 1568 bytes
• ML-KEM-1024 ciphertext: 1568 bytes
• ChaCha20-Poly1305 with 12-byte nonces, 16-byte tags
• Per-direction AEAD keys: BLAKE3_keyed_hash(prk, "c2s" | "s2c")
• Plaintext padding to 256-byte boundary before encryption
• BLAKE3-256 throughout (digest, capabilities, KT log leaves + inner nodes)
• KT log inclusion + consistency proofs verified for every tree size 1..=17 in property tests

---

Threat model summary

In scope: passive observers, active network attackers, compromised intermediaries, compromised log operators, compromised DNS resolvers, single-witness compromise, quantum-capable adversaries (harvest-now-decrypt-later).

Out of scope: endpoint compromise, side channels in upstream crypto libraries, cryptanalytic breaks of FIPS 203 / 204 or BLAKE3, threshold witness collusion, traffic-analysis resistance beyond per-frame padding.

Full treatment in THREAT-MODEL.md.

---

Audit posture (v0.7.0)

Severity	Open	Closed
CRITICAL	0	—
HIGH	0	—
MEDIUM	0	8
LOW	5	7
INFO	0	9

All open LOWs are documented design choices, operational items (e.g. IANA assignment pending), or external dependencies. The per-sprint narrative — covering 46+ documented sprints across the codebase — is in BTP-AUDIT.md.

---

What still stands between here and v1.0

The remaining work is operational, not implementation:

• Recruit 5+ independent witness operators across 3+ jurisdictions
• Submit the IANA DNS RRTYPE assignment request per IANA-RR-TYPE-REQUEST.md (formal channel: dns-rrtype-applications@ietf.org)
• Run the nightly fuzz workflow 14 consecutive nights with zero new findings
• Independent reproducible-build verification by a third party
• External security audit (see BTP-AUDIT.md for the per-sprint audit trail covering the work to date)
• First non-reference implementation to certify against the conformance suite (crates/btp/tests/conformance/ — suite published, 29 normative test vectors; the reference implementation passes 29/29 MUST-level)

Of these six gates, only the last is partially closed (the suite itself is shipped). The other five are operational — recruitment, formal submissions, calendar time, third-party verification, and engaging an auditor — and cannot be closed by additional implementation effort.

---

License & trademark

BTP separates protocol, implementation, and brand:

Asset	License	Why
The protocol specification (SPEC.md)	CC-BY 4.0	Anyone may copy, translate, or republish the spec, with attribution. Encourages independent implementations.
The reference implementation (crates/*)	Apache-2.0	Fork, modify, embed in proprietary products, ship commercially — no copyleft drag, no source-disclosure trigger.
The names "BTP" / "Berkeley Transport Protocol"	Registered trademark of Security Ops	Protects end users from impostor implementations. See TRADEMARK.md.

BTP is freely implementable by anyone under the protocol specification. The reference implementation is Apache-2.0. The "BTP" name is a registered trademark of Security Ops (maintained by Cristian Cezar Moisés) — to use it, your implementation MUST pass the conformance test suite at crates/btp/tests/conformance/.

This is the same pattern used by Rust (Rust Foundation), Kubernetes (CNCF), and OpenSSL (OpenSSL Software Foundation): permissive impl license + protected trademark. Encourages adoption while preventing post-quantum-claiming forks that silently re-enable classical fallback.

For trademark licensing, conformance certification, or general inquiries: sac@securityops.co (PGP: https://securityops.co/.well-known/security.asc).

Related projects under different licenses

• Evelin (post-quantum transport library — separate repository at git.securityops.co/cristiancmoises/evelin) — AGPL-3.0-or-later + commercial. Strong copyleft; commercial license available.
• Zupt (compression codec — separate repository) — keeps its existing license.

The license difference is intentional: BTP is a protocol meant for wide adoption, so permissive. Evelin is an implementation of standardized PQ primitives, so AGPL gates commercial users into the dual-licensing conversation.

---

Citation

If you use BTP in academic or technical writing, please cite the whitepaper:

The v0.7.0 whitepaper is published on Zenodo with permanent DOI 10.5281/zenodo.20278231.

@misc{moises2026btp,
  author    = {Mois{\'e}s, Cristian Cezar},
  title     = {{Berkeley Transport Protocol (BTP): A Post-Quantum
                Application Substrate with Witness-Anchored Identity}},
  year      = {2026},
  publisher = {Zenodo},
  version   = {v0.7.0},
  doi       = {10.5281/zenodo.20278231},
  url       = {https://doi.org/10.5281/zenodo.20278231}
}

Plain-text:

Moisés, C. C. (2026). Berkeley Transport Protocol (BTP): A Post-Quantum Application Substrate with Witness-Anchored Identity (v0.7.0). Zenodo. https://doi.org/10.5281/zenodo.20278231

The whitepaper text is CC-BY 4.0; the reference implementation is Apache-2.0. The "BTP" name remains a registered trademark of Security Ops — see TRADEMARK.md.

---

Acknowledgements

BTP is built directly on:

• FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA), NIST's selected post-quantum standards.
• RFC 6962 (Certificate Transparency), whose Merkle tree structure inspired the KT log.
• RFC 8439 (ChaCha20-Poly1305).
• RFC 9116 (security.txt), for the vulnerability disclosure metadata format.
• The RustCrypto ecosystem (ml-kem, ml-dsa, chacha20poly1305, ed25519-dalek).
• The BLAKE3 team.
• The macaroons paper (Birgisson et al., NDSS 2014).

None of these projects endorse BTP. Any defects in the way BTP composes them are the maintainer's alone.

---

In Code We Trust.