Hard-Chat – 无服务器、仅 RAM 的 P2P 终端聊天

就在您的浏览器中进行端到端加密的 P2P 聊天。没有服务器，没有帐户，没有存储的历史记录。由 Hardlint 网络安全团队开发 该项目是出于教育和安全研究目的而分发的。它不保证网络级匿名性：它保护对话内容，而不一定是连接者。在将其用于敏感通信之前，请阅读攻击面和已知限制部分。强烈建议在两台设备上使用值得信赖的 VPN。 🔐 端到端加密 — AES-GCM 256 位，通过 PBKDF2 派生密钥（100,000 次迭代） 🌐 真正的 P2P 连接 — 两个设备之间的直接 WebRTC 链接，无中央服务器中继消息 🚫 零持久性 — 无 Cookie、无 localStorage、无数据库：关闭选项卡，什么都不留下 🔑 单一共享秘密 — 随机生成的房间密钥（100字符），无需手动技术配置 🧹 紧急清除 — 一键立即擦除密钥、连接状态和可见的聊天历史记录 📡 可靠的连接 — 18 个 STUN/TURN 服务器配置为后备，即使在限制性 NAT（4G/5G、企业网络）之后也能工作 打开页面（必须通过 HTTPS 提供服务 — 例如通过 GitHub Pages，而不是作为本地文件打开） 主机：单击 [1] 初始化房间 →复制生成的房间密钥 通过其他渠道（面对面、语音通话、另一个加密应用程序）将房间密钥发送给您的联系人 访客：单击 [2] 连接到房间 → 粘贴收到的房间密钥 等待连接（通常需要几秒钟）→ 聊天打开 如果 2 分钟内未建立连接，房间密钥将自动过期：使用专用按钮生成新的房间密钥 支持 WebRTC 和 Web Crypto API 的现代浏览器（最新的 Chrome、Firefox、Edge、Safari） 两台设备均可访问互联网页面必须通过 HTTPS 提供服务（Web Crypto API 和 WebRTC 需要安全上下文）——作为本地文件打开时不起作用 双方在连接尝试期间必须同时打开页面 房间密钥必须完整复制，恰好 100 个字符，没有多余的空格或换行符 🏗️ 架构概述 零跟踪终端是一个静态 Web 应用程序（HTML/CSS/JS，无专有后端），允许两个设备建立直接连接通过 WebRTC 进行点对点连接，交换端到端加密文本消息。主要组件： 组件角色 技术 用户界面 复古终端 UI 纯 HTML/CSS 信令 使两个对等点互相“找到”对方 PeerJS（公共云代理） 数据传输 加密 P2P 通道 WebRTC DataChannel NAT 穿越 穿透防火墙/NAT STUN + TURN (ICE) 加密 消息内容保护 AES-GCM 256 位 + PBKDF2 托管 代码分发 GitHub 页面（静态） 没有专有应用程序服务器：代码完全在每个用户的浏览器中运行。所涉及的唯一外部基础设施用于将两个设备相互“引入”（信令），并在需要时在无法直接连接时中继流量 (TURN)。当用户单击“初始化房间（主机）”时：使用 crypto.getRandomValues() 生成一个随机的 100 个字符的字符串（generate100CharCode()）——一个加密安全的随机数生成器（不是 Math.random() ，它不适合加密目的）。字符集包括大写/小写字母、数字和特殊符号（ -_!@#$%^&* ），最大化 100 个字符内的熵。该字符串（房间密钥）是双方需要在带外交换的唯一共享秘密（例如语音消息、面对面、另一个加密通道）。从房间密钥导出密钥 从房间密钥导出两个独立的值，每个值都有不同的用途： A. 消息加密密钥 (PBKDF2 → AES-GCM) PBKDF2(password = Room Key, salt = "p2p-zero-trace-salt-v1" (fixed,hardcoded), iterations = 100,000, hash = SHA-256 ) → 256-bit AES-GCM key B. PeerJS 标识符（截断的 SHA-256） SHA-256（房间密钥）→ 前 32 个十六进制字符，前缀为“ztt-”。此 ID 仅用于主机和访客可以在 PeerJS 信令代理上“找到”彼此，而无需交换房间密钥之外的任何内容。它不发挥加密作用。关于固定盐的注意事项：PBKDF2 盐是硬编码的，并且在所有会话中都是相同的。这是可以接受的，因为“密码”（房间钥匙）已经具有非常高的熵（100 个随机字符）——固定盐只会在涉及弱密码、重复使用密码的情况下削弱安全性，这在此处不适用。主机创建一个 Peer 对象，使用从 Room Key 派生的 ID 向公共 PeerJS 云代理注册。客人在粘贴相同的房间密钥后，计算相同的 ID 并调用 peer.connect(id) 。 PeerJS 代理仅调解此初始交换（谁想与谁交谈）——它永远不会看到或传输消息内容，此时消息内容会通过单独的 WebRTC 通道传输。 ICE协商（NAT穿越） 一旦两个Peer“自我介绍”完毕，WebRTC就开始ICE协商