Secure Drop
Anonymous · Encrypted · No login required
Your message is sealed and anonymous. We cannot identify you. No account or login is needed.
Your message
Max 3 files, 10 MB each
Powered by City of Hats · Get your own Secure Drop
Secure Channel
Anonymous · Bidirectional · Encrypted
Start an anonymous conversation. You'll receive a thread code to check for replies later.
Your message
Max 3 files, 10 MB each
Thread Code
Enter your thread code above to check for replies.
Powered by City of Hats · Get your own Secure Channel
TRUST, WITH RECEIPTS

Security Evidence Center

A living record of what City of Hats claims, what supports each claim, where the protection applies, and where it stops.

Reviewed 10 August 2026First-party evidence is identified as such. No independent cryptographic audit has been published yet.
6Core claims documented
PublicEvidence and limitations
PendingIndependent cryptographic audit
SECURITY CLAIMS REGISTRY

Every claim needs a boundary

These entries describe the current published architecture and observable product behavior. They are first-party claims unless an independent source is explicitly named.

01Documented

Hat content is end-to-end encrypted

City of Hats documents client-side encryption for Hat-to-Hat messages, files, and calls so delivery infrastructure handles encrypted content rather than conversation plaintext.

ScopeHat-to-Hat communication on supported City of Hats clients.
EvidenceThe technical specification names hybrid X25519 and ML-KEM-768 key establishment, a Double Ratchet, and AES-256-GCM authenticated encryption.
Important limitationEncryption does not protect plaintext on a compromised or unlocked endpoint, or against a recipient who records what they can read.
Read the technical specification
02Observable

A Hat needs no phone number or email

A person can create a pseudonymous Hat and be reached through a Hat code or Phrase ID without registering a carrier number or mailbox identity.

ScopeCore consumer Hat creation; paid, administrative, support, or billing services may collect separate account information.
EvidenceThe public Hat creation flow can be tested without submitting a phone number or email address.
Important limitationPseudonymity is not absolute anonymity. Devices, networks, voluntarily shared details, and operational connection data remain part of the threat model.
See pseudonymous identities
03Observable

There is no provider-held conversation recovery vault

The consumer messenger is designed without a City of Hats backup vault able to restore a lost Hat conversation history.

ScopeConsumer Hat messages and device-held conversation state; separate business records follow the Privacy Policy.
EvidenceProduct recovery behavior and the published privacy documentation state that City of Hats cannot restore destroyed or device-lost conversation content.
Important limitationThis is also an availability tradeoff: losing the only authorized device can mean permanently losing the messages.
Read the data-handling policy
04Documented

Key establishment uses a post-quantum hybrid

The published design combines classical X25519 with ML-KEM-768 before deriving keys used by the conversation protocol.

ScopeSupported Hat sessions on clients running the current protocol version.
EvidenceNamed algorithms and the hybrid construction are documented on the Transparency and Secure Chats pages.
Important limitationNaming strong algorithms is not an independent implementation audit. Security also depends on integration, key handling, clients, and future cryptanalysis.
Review the secure-chat design
05Documented

Calls do not expose a direct peer IP

Voice and video are designed to use relayed encrypted media rather than a peer-to-peer media path that reveals each participant’s IP address to the other.

ScopeCity of Hats voice and video calls using the documented relay architecture.
EvidenceThe Encrypted Calls and Transparency pages describe relay-only media and fresh call encryption keys.
Important limitationThe relay and network providers still process connections for delivery. Relaying does not hide an endpoint from its own network or defeat device compromise.
See encrypted call architecture
06Observable

Senders can reduce exposure after sending

Security modes such as View Once, Recall, GeoLock, Certified Send, Invisible Watermark, and Channel Seal restrict ordinary access, retention, or disclosure.

ScopeMessages and files sent with the selected control on supported clients.
EvidenceControls and their recipient flows are visible in the product and documented on their feature pages.
Important limitationNo application can make an authorized recipient forget, prevent every external camera, or secure plaintext already captured outside the protected viewer.
Inspect the security modes
ARCHITECTURE PATH

Where the trust boundary sits

The intended protection path begins and ends on authorized devices. The service routes encrypted material and the public information needed to establish secure sessions.

1

Hat on device

The user creates a pseudonymous communication identity on an authorized client.

2

Hybrid agreement

X25519 and ML-KEM-768 contribute to session key establishment.

3

Encrypt locally

The Double Ratchet advances keys and AES-256-GCM protects message content.

4

Opaque relay

Infrastructure routes ciphertext, public keys, and the limited operational data needed for delivery.

5

Decrypt locally

An authorized recipient device authenticates and opens the protected content.

This diagram summarizes City of Hats’ current first-party specification. It is not a substitute for source review, implementation testing, or an independent cryptographic audit.
DATA BOUNDARY

What exists where

“Zero knowledge” describes access to protected conversation content—not the absence of every operational record. The distinctions below matter.

