Signal 无号码注册以零知识证明取代电话号码验证
尽管多年来一直强制要求验证电话号码，Signal 无号码注册如今已从用户长期以来的诉求，发展为可运行的 Android 代码。近期提交新增了无号码账户创建、登录、支付处理、恢复及端到端测试。代码还采用了一种零知识凭证，使用户能够在注册时证明自己获得授权，而无需暴露底层购买记录。
这一组合至关重要，因为移除电话号码会带来棘手的滥用问题。电话号码从未保证对应真实身份，但获取号码会给创建一次性账户的人增加成本和阻力。Signal 似乎准备以付费凭证替代这道并不完美的屏障，同时将付款与最终生成的账户分离。
这不只是又一项隐私设置。Signal 在 2024 年推出了用户名，但用户注册时仍需提供电话号码。SimpleX 等服务已将无标识符通信置于其设计核心。Signal 现在正测试：一款主流加密通讯工具能否移除电话号码，同时不让购买行为成为持久的追踪机制。
Signal 无号码注册现已出现在 Android 代码中
Signal 尚未宣布公开上线，但其 Android 代码库显示出一套协调统一的无号码注册流程，而非孤立的实验。
2026 年 9 月 2 日，Signal 开发者将“无号码账户”注册功能提交至公开 Android 代码库。该提交修改了 49 个文件，新增 871 行代码、删除 359 行。其范围覆盖注册界面、账户状态、网络请求、恢复、测试和用户名创建。
代码改动允许注册系统将电话号码视为可选项。它们还让应用能够识别主设备没有电话号码标识符（内部称为 PNI）的账户。这一区别并不止影响首次注册界面。
Signal 的应用此前假定主账户拥有 E.164 格式的电话号码，即用于表示电话号码的国际格式。无号码支持迫使客户端重新审视所有依赖号码的既有假设，包括注册、恢复、联系人发现和账户状态。
同一批 9 月 2 日的提交还隐藏了不适用于无号码账户的设置，包括电话号码可发现性控制及部分 PIN 提醒。其他改动增加了专用的无号码国家代码配置，并支持登录已有的无号码账户。
另一项提交引入了 Signal zkgroup 加密库中的新凭证。该库支持保护隐私的凭证和群组操作。注册客户端可在创建账户时出示这类凭证，而无需提供电话号码。
9 月 9 日，Signal 又跟进加入了支付处理及更多无号码账户修复。这些新增内容涵盖备份引导、账户恢复、联系人发现、多设备同步和注册锁错误。Signal 还新增了 619 行“注册测试”，覆盖无号码流程。
这一覆盖范围意义重大。原型可能止步于展示一个新的注册界面；这些提交则处理了那些不太显眼、却往往会阻碍身份系统变更真正触达用户的依赖项。
根据代码库信息，该功能仍在内部构建版本中受限启用。公开 Android 用户不应将已合并的代码解读为立即可用。Signal 尚未公布上线日期、支持国家或地区列表、支付政策，或最终用户文档。
因此，现有证据仅支持一个有限结论：Signal 正在积极实现和测试无号码账户，包括其支付和隐私机制。但这尚不能说明 Signal 无号码注册何时会成为面向所有用户的功能。
这一区别对现有用户尤其重要。可见代码能够创建和恢复无号码账户，但并未明确承诺已注册用户可以移除已绑定的号码。一名社区参与者询问既有账户是否可以解绑，另一名贡献者表示现有改动尚不能证明提供了这一选项。
因此，首个版本可能支持创建新的无号码账户，却不转换旧账户。它也可能按平台、地区或测试群组限制这一功能。在 Signal 公布其设计前，这些问题仍未有定论。
Signal 为什么需要替代电话号码验证的机制
移除电话号码，也意味着移除了 Signal 一直用于减缓自动化注册和一次性账户滥用的一种稀缺资源。
电话号码在通讯系统中承担多项功能。它们帮助用户发现联系人，提供熟悉的恢复渠道，并形成用户容易理解的账户标识符。当攻击者需要注册数百或数千个账户时，电话号码也会带来成本。
但这些好处并不意味着电话号码天然具备隐私性或安全性。号码往往与法定身份、账单记录、雇主和位置历史有关。用户也可能因号码重新分配、账户注销或 SIM 卡交换攻击而失去它们。
Signal 在 2024 年推出用户名和新的隐私控制措施时，减少了人际间的信息暴露。其官方“用户名设计”允许用户在不分享号码的情况下发起对话。用户名必须完全匹配，且 Signal 不提供可搜索的公开目录。
不过，用户名改变的是发现方式，而非注册流程。Signal 现有的支持文档仍称，该服务使用现有电话号码。在传统账户创建过程中，号码必须能够接收短信或电话。
这一缺口多年来一直令注重隐私的用户感到挫败。记者可能希望公开 Signal 用户名，而不暴露个人号码；组织者可能需要一个独立身份，却不想另购一条移动通信线路；平板电脑用户则可能根本没有可用号码。
对于电话号码记录可被雇主、电信公司或政府获取的人而言，风险更大。端到端加密能够保护传输过程中的消息内容，但无法抹除获取和维持电话号码时产生的每一项外部记录。
然而，若直接取消号码要求，账户创建将变得低成本且可重复。垃圾信息发送者可能在被封锁后不断更换用户名。诈骗运营者可以重建账户库存，而自动化系统可能淹没消息请求或基础设施。
Signal 已限制陌生发送者可以执行的操作，但内容加密限制了服务器端审核。该服务无法像未加密平台那样检查每一段对话，并对滥用文本进行分类。因此，注册环节的阻力具有更大分量。
一名社区参与者指出了另一个规避问题：如果用户能用一个号码注册后立即解绑，该号码就可能生成大量免费账户。冷却期可以减缓这一循环，但有决心的攻击者可以等待，或分散其活动。
支付要求提供了另一种稀缺资源。它要求每位注册者取得有效购买凭证，而非有效电话号码。这笔费用可遏制批量创建，同时不要求 Signal 保留与电话号码关联的身份信息。
这种方法是转移压力，而非消除压力。支付系统会产生自身的记录、地域限制和访问障碍。没有受支持支付方式的人可能会发现，无号码注册比短信验证更难使用。
应用商店运营方也可能知道购买已发生。Google Play、金融中介机构或其他支付提供商可能将该交易与既有账户关联。核心隐私问题在于，Signal 能否在不知道最终通讯账户由谁购买的情况下兑换这笔购买。
这正是零知识凭证进入设计的原因。它旨在将原本会一同出现的两项陈述分开：存在一笔有效购买；以及这个特定的 Signal 账户完成了该购买。
零知识凭证如何切断支付关联
这一拟议机制让 Signal 能够验证资格，同时避免形成将付款直接关联至新账户的可重复使用记录。
零知识证明允许一方证明某项陈述为真，却不揭示该陈述背后的秘密。在这里，相关陈述并非用户姓名或财务身份，而是注册者持有获授权的收据凭证。
可见的 Android 代码会创建随机化的收据请求，并通过与支付相关的注册端点发送。购买验证后，客户端接收凭证响应，随后检查该响应，并构造用于账户注册的凭证出示内容。
这一过程采用盲签名凭证概念。盲凭证允许签发方授权一个隐藏值，而不会以日后可识别的形式得知该值。用户之后可以证明自己持有该凭证，同时限制签发与兑换之间的可关联性。
从实际角度看，Signal 的支付服务可以验证购买令牌，并签发加密收据。注册服务随后可以验证该收据的出示内容。设计正确的协议可防止服务器将该出示内容与先前的签发记录进行匹配。
9 月的代码通过多个彼此独立的对象使这种分离变得可见，其中包括收据序列号、请求上下文、凭证响应、凭证和凭证出示内容。客户端创建请求上下文时会引入随机性。
支付实现还将购买视为可重复购买的产品类别，而非订阅。可见的“支付流程”支持反复购买同一项一次性商品。它会在发起另一笔收费前检查是否存在未消耗的购买。
成功兑换后，应用可以消耗购买令牌。这样既可让商店商品再次购买，也能防止同一令牌反复授权注册。这一细节将反垃圾信息目标与凭证设计联系起来。
因此，该系统需要同时具备两种保护。凭证应有足够的不可关联性来保护注册者；兑换规则则必须阻止重复使用。任一环节薄弱，都会削弱该功能。
若支付与注册记录被直接关联，无号码注册就只是以金融标识符替代电信标识符。这或许能带来便利，但无法实现该功能所暗示的隐私改进。
若凭证可被复制或重放，攻击者就能一次购买、创建多个账户。Signal 将因此失去促使其引入付费机制的抗滥用能力。代码中的收据序列号、验证步骤和消耗流程，似乎正是为了防止这一结果。
Signal 此前已在其他场景应用过相关的密码学理念。其私密群组系统使用匿名凭证，使服务器能够在常规运行中执行群组操作，而无需获知群组成员身份。捐赠徽章同样使用收据凭证，将付款与个人资料徽章分离。
这段历史降低了实现层面的新颖性，但并未消除部署风险。复用经过审查的原语比另起炉灶更安全。注册流程仍会引入新的端点、状态转换、商店依赖与故障情形。
公开可见的源代码同样无法证明生产服务器保留了哪些信息。客户端密码学能够限制有效协议所泄露的内容。研究人员仍需获得最终服务器实现、协议规范、数据保留政策及部署行为，才能评估这项主张的完整性。
Signal 早前关于“私密发现”的工作体现了同样的理念：在可行时，其客户端应避免将明文社交关系图谱托付给服务器。无手机号注册将这一原则延伸至账户创建环节。
这一机制保护的是一种特定关系，而非所有形式的元数据。商店仍可能知道有人购买了与 Signal 相关的项目。按照其常规服务架构，Signal 仍可观察网络请求、时间信息、设备信息及后续账户活动。
因此，用户应准确理解“零知识”。它描述的是在特定协议中证明所隐藏的内容，并不意味着每个参与方对每个事件都一无所知。
对于高风险用户而言，时间信息尤其重要。购买凭证后数秒内立即兑换，可能会允许跨独立系统进行关联。网络隔离、批量处理、延迟兑换或其他操作选择，或许能减少这类暴露。
Signal 尚未说明最终工作流是否会引入此类措施。它也尚未说明其服务器会接收或保留哪些支付元数据。这些未披露之处，比附加在密码学上的令人安心的标签更重要。
无手机号注册改变 Signal 的竞争定位
Signal 正从在对话中隐藏电话号码，转向在账户创建阶段移除电话号码；而多家以隐私为先的竞争者早已将此作为差异化优势。
WhatsApp 仍以电话号码为账户注册核心，尽管它同样使用 Signal Protocol 进行消息加密。Telegram 在常规注册中也使用电话号码，并提供用户名用于发现联系人。这些设计保留了便捷的联系人匹配能力，却也继承了以手机号作为身份标识的隐私代价。
Signal 历来处于相似位置。它的消息加密获得了广泛好评，但批评者仍可指出，强制电话验证构成了一条基础性的身份关联。用户名降低了联系人之间的信息暴露，却未消除注册时的这条关联。
Signal 的无手机号注册将缩小它与围绕替代性标识符设计的服务之间的差距。例如，SimpleX 表示其网络不会为用户分配全局标识符。联系人通过邀请链接和成对地址连接，而非通用的电话号码或用户名。
Session 使用账户标识符而非电话号码，并通过去中心化网络分发消息路由。Matrix 允许用户在独立运营的服务器上创建账户，通常使用绑定所选 homeserver 的用户名。每条路径都在发现、审核、元数据和可用性之间作出不同取舍。
Signal 并未采用这些系统的架构。它仍是一项集中运营的服务，客户端与服务器之间的关系受到严格控制。无手机号工作改变的是其注册凭证，而非其联邦化方式或基础设施治理模式。
这一重点符合 Signal 所宣称的优先事项。集中运营使其能够更新协议、部署滥用防控措施并协调客户端行为。即使加密将可获得的数据降至最低，这也会让对 Signal 实现与政策的信任更加集中。
因此，竞争格局的变化并不等同于“Signal 变得匿名”。无手机号账户仍可能拥有用户名、个人资料名称、设备、网络地址、联系人和行为模式。隐私取决于这些信号如何与用户的现实身份相互关联。
改变的是，加入前必须提供一个电话端点这一默认要求。此事意义重大，因为电话号码是异常持久且高度互通的标识符。它们贯穿消息、银行、广告、就业和政府系统。
付费凭证则具备不同属性。它可以施加经济门槛，却无需成为联系人使用的地址。如果其密码学隔离有效，购买行为便可授权注册，而不会持续绑定到账户上。
这一设计也改变了易用性的竞争。Signal 可以保留用户熟悉的用户名和完善的联系人体验，同时提供更私密的加入路径。围绕匿名标识符构建的竞争产品，往往要求用户理解邀请链接、服务器选择或不熟悉的恢复模型。
不过，Signal 的做法可能会排除无法使用受支持商店或支付渠道的人。隐私工具常为受限环境中的用户服务，其中包括应用商店受限地区的用户。一个依赖支付的选项，需要比单一 Android 计费集成更广泛的可及性。
目前的提交仅展示了 Google Play 计费支持，而非 Play 版本可能会提示无法购买。这立即引发了替代 Android 商店和直接安装应用包用户的疑问。Signal 尚未公布最终的跨平台方案。
Apple 平台将需要自身的实现与审核。按照如今移动客户端的既有假设，桌面设备无法创建主账户。一次完整发布必须决定哪些设备与支付组合可以创建无手机号身份。
与电话验证的比较也会因地区而异。SMS 投递在一些国家可能失败，而预付费号码在其他地区仍较易获得。商店计费可能对一位用户运行良好，却对另一位用户完全不可用。
Signal 需要将无手机号注册呈现为一项具有明确限制的选项。若将其视为电话号码的通用替代方案，便会夸大当前代码所支持的能力。最强的设计或许是保留多种注册路径，同时清晰说明各自的隐私属性。
最棘手的问题始于证明成功之后
零知识凭证可以切断一条关联，但账户恢复、滥用控制、支付可及性与元数据，决定了整套系统是否值得信任。
账户恢复是第一个压力点。电话号码为用户提供了找回身份的外部渠道，尽管这一渠道也会带来 SIM 卡劫持风险。无手机号账户必须依赖秘密信息、设备、备份或其他凭证。
Android 改动包含对无手机号登录的密码管理器支持，以及调整后的备份引导流程。它们还移除了无手机号账户的部分 PIN 行为。这些细节表明，Signal 预期恢复材料将承担更多责任。
这项转变可为谨慎用户提升安全性。但当用户遗失凭证或未保存恢复密钥时，也可能导致永久失去账户。Signal 必须在注册前，而非设备丢失后，说明这一后果。
代码提及账户熵池，这是一种用于备份与恢复工作流的高熵秘密信息。密码管理器能够比人类记忆更可靠地保存此类信息。但缺少密码管理器的用户，仍需要一种安全且易于理解的替代方案。
滥用是第二个压力点。只有当成本和兑换规则能实质影响攻击者时，支付才会抑制大规模注册。欺诈活动可能利用被盗支付工具、遭入侵的商店账户或退款方案。
Signal 还必须决定封禁如何与新凭证互动。若被封禁者能立即购买另一份注册凭证，系统只会制造摩擦，无法阻止其持续行为。若 Signal 为执行封禁而关联过多信息，又会削弱隐私承诺。
这种张力无法单靠密码学解决。零知识证明可以表明有效购买确已发生，并防止简单重放；它们无法决定 Signal 应收集哪些滥用信号，也无法决定服务应多积极地关联这些信号。
支付可及性构成第三项担忧。可见的 Android 工作依赖 Google Play 作为已实现的购买路径。根据代码注释，缺少 Play 计费功能的设备会返回不可用状态。这包括部分注重隐私的 Android 配置和分发渠道。
因此，一项旨在减少对电信公司的依赖的功能，反而可能加深对应用商店运营商的依赖。Google 可能不会知道最终的 Signal 账户，但它可以知道其客户购买了 Signal 注册项目。
这种区别有意义，但并不完整。一些用户主要希望让其 Signal 账户与电话号码脱钩；另一些用户也希望避免留下表明使用 Signal 的商店或金融记录。
Signal 最终或可支持替代支付提供商或代金券，也可以设计可赠送的凭证，让一人授权另一人注册。当前代码库并未确立这些选项，因此它们应被视为可能性，而非预期。
元数据构成第四项担忧。隐私保护凭证在数学上可以不可关联，但操作事件仍可能相互关联。签发时间、兑换时间、网络地址、设备指纹和错误日志，都可能缩小匿名空间。
Signal 的客户端旨在向服务器披露更少数据，但没有任何已部署网络可以完全没有元数据。相关标准并非完美隐形，而是系统是否只收集必要信息，并防止可避免的关联。
独立评估需要协议说明和清晰的威胁模型。Signal 应明确指出它假定哪些参与方能够相互协作。其中包括商店运营商、支付处理商、凭证签发方、注册服务和网络观察者。
研究人员还需评估是否由同一组织控制多个角色。即使在共享运营之下，密码学隔离仍可能具有价值；其保障取决于正确的构造、密钥处理、日志行为和部署边界。
一个社区讨论帖帮助发现了相关代码，但社区讨论并非正式产品公告。一些参与者自信地描述这一设计，另一些人则质疑其不可关联性与支付隐私。他们的讨论提出了合理问题，但并未解决这些问题。
Android 代码库提供了更有力的实现证据，但它仍代表开发中的软件。功能标志、接口、测试和注释可能在发布前变更，而服务器行为也可能不同于从客户端代码中推断出的假设。
Signal 值得因让大量客户端工作可供检查而获得肯定。这种透明度使开发者能够识别收据凭证、支付边界和无手机号账户状态，也使审查得以在营销话术定义叙事之前展开。
负责任的结论应是有条件的。该机制看似旨在防止支付与账户之间建立直接关联，同时执行一次性授权。已部署的服务是否实现了这一目标，尚未获得独立验证。
Signal 推出无手机号账户前应关注什么
有三个信号将表明这是否会成为一项可信的隐私功能：公开可用性、已记录的威胁模型，以及广泛的注册访问渠道。
第一个信号是公开测试版或正式稳定版发布。目前，Android 代码仅允许内部构建版本进行无手机号注册。若将这一限制移至测试版，便意味着 Signal 认为该流程已可在其开发环境之外使用。
测试版还将揭示实际的引导注册流程。用户可以了解付款是否为必需步骤、能否跳过创建用户名，以及必须保存哪些恢复资料。应用商店的可用性和国家/地区限制也将变得可以衡量。
还应关注现有账户能否解绑手机号。仅支持新账户可解决未来用户的注册问题，却会让 Signal 现有用户群仍与历史电话号码标识符绑定。迁移流程将显著扩大该功能的影响范围。
Signal 必须解释解绑的具体含义。从界面中移除号码，并不等同于删除所有相关的服务器记录。用户需要明确的账户状态定义和数据保留政策。
第二个信号是发布技术设计文档。一份有用的文档应说明凭证签发、购买兑换、防重放机制、恢复流程及相关元数据；还应说明支付服务商和 Signal 服务能够观察到哪些信息。
正式的安全审查将增强这一方案的可信度。zkgroup 库此前已在 Signal 内部被使用，但无手机号注册形成了新的协议组合。审查人员应同时检视其数学基础和周边应用流程。
最重要的问题是可关联性。Signal 应明确：签发方能否识别已兑换的凭证、多次出示凭证能否被关联，以及哪些时间信息仍然可见。清晰说明限制，比笼统宣称匿名性更可信。
第三个信号是平台与支付覆盖范围。当前 Android 实现似乎采用 Google Play 计费。如果直接安装的 Android 版本、iOS 用户或不受支持地区没有注册途径，这项隐私功能就无法服务 Signal 的全部用户群。
替代凭证可降低这种依赖。礼品码、非营利组织发放渠道，或服务商中立的支付机制，或许能帮助没有受支持应用商店账户的用户。任何此类途径都必须保持一次性兑换机制，并能抵御批量滥用。
开发者也应关注服务器代码仓库和协议库。新的端点、凭证类型和文档，能够揭示哪些保障是通过密码学强制执行的。仅凭客户端界面无法解答所有数据保留问题。
对隐私敏感的组织应等待这些细节明确后，再调整注册指引。记者、研究人员、组织者和企业需要在降低手机号暴露风险的同时，了解恢复和账户丢失风险。
评估隐私工具的知识工作者，可以将这些设计假设记录在个人知识库中。这样一来，当 Signal 发布文档或改变推广方式时，便可形成一份持久的对比记录。
Signal 的无手机号注册解决了一个真实的矛盾：该服务希望实现低数据量注册，却又必须防止一次性账户淹没加密网络。付费且不可关联的凭证是一种连贯的答案，但能否奏效取决于实施细节。
下一步取决于 Signal。它应发布该功能，记录可被观察到的元数据，并解释恢复机制，而非用密码学术语掩盖不确定性。届时，读者应提出一个实际问题：各方能否证明自己所需的事项，同时又不会获得一条可持久追溯到个人的路径？
