The most secure
web protocol
is BTP.
Berkeley Transport Protocol is the first application protocol designed with post-quantum cryptography as a normative property — not optional, not retrofit, not negotiable. Built to replace HTTPS for a threat model that includes quantum adversaries, mass surveillance, and compromised certificate authorities.
Connect to this server
You are viewing the discovery portal for this BTP origin. Below are the live connection parameters, the BLAKE3-256 fingerprint to pin, and three ways to fetch signed documents from this server.
btp.securityops.co
3004
7f24c0a217230af47f795bab43240389e46ca103685ff45baa4048825a50a129
btp://btp.securityops.co:3004
Browser (easiest)
The HTTPS gateway fetches signed .btp content, verifies the ML-DSA-87 signature server-side, and renders HTML. Lowest guarantees: you trust this server to not lie about signature validity.
Open gateway →Android app
The BTP Android app fetches via HTTPS gateway, then verifies any .btp file locally on-device with ML-DSA-87. Compose, sign, and share — all on-device, no server involved.
Download APK →Native client (full PQ)
btpview speaks BTP directly over raw TCP, performs ML-KEM-1024 key exchange end-to-end, and verifies ML-DSA-87 locally. Pin the fingerprint to detect future tampering.
CLI instructions →BTP vs the modern web stack
Evaluation across seven critical dimensions against the protocols that actually carry today's internet: HTTPS, HTTP/3, gRPC, and WebSocket Secure. Scores reflect protocol-level design, not implementation quality of specific products.
Why BTP is the most secure
Security in BTP is not configuration — it is a property of the protocol. Normative ML-DSA-87, the absence of privileged JavaScript for cryptography, content addressing via BLAKE3-256, and mandatory key transparency eliminate entire classes of attacks that HTTPS, HTTP/3, gRPC, and WebSocket carry by inheritance.
by design
What makes BTP immune by construction
Threat matrix by protocol
Each row is a real and well-documented attack class. Columns show whether each protocol resists by design, is partially mitigated, or remains structurally vulnerable.
Comparative radar
Seven dimensions in a single visualization. BTP occupies the largest polygon in every critical security dimension.
Smaller surface, safer protocol
Attack surface index based on exposed vectors: cookies, privileged JavaScript, centralized CA, ASCII parsing, protocol fallback, fingerprinting headers, connection coalescing, and tracking primitives.
BTP v0.7.0 — Architecture & Specification (pre-1.0)
Reference documentation for the current pre-1.0 reference implementation. Sprints 1–6 complete with every component verified end-to-end. Documentation kept in English for technical accuracy.
Architecture Overview
BTP is a layered protocol with strict separation between transport, application semantics, and document format. Each layer is pluggable: the transport trait abstraction allows swapping TCP for Evelin (post-quantum AEAD) without touching higher layers.
The wire format uses CBOR for type-safe binary frames, eliminating entire classes of ASCII parser confusion attacks that plague HTTP. Every frame is length-prefixed, CBOR-tagged, and includes a stream identifier.
Core Components
The reference implementation is organized into focused Rust crates and binaries. All code is memory-safe with zero unsafe blocks. CI runs on Ubuntu, macOS, and Windows.
.btp documents over the configured transport. Sprint 3+.genkey, doc, cap, echo, fetch.Wire Format
BTP frames are length-prefixed, CBOR-encoded binary structures. Stream IDs use 62-bit varints with the low bit indicating direction (server-initiated vs client-initiated).
Cryptography
BTP uses post-quantum primitives normatively. There is no negotiation, no fallback, no downgrade path. Implementations that do not implement these primitives are not BTP-compliant.
- Signatures:
ML-DSA-87(FIPS 204, formerly Dilithium-5) — 4627-byte signatures, 2592-byte public keys - Hash:
BLAKE3-256for content addressing, KT log internal hash, and digests - Domain separation:
b"BTP/v1"applied to all signature inputs (SPEC §2.4) - Next transport: Evelin with
ML-KEM-1024+ChaCha20-Poly1305+Argon2id - Banned primitives: RSA, ECDSA, Ed25519, X25519, SHA-1, MD5 — explicitly forbidden by spec
Document Format (.btp)
A .btp document is a CBOR-encoded structure containing a header, a sequence of content blocks, and an ML-DSA-87 signature over the entire content. The content digest (BLAKE3-256) is the document's canonical address.
Capabilities
BTP uses macaroon-style capabilities for authorization. Capabilities can be attenuated client-side without contacting the issuer — restricting scope, expiration, or path. This makes bearer-token theft fundamentally less dangerous: a stolen capability is already constrained.
Key Transparency
Every origin's signing key MUST appear in a public Merkle log (BLAKE3-256, RFC-6962 style). Clients reject responses without a verifiable inclusion proof. This eliminates the central-CA-compromise attack vector that haunts HTTPS.
- Public, append-only, Merkle-tree-backed log
- BLAKE3-256 internal hash; ML-DSA-87 log signatures
- Mandatory inclusion proof in every response (KTPROOF frame)
- Out-of-band auditors verify log consistency via gossip protocol
- Origin key rotation creates a new log entry; old keys remain auditable
Normative Requirements
These are protocol-level requirements. Implementations that violate any of them are not BTP-conformant. There are no optional bypasses.
- MUST use ML-DSA-87 for all signatures. No classical fallback permitted.
- MUST verify Key Transparency inclusion proof before accepting any response.
- MUST NOT implement, send, or accept cookies, User-Agent, or Referer headers.
- MUST isolate connections per origin. Cross-site connection coalescing is forbidden.
- MUST NOT allow JavaScript or any client-side scripting to handle protocol-level cryptography.
- MUST address documents by BLAKE3-256 digest. URL-only addressing is forbidden.
- MUST use CBOR for all frame encoding. ASCII parsing is forbidden in the wire format.
- MUST reject any document whose signature fails verification, even if served over an authenticated transport.
Continuous verification
Every sprint maintains the invariant of all tests passing with zero clippy warnings. CI matrix covers Ubuntu, macOS, and Windows. Below is the breakdown of the 50 tests that gate every commit.
Where BTP is going
Sprint timeline with clear deliverables. Each sprint ends with verified, tested, documented code — no work-in-progress reaches production.
The Security Ops ecosystem
BTP is the core protocol of a coordinated suite of tools: post-quantum transport, compression codec, browser, and a publishing app — all designed to work together.
Run BTP in two minutes
Clone the repository, build with cargo, run the daemon. The reference implementation is Apache-2.0. The protocol spec is CC-BY 4.0. "BTP" is a registered trademark — see TRADEMARK.md.
01 · Installation
Build from source
Clone the repository and build with cargo. Rust 1.75+ required.
02 · First Request
Serve and fetch a document
Generate a key, sign a document, start the daemon, and fetch it with the CLI client.