🔍技术透明度
我们所看到的。
我们不做什么。
这不是营销页面。这是一个技术规范，明确说明City of Hats收集哪些数据、我们的服务器可以访问什么、不能访问什么以及我们的加密边界在哪里。
最后更新时间：2026 年 4 月🎯我们的立场
我们认为安全性应该得到证明，而不是声称。
City of Hats是一个年轻的平台。我们于 2026 年 3 月在应用商店推出。我们尚未开源。我们尚未完成独立审计。我们对此保持透明，并且正在积极努力缩小这些差距。同时，这里详细介绍了我们的系统实际执行的操作。
我们的承诺：我们将在此页面上发布我们第一次独立加密审计的完整报告。没有修订。
🛡威胁模型
我们防范 — 的措施和不防范的措施
没有哪个系统是无懈可击的。说明我们防御什么—以及我们的边界在哪里—比声称绝对安全更可信。
旨在防止
- ✅被动网络监控
- ✅服务器端数据访问（我们无法读取E2E消息）
- ✅通过电话号码或电子邮件进行身份关联
- ✅未来的量子攻击（混合 PQ 密钥交换）
- ✅泄露过去消息的密钥妥协（前向保密）
- ✅消息长度分析（元数据填充）
尚未正式评估
- ⚠民族国家的对手
- ⚠用户设备受损（操作系统级攻击）
- ⚠高级针对性攻击
- ⚠大规模流量分析（时间、频率模式）
诚实的建议： 具有高风险威胁模型的用户应结合多种安全工具和实践。没有一个应用程序是完整的安全解决方案。
🔒加密
加密架构
所有端到端的消息、呼叫和文件传输都使用客户端端到端加密。服务器从不保存用户对话的解密密钥。
Double Ratchet协议
与Signal相同的协议系列。每条消息都使用一个唯一的密钥。泄露一个密钥不会暴露过去或未来的消息（前向保密+未来保密）。
后量子混合体
密钥交换使用 X25519 + ML-KEM-768 (Kyber)。即使量子计算机将来打破了经典的密钥交换，消息仍然受到保护。
AES-256-GCM
所有消息有效负载、文件内容和呼叫信令均使用AES-256-GCM 验证加密进行加密。标头也被加密以防止元数据泄漏。
群组发送者按键
组消息使用带有 HMAC 链棘轮和 ECDSA 签名的发送方密钥协议。每个发送者都维护自己的密钥链，分布在加密的 1:1 通道上。
协议栈
密钥交换 → X25519 + ML-KEM-768（混合后量子）
Ratchet → Double Ratchet（Signal协议族）
对称密码 → AES-256-GCM
密钥派生 → HKDF-SHA-256
消息认证 → HMAC-SHA-256
签名 → ECDSA P-256（组）
密码 KDF → PBKDF2
运行时 → Web Crypto API（浏览器原生）
PQ 库 → @noble/post-quantum (ML-KEM-768)
密钥交换 → X25519 + ML-KEM-768（混合后量子）
Ratchet → Double Ratchet（Signal协议族）
对称密码 → AES-256-GCM
密钥派生 → HKDF-SHA-256
消息认证 → HMAC-SHA-256
签名 → ECDSA P-256（组）
密码 KDF → PBKDF2
运行时 → Web Crypto API（浏览器原生）
PQ 库 → @noble/post-quantum (ML-KEM-768)
验证我们的声明。完整的加密源代码、协议规范和架构文档均在 MIT 许可下发布：
github.com/City-of-Hats/coh-crypto-spec →
github.com/City-of-Hats/coh-crypto-spec →
👁数据可见性
我们的服务器可以看到什么和不能看到什么
该表准确记录了我们服务器上存在的数据。我们区分加密的内容（对我们来说不透明）和可见的内容。
| 数据类型 | 服务器访问 | 细节 |
|---|---|---|
| 留言内容 | ✕看不到 | 所有帽子对帽子消息都是端到端加密的客户端。服务器仅存储不透明的密文。 |
| 文件附件 | ✕看不到 | 文件在上传之前在客户端进行加密。服务器存储加密的 blob。 |
| 语音&视频通话 | ✕看不到 | 呼叫使用带有加密信令的点对点 WebRTC。服务器仅促进连接设置。 |
| Dead Drops / EchoDrops | ✕看不到 | 内容加密客户端。解密密钥位于 URL 片段中（从不发送到服务器）或从密码中派生。 |
| GhostFrame 有效负载 | ✕看不到 | 上传前嵌入并加密客户端的隐写内容。 |
| 私钥 | ✕看不到 | ECDH 和后量子私钥仅在设备上生成和存储。从未传输到服务器。 |
| 帽子代码 | ✓可见的 | 存储帽子标识符以路由消息。他们是化名的，与真实身份无关。 |
| 通道对 ID | ✓可见的 | A 记录 Hat A 和 Hat B 有一个通道。消息路由所需。 |
| 时间戳 | ✓可见的 | 消息发送/接收时间戳。订购和过期逻辑所需。 |
| 公钥 | ✓可见的 | ECDH 和 ML-KEM 公钥已发布以实现密钥交换。这是设计使然 — 公钥应该是公开的。 |
| 推送通知令牌 | ⚠仅元数据 | 存储设备推送令牌以传递通知。通知内容使用通用文本，而不是消息内容。 |
诚实披露： 与所有消息平台（包括Signal）一样，我们必须存储一些路由元数据来传递消息。帽子代码是化名的 — 不需要电话号码、电子邮件或身份。但我们确实知道帽子 A 在给定时间向帽子 B 发送了一条消息。
⚙加密模式
两条加密路径—如实解释
并非City of Hats中的所有内容都使用相同的加密路径。我们对服务器何时可以访问内容以及何时不能访问内容保持透明。
客户端E2E（默认）
用于所有帽子对帽子的消息、呼叫、dead drop、GhostFrames 和 EchoDrops。
- ✅发送前已在您的设备上加密
- ✅仅在收件人的设备上解密
- ✅服务器存储不透明的密文
- ✅即使被迫我们也无法解密
服务器端加密（有限）
仅用于系统生成的内容：平台公告和CHECK智能机器人。
- ⚠服务器生成并加密该内容
- ⚠服务器保存这些路径的加密密钥
- ℹ这仅适用于机器人/系统消息
- ✅用户间的聊天永远不会走这条路
为什么有两种模式？CHECK智能机器人需要在服务器端生成安全报告（它查询外部数据库）。平台公告向所有用户广播。这些不是私人对话—，它们是系统消息。所有用户到用户的通信都专门使用客户端 E2E。
📋日志记录策略
我们记录什么
我们主张准确披露记录的内容，而不是提出广泛的“无日志”声明。
| 类别 | 记录了什么 | 保留 |
|---|---|---|
| IP 地址（应用程序） | 速率限制使用 IP 地址的单向 SHA-256 哈希值。原始 IP 不存储在数据库中。标准 Web 服务器访问日志可能暂时包含 IP。 | 散列：持久。访问日志：定期轮换。 |
| IP 地址（网站） | 营销网站 (cityofhats.com) 收集访客分析，包括 IP 和大致地理位置。这与消息应用程序是分开的。 | 与消息身份无关。 |
| 留言内容 | 未登录。无法访问。存储端到端密文以供传递，然后根据用户配置的过期时间进行存储。 | 用户控制（刻录计时器、自动到期）。 |
| 错误/崩溃日志 | 用于调试的服务器端错误日志。它们包含错误类型和堆栈跟踪，而不是消息内容。 | 定期轮换。 |
| 速率限制事件 | 使用散列标识符记录以防止滥用。无留言内容。 | 滚动窗口。 |
| 账户数据 | 如果您使用 Auth0 (Google/Apple) 登录，您的身份验证提供商会共享一封电子邮件。匿名（仅帽子）帐户没有链接的电子邮件。 | 直至账号被删除。 |
🔑密钥管理
你的钥匙在哪里
私钥永远不会离开您的设备。这就是关键材料的处理方式。
| 钥匙类型 | 存放地点 | 服务器访问 |
|---|---|---|
| ECDH 私钥 | 仅设备（浏览器本地存储） | 从未传送过 |
| ML-KEM 密钥 | 仅设备（浏览器本地存储） | 从未传送过 |
| Double Ratchet状态 | 仅限设备。可选的加密备份到服务器（使用私钥派生的密钥加密）。 | 仅加密备份 |
| 群组发送者按键 | 仅设备（浏览器本地存储） | 从未传送过 |
| ECDH 公钥 | 发布到服务器进行密钥交换 | 可见（按设计） |
| ML-KEM 公钥 | 发布到服务器进行密钥交换 | 可见（按设计） |
已知限制： 因为这是一个 Web/PWA 应用程序，所以私钥存储在浏览器 localStorage 中。这是基于网络的加密信使的标准，但这意味着设备安全（屏幕锁定、全盘加密）至关重要。可选的 PIN 功能使用 PBKDF2 派生的加密技术封装存储的密钥，以提供额外的保护。
⚖法律要求
执法和法律要求
City of Hats Inc. 在加拿大安大略省注册成立，并根据加拿大法律运营。
- ✓ 我们无法提供消息内容。端到端加密消息以密文形式存储。我们不持有解密密钥。即使法律强制，我们也无法解密用户间的消息。
- ✓ 如果法律强制，我们可以提供： 帽子代码、通道对记录、时间戳、公钥和帐户电子邮件（如果用户通过提供商登录）。这与任何加密消息服务存储的元数据相同。
- ✓ 匿名帐户的数据最少。 在未登录的情况下创建仅帽子帐户的用户在我们的服务器上没有电子邮件、电话号码和身份信息。帽子代码是唯一的标识符。
- ✓ 我们将发布透明度报告。我们打算根据适用法律发布有关收到的法律请求和提供的数据的汇总统计数据。
- ✓ 权证金丝雀：City of Hats维护权证金丝雀。如果它被删除，则表明我们收到了秘密法律命令。
🛤信任路线图
我们下一步做什么
我们正在建立完全可验证的信任。这是我们的公共路线图。
技术透明度页面
这一页。对我们系统功能的详细、诚实的说明。 2026 年 4 月发布。
开源加密层
我们将把加密协议实现（Double Ratchet、后量子混合、群组发送密钥）作为开源发布以供独立验证。
独立安全审计
一家信誉良好的第三方公司将审核我们的加密实施。完整报告将在此处发布，未经编辑。
透明度报告
关于收到的法律请求、披露的数据和系统正常运行时间的定期报告。发布在此页面。
🤝自己验证一下
您不必相信我们
City of Hats 包含内置工具，供您验证加密是否按描述工作。
- ✓ 安全号码。每个通道显示从双方公钥派生的唯一安全号码。比较带外以验证没有发生中间人攻击。
- ✓ 密钥更改警报。如果联系人的加密密钥发生更改（新设备、重新安装），您会收到警报。这可以防止静默密钥替换。
- ✓ 审计日志链。加密审计日志使用哈希链，以便可以检测到对日志的篡改。
- ✓ E2E 指示器。 每个加密通道都会显示一个带有“E2E”的锁定图标，以确认该会话的客户端加密处于活动状态。
- ✓ 开放加密规范。我们完整的协议设计—密钥交换、Double Ratchet、后量子混合、组加密—已公开发布。自己回顾一下：github.com/City-of-Hats/coh-crypto-spec
📬接触
有问题或疑虑吗？
如果您是安全研究人员、记者，或者对我们的隐私实践有疑问，我们欢迎对话。
City of Hats Inc. · Toronto，加拿大 · 在安大略省注册成立