Metadata Minimization & The AAD Shield
How Convro-6-Protocol achieves best-in-class metadata privacy through sealed sender, fixed-size padding, and cryptographic binding that crushes the competition.
The Sharp Line: Content vs Metadata
C6P draws a sharp distinction between message content (fully E2E encrypted) and metadata (minimized by design).
While message content is protected by end-to-end encryption, metadata can reveal who talks to whom, when, and how often. C6P minimizes metadata exposure through multiple layers of protection.
What the Server Never Sees
Message Plaintext
Content is encrypted end-to-end with C6P session keys
Sender Identity
Sealed sender hides who sent the message (server only knows recipient)
Message Size
Fixed 64KB padding hides actual content length
Exact Timestamp
Timestamps rounded to nearest 5 minutes with random 0-5s jitter
C6P is designed with privacy by default, not privacy as an opt-in feature. Sealed sender with 64KB padding is STANDARD, not optional. This means every user benefits from best-in-class metadata privacy automatically.
The 63-Byte AAD Shield
Additional Authenticated Data (AAD) cryptographically binds all context to prevent tampering, splicing, and downgrade attacks.
What is AAD?
AAD (Additional Authenticated Data) is metadata that's cryptographically authenticated but not encrypted. It ensures that envelope fields cannot be tampered with or reused in different contexts.
Canonical 63-Byte Layout
Security Properties
Protocol version and suite bound in AAD — tampering fails AEAD verification
Session binding prevents messages from being moved between sessions
Counter in AAD ensures duplicate messages are rejected even if AEAD verifies
Message type bound — DM cannot be relabeled as group message
AAD MUST be exactly 63 bytes in C6P v1. Any other length is an implementation bug and MUST cause fail-closed rejection. This is non-negotiable for security.
Session Binding: Device Pair Lockdown
Every message is cryptographically bound to the exact device pair that established the session.
Why Session Binding?
Without session binding, a malicious server could splice messages between different sessions or device pairs. Session binding prevents this by creating a unique fingerprint for each device pair.
Computation
session_binding = SHA-256(
"C6P_BIND_V1" ||
session_id(8 bytes) ||
initiator_device_id(16 bytes) ||
responder_device_id(16 bytes)
)
// Output: 32 bytes (256 bits)
// Included in every AAD constructionAttack Scenarios Prevented
Attack: Malicious server copies message from Session A to Session B
Defense: Different session_id means different session_binding → AEAD verification fails
Attack: Server delivers message intended for Device A to Device B
Defense: Wrong device_id means wrong session_binding → AEAD verification fails
Attack: Attacker intercepts and modifies AAD fields (suite, type, etc.)
Defense: Any AAD modification breaks AEAD authentication → rejection
Session binding is computed from canonical, locally trusted session state, not from attacker-controlled fields. The server cannot "fix" AAD to match a spliced message because it doesn't know the session keys.
Sealed Sender: Server Blindness
The server routes messages without knowing who sent them, protecting your social graph.
How Sealed Sender Works
Messages use a two-layer envelope structure: an outer envelope for server routing (recipient only) and an encrypted inner envelope containing sender identity.
Fixed 64KB Padding
All sealed messages are padded to exactly 64KB (65,536 bytes). This hides the actual message length from the server.
Every message exactly same size — no length analysis
Timestamps rounded to nearest 5 minutes
Delivery delay prevents correlation
| Mode | Server Sees Sender | Message Size | Timestamp |
|---|---|---|---|
| Standard | Visible | Variable (~2-10 KB) | Precise |
| Sealed | Hidden | Fixed 64 KB ALWAYS | Rounded (±5 min) |
How C6P Crushes the Competition
Side-by-side comparison shows C6P provides best-in-class metadata privacy by default.
| Metadata Type | Signal (Standard) |
Signal (Sealed) |
Convro (STANDARD) |
|
|---|---|---|---|---|
| Sender identity | Visible | Visible | Hidden | Hidden (ALWAYS) |
| Recipient identity | Visible | Visible | Visible | Visible |
| Message content | Encrypted | Encrypted | Encrypted | Encrypted (C6P) |
| Message size | Variable | Variable | Padded | Fixed 64KB (ALWAYS) |
| Exact timestamp | Precise | Precise | Precise | 5min rounded (ALWAYS) |
| Social graph | Full exposure | Full exposure | Recipient-only | Recipient-only (ALWAYS) |
| Timing jitter | None | None | None | 0-5s random delay |
Poor privacy (server sees everything)
Good E2E, but server sees social graph
Optional privacy enhancement
Key Takeaways
63-byte AAD cryptographically binds all context to prevent tampering and splicing
Session binding locks messages to exact device pair, preventing cross-session attacks
Sealed sender ALWAYS — server never knows who sent a message (privacy by default)
64KB fixed padding hides message length from traffic analysis attacks
Timestamp rounding + jitter prevents precise timing correlation (5min ± 0-5s)
Best-in-class privacy — C6P crushes WhatsApp and equals/exceeds Signal's sealed mode