Data classWhere it originates or remainsServer roleCity of Hats access
Message, file, and call plaintextAuthorized endpoints before encryption or after decryptionCarries encrypted payloads or mediaNot intended to be available under the documented architecture
Conversation private keysAuthorized endpointsNot sent as provider-held recovery keysNo access under the documented design
Public keys and transparency entriesGenerated by clients and published for secure session setupDirectory and signed-log distributionYes—public key material, not conversation private keys
Hat, channel, timing, and delivery identifiersCreated during identity, channel, and delivery operationsRoutes traffic and manages lifecycle stateLimited operational access; not message plaintext
Network connection dataDevices and network infrastructureConnections must be processed to deliver trafficLimited operational processing; review the Privacy Policy for current handling
Billing, support, and business account dataOnly when a person uses those separate servicesAccount administration, support, or payment workflowsAs described in the Privacy Policy; not required for basic Hat creation
THREAT MODEL

What this design helps—and what it cannot solve

A useful security claim names the adversary, the protected asset, and the assumptions that must remain true.

Designed to help with

  • Network interception of message content in transit.
  • A delivery server or service operator attempting to read ordinary conversation plaintext.
  • Phone-number and email correlation during basic Hat creation.
  • A later provider-side request to recover a conversation vault that the messenger does not maintain.
  • Direct peer IP disclosure during calls using the relay-only design.
  • Unnecessarily persistent identities and message exposure when ephemeral controls are used.

Does not eliminate

  • Malware, an unlocked device, notification leakage, or compromised input and accessibility tools.
  • A legitimate recipient copying, photographing, quoting, or remembering content.
  • All timing, traffic, connection, and device metadata throughout the wider network.
  • Availability failures, blocking, rate limits, or loss of the only authorized device.
  • Human mistakes such as sharing a Phrase ID, unlock code, or sensitive detail with the wrong person.
  • Software defects or implementation weaknesses that have not yet been found.
EVIDENCE MATURITY

Claimed is not the same as independently verified

We label the strength and origin of evidence instead of collapsing every source into a green checkmark.

Available

Published documentation

Algorithms, data boundaries, intended behavior, tradeoffs, and product controls are described in first-party technical and policy pages.

Available

Observable behavior

Visitors can create a Hat without a phone or email and test supported security, delivery, destruction, and recipient flows.

Not yet published

Independent cryptographic audit

No independent cryptographic audit report is currently published. When one is available, this status will link to the report and remediation record.

VERIFY FURTHER

Follow the evidence trail

Use the detailed specification, policies, product behavior, and source-backed explanations together.

Technical TransparencyAlgorithms, server-visible data, keys, calls, and audit status.Open specification →E2EE BoundariesA sourced explanation of what end-to-end encryption does and does not protect.Read the guide →Privacy PolicyCurrent data categories, purposes, third parties, retention, and user rights.Review policy →Warrant CanaryThe current public statement concerning secret legal demands.Check status →Comparison MethodFact-checked comparisons with official sources and dated review labels.Compare platforms →Security ModesThe visible behavior and limits of sender-controlled protection modes.Inspect controls →Threat Model AdvisorBuild a practical security plan for your situationStart the assessment →
RESPONSIBLE DISCLOSURE

Found something that could make us safer?

Report suspected vulnerabilities in good faith. Start with enough detail for triage, but do not include live user secrets or unnecessary personal data in the initial message.

Start a security reportView security.txt
  1. Describe the affected product, version, URL, or feature and the security impact you believe is possible.
  2. Provide safe reproduction steps or a minimal proof of concept. Do not access data that is not yours.
  3. Use the contact form for the initial report. We can establish a protected channel before exchanging sensitive technical material.
  4. Allow a reasonable remediation period before public disclosure and avoid service disruption, extortion, or social engineering.
STRAIGHT ANSWERS

Evidence Center FAQ

Is this page an independent security audit?

No. It organizes City of Hats first-party claims, observable behaviors, limitations, and supporting pages. No independent cryptographic audit report has been published yet.

Does “zero knowledge” mean City of Hats processes no data at all?

No. It describes the intended inability to access protected conversation plaintext and private conversation keys. Routing, public keys, lifecycle state, network connections, and separate business services still require carefully limited operational data.

Can encryption protect a compromised phone or a hostile recipient?

Not completely. Plaintext exists on authorized endpoints. Malware, an unlocked device, notification previews, or a recipient using another camera can bypass protections that secure content in transit or within the application.

How do I report a vulnerability?

Use the contact path listed in security.txt for the initial report and avoid including live secrets. City of Hats can establish a protected channel for sensitive reproduction material.

Read the specification, not just the summary

The Evidence Center indexes the claims. Technical Transparency provides the detailed system description, while the Knowledge Center explains the security concepts and tradeoffs.

Open Technical TransparencyRead the E2EE guide