![[论文学习]主动腐化服务器下的隐私信令：无需TEE的模拟安全方案](http://pic.xiahunao.cn/yaotu/[论文学习]主动腐化服务器下的隐私信令：无需TEE的模拟安全方案)
Private Signaling Secure Against Actively Corrupted Servers论文重点这篇论文解决了隐私信令领域一个长期存在的痛点现有方案要么依赖可信执行环境TEE要么只能抵御被动攻击的服务器。作者提出了首个不依赖TEE、在双服务器模型下可抵御主动腐化攻击的模拟安全隐私信令协议通过将信令检索转化为类似隐私集合求交PSI的问题配合定制零知识证明来保证与公共公告板的一致性在服务器间通信开销和摘要体积上都优于当前最好的半诚实方案。核心研究内容问题定义隐私信令要解决的问题是——服务器需要在一个公开公告板上识别某个接收者的消息但同时又不能知道接收者的元数据谁在接收、接收了什么。现有方案中如果不想用TEE可信执行环境就只能假设服务器是被动腐化的即老老实实执行协议但会偷看数据。一旦服务器主动作恶比如篡改消息、伪造证明现有方案就崩了。论文的目标就是去掉这个“被动”假设同时不引入TEE。创新方法论文的核心思路是把“接收者检索自己的信令”这个操作转化成一个类似PSI隐私集合求交的问题。接收者和服务器各自持有集合通过PSI找到交集从而定位属于自己的信号。但PSI本身还不够因为服务器可能篡改公告板内容或伪造中间数据。为此作者设计了一套定制零知识证明用来保证服务器在协议执行过程中确实按照公告板的真实内容进行操作没有偷换数据。整个协议基于两方非串通服务器模型任意一方可以在任意时刻被主动腐化协议仍然保持模拟安全。研究成果在公告板规模为 (2^{19})约52万条消息时协议产生的摘要digest大小仅为33.57KB远小于现有半诚实方案的摘要体积。检索私有信令的计算时间约为2分钟在16线程和局域网环境下完成。服务器之间的通信开销也显著低于当前最优的半诚实协议。实际落地应用的可能性这个协议最直接的应用场景是隐私保护区块链和匿名消息系统。在这些场景中公告板就是一个公开的链上存储而服务器节点可能来自不同利益方随时可能作恶。不依赖TEE意味着不需要专门的硬件支持可以部署在普通的云服务器上。33KB级别的摘要也使得链上存储开销可控2分钟的检索时间对于非实时性要求极高的场景比如匿名投票、隐私交易通知是可以接受的。不过2分钟这个数字对于即时通讯类的应用来说还是偏慢可能需要进一步优化或做参数裁剪。技术细节论文的技术路线可以拆成几个关键步骤来理解。第一步把信令检索变成PSI问题。传统做法是接收者逐个尝试解密公告板上的密文直到找到自己能解开的那个。这在大规模公告板下效率很低。论文的做法是让接收者和服务器各自持有“位置集合”服务器持有所有信令在公告板上的位置接收者持有自己公钥对应的可识别标记。通过PSI双方在不暴露各自集合内容的前提下找到交集从而定位接收者的信令位置。第二步用定制零知识证明保证一致性。PSI解决了隐私问题但没解决“服务器有没有说谎”的问题。服务器可能在PSI过程中使用错误的数据或者公告板上的内容已经被服务器篡改。论文的解决方案是让服务器为它在PSI中的每一步操作生成零知识证明证明这些操作确实与公告板的公开状态一致。这些证明是定制化的专门针对PSI的操作结构设计比通用ZK证明更高效。第三步模拟安全的形式化保证。论文的协议在UC通用可组合框架下实现了模拟安全。这意味着协议的安全性不依赖于任何关于服务器行为模式的假设即使在服务器被主动腐化、协议执行被完全操控的情况下一个模拟器仍然可以在不知道接收者真实身份的情况下生成与真实执行不可区分的视图。这是比半诚实模型强得多的安全保证。性能数据方面论文在 (2^{19}) 消息规模下报告了33.57KB的摘要和约2分钟的检索时间。摘要大小主要来自零知识证明和PSI相关的承诺数据。2分钟的计算时间中大部分消耗在ZK证明的生成和验证上这部分可以通过并行化和硬件加速进一步优化。研究设定论文的实现基于以下配置硬件16线程CPU局域网环境LAN连接两台服务器软件/协议栈协议本身是密码学层面的论文没有指定具体的编程语言或库但从“16线程”的描述来看实现使用了多线程并行化来处理ZK证明生成和PSI计算网络假设两台服务器之间通过低延迟局域网通信与公告板的交互假设公告板是公开可读写的比如区块链安全参数论文没有在摘要中给出具体的安全参数选择如 (\lambda 128) 或 256但这类协议的实现通常会选择128位安全级别公告板规模实验中使用 (2^{19} \approx 524,288) 条消息作为基准规模需要指出的是2分钟16线程局域网这个组合意味着在广域网WAN环境下性能会明显下降因为ZK证明的生成和验证过程中存在大量服务器间通信。论文没有报告WAN环境下的数据这可能是后续工作需要补上的。综合分析这篇论文的真正价值在于它打破了隐私信令领域的一个隐性妥协。过去几年隐私信令的方案基本分两条路一条是TEE路线用硬件安全来换取协议简洁性但TEE本身有侧信道攻击、供应链信任等一系列问题另一条是纯密码学路线但只能做到半诚实安全实际部署中服务器一旦作恶就完全失效。这篇论文证明了一条中间道路是可行的用两个非串通服务器PSI定制ZK可以在不依赖TEE的前提下达到主动安全。从技术角度看把信令检索转化为PSI这个思路并不新鲜但在隐私信令的语境下难点在于如何让PSI与公开公告板的语义绑定。公告板是公开的任何人都能读但服务器不能从中推断出接收者的身份。论文的零知识证明正是用来解决这个“公开但不可关联”的悖论。这个设计思路对于其他需要与公开数据结构交互的隐私协议也有借鉴意义。从工程角度看33KB的摘要和2分钟的检索时间在当前的密码学协议中属于可接受的水平但距离“实用”还有一段距离。特别是2分钟这个数字如果目标是让接收者定期轮询公告板获取新信令这个延迟就太大了。可能的优化方向包括针对特定应用场景做参数裁剪比如减少公告板分片、降低ZK证明的冗余度、使用GPU加速ZK证明生成、或者设计更轻量的证明系统。从安全模型的角度论文假设两台服务器非串通这比单服务器模型更容易在实际中实现比如两个不同云服务商、两个独立运营方但仍然是一个需要信任的假设。如果两台服务器被同一实体控制主动安全性就失效了。论文没有讨论服务器串通概率的量化分析这在实际部署中是一个需要评估的风险因素。实践应用如果考虑在实际系统中采用这个协议以下几点值得注意适用场景的选择要务实。这个协议最适合“接收者不需要实时获取信令”的场景。匿名投票的开票通知、隐私交易的结算确认、去中心化身份系统的凭证更新通知——这些场景对延迟不敏感但对隐私和抗主动攻击的要求很高正是这个协议的用武之地。即时通讯的消息推送就不太适合因为2分钟的检索延迟对于聊天场景来说是不可接受的。服务器部署策略很关键。两台服务器必须由不同信任域的主体运营。比如一台放在AWS、一台放在阿里云或者由两个独立组织分别运维。如果两台服务器在同一个安全边界内同一家公司、同一个机房主动安全假设就形同虚设。部署时还需要确保两台服务器之间的通信通道本身是加密和认证的防止网络层的中间人攻击绕过协议层的安全保证。公告板的选择影响协议效率。论文的协议假设公告板是公开可读的但没有假设公告板本身提供任何隐私保护。如果公告板是一个区块链那么链上存储的摘要大小33KB/轮和检索时的链上读取次数会直接影响gas成本。在以太坊这类gas敏感的环境中可能需要将多个轮次的信令批量打包以摊薄成本。参数裁剪是工程化的第一步。论文报告的 (2^{19}) 规模是一个通用基准实际应用中可以根据需求调整。如果只需要支持几千个接收者公告板规模可以缩小到 (2^{12}) 或 (2^{13})摘要大小和检索时间都会大幅下降。关键是找到“够用”的最小规模而不是无脑照搬论文的实验参数。关注后续的实现开源和优化。目前论文只报告了实验数据没有提及开源实现。如果后续有团队基于这个协议做工程化代码质量、API设计、以及针对特定硬件比如支持AES-NI和AVX的CPU的优化都会显著影响实际性能。建议在采用前先做小规模的概念验证测量在自己的网络和硬件环境下的实际表现而不是直接以论文数据作为部署依据。参考资料原始论文Haotian Chu, Xiao Wang, Yanxue Jia.Private Signaling Secure Against Actively Corrupted Servers. Cryptology ePrint Archive, Paper 2025/1056. https://eprint.iacr.org/2025/1056 [论文学习]主动腐化服务器下的隐私信令：无需TEE的模拟安全方案
Private Signaling Secure Against Actively Corrupted Servers论文重点这篇论文解决了隐私信令领域一个长期存在的痛点现有方案要么依赖可信执行环境TEE要么只能抵御被动攻击的服务器。作者提出了首个不依赖TEE、在双服务器模型下可抵御主动腐化攻击的模拟安全隐私信令协议通过将信令检索转化为类似隐私集合求交PSI的问题配合定制零知识证明来保证与公共公告板的一致性在服务器间通信开销和摘要体积上都优于当前最好的半诚实方案。核心研究内容问题定义隐私信令要解决的问题是——服务器需要在一个公开公告板上识别某个接收者的消息但同时又不能知道接收者的元数据谁在接收、接收了什么。现有方案中如果不想用TEE可信执行环境就只能假设服务器是被动腐化的即老老实实执行协议但会偷看数据。一旦服务器主动作恶比如篡改消息、伪造证明现有方案就崩了。论文的目标就是去掉这个“被动”假设同时不引入TEE。创新方法论文的核心思路是把“接收者检索自己的信令”这个操作转化成一个类似PSI隐私集合求交的问题。接收者和服务器各自持有集合通过PSI找到交集从而定位属于自己的信号。但PSI本身还不够因为服务器可能篡改公告板内容或伪造中间数据。为此作者设计了一套定制零知识证明用来保证服务器在协议执行过程中确实按照公告板的真实内容进行操作没有偷换数据。整个协议基于两方非串通服务器模型任意一方可以在任意时刻被主动腐化协议仍然保持模拟安全。研究成果在公告板规模为 (2^{19})约52万条消息时协议产生的摘要digest大小仅为33.57KB远小于现有半诚实方案的摘要体积。检索私有信令的计算时间约为2分钟在16线程和局域网环境下完成。服务器之间的通信开销也显著低于当前最优的半诚实协议。实际落地应用的可能性这个协议最直接的应用场景是隐私保护区块链和匿名消息系统。在这些场景中公告板就是一个公开的链上存储而服务器节点可能来自不同利益方随时可能作恶。不依赖TEE意味着不需要专门的硬件支持可以部署在普通的云服务器上。33KB级别的摘要也使得链上存储开销可控2分钟的检索时间对于非实时性要求极高的场景比如匿名投票、隐私交易通知是可以接受的。不过2分钟这个数字对于即时通讯类的应用来说还是偏慢可能需要进一步优化或做参数裁剪。技术细节论文的技术路线可以拆成几个关键步骤来理解。第一步把信令检索变成PSI问题。传统做法是接收者逐个尝试解密公告板上的密文直到找到自己能解开的那个。这在大规模公告板下效率很低。论文的做法是让接收者和服务器各自持有“位置集合”服务器持有所有信令在公告板上的位置接收者持有自己公钥对应的可识别标记。通过PSI双方在不暴露各自集合内容的前提下找到交集从而定位接收者的信令位置。第二步用定制零知识证明保证一致性。PSI解决了隐私问题但没解决“服务器有没有说谎”的问题。服务器可能在PSI过程中使用错误的数据或者公告板上的内容已经被服务器篡改。论文的解决方案是让服务器为它在PSI中的每一步操作生成零知识证明证明这些操作确实与公告板的公开状态一致。这些证明是定制化的专门针对PSI的操作结构设计比通用ZK证明更高效。第三步模拟安全的形式化保证。论文的协议在UC通用可组合框架下实现了模拟安全。这意味着协议的安全性不依赖于任何关于服务器行为模式的假设即使在服务器被主动腐化、协议执行被完全操控的情况下一个模拟器仍然可以在不知道接收者真实身份的情况下生成与真实执行不可区分的视图。这是比半诚实模型强得多的安全保证。性能数据方面论文在 (2^{19}) 消息规模下报告了33.57KB的摘要和约2分钟的检索时间。摘要大小主要来自零知识证明和PSI相关的承诺数据。2分钟的计算时间中大部分消耗在ZK证明的生成和验证上这部分可以通过并行化和硬件加速进一步优化。研究设定论文的实现基于以下配置硬件16线程CPU局域网环境LAN连接两台服务器软件/协议栈协议本身是密码学层面的论文没有指定具体的编程语言或库但从“16线程”的描述来看实现使用了多线程并行化来处理ZK证明生成和PSI计算网络假设两台服务器之间通过低延迟局域网通信与公告板的交互假设公告板是公开可读写的比如区块链安全参数论文没有在摘要中给出具体的安全参数选择如 (\lambda 128) 或 256但这类协议的实现通常会选择128位安全级别公告板规模实验中使用 (2^{19} \approx 524,288) 条消息作为基准规模需要指出的是2分钟16线程局域网这个组合意味着在广域网WAN环境下性能会明显下降因为ZK证明的生成和验证过程中存在大量服务器间通信。论文没有报告WAN环境下的数据这可能是后续工作需要补上的。综合分析这篇论文的真正价值在于它打破了隐私信令领域的一个隐性妥协。过去几年隐私信令的方案基本分两条路一条是TEE路线用硬件安全来换取协议简洁性但TEE本身有侧信道攻击、供应链信任等一系列问题另一条是纯密码学路线但只能做到半诚实安全实际部署中服务器一旦作恶就完全失效。这篇论文证明了一条中间道路是可行的用两个非串通服务器PSI定制ZK可以在不依赖TEE的前提下达到主动安全。从技术角度看把信令检索转化为PSI这个思路并不新鲜但在隐私信令的语境下难点在于如何让PSI与公开公告板的语义绑定。公告板是公开的任何人都能读但服务器不能从中推断出接收者的身份。论文的零知识证明正是用来解决这个“公开但不可关联”的悖论。这个设计思路对于其他需要与公开数据结构交互的隐私协议也有借鉴意义。从工程角度看33KB的摘要和2分钟的检索时间在当前的密码学协议中属于可接受的水平但距离“实用”还有一段距离。特别是2分钟这个数字如果目标是让接收者定期轮询公告板获取新信令这个延迟就太大了。可能的优化方向包括针对特定应用场景做参数裁剪比如减少公告板分片、降低ZK证明的冗余度、使用GPU加速ZK证明生成、或者设计更轻量的证明系统。从安全模型的角度论文假设两台服务器非串通这比单服务器模型更容易在实际中实现比如两个不同云服务商、两个独立运营方但仍然是一个需要信任的假设。如果两台服务器被同一实体控制主动安全性就失效了。论文没有讨论服务器串通概率的量化分析这在实际部署中是一个需要评估的风险因素。实践应用如果考虑在实际系统中采用这个协议以下几点值得注意适用场景的选择要务实。这个协议最适合“接收者不需要实时获取信令”的场景。匿名投票的开票通知、隐私交易的结算确认、去中心化身份系统的凭证更新通知——这些场景对延迟不敏感但对隐私和抗主动攻击的要求很高正是这个协议的用武之地。即时通讯的消息推送就不太适合因为2分钟的检索延迟对于聊天场景来说是不可接受的。服务器部署策略很关键。两台服务器必须由不同信任域的主体运营。比如一台放在AWS、一台放在阿里云或者由两个独立组织分别运维。如果两台服务器在同一个安全边界内同一家公司、同一个机房主动安全假设就形同虚设。部署时还需要确保两台服务器之间的通信通道本身是加密和认证的防止网络层的中间人攻击绕过协议层的安全保证。公告板的选择影响协议效率。论文的协议假设公告板是公开可读的但没有假设公告板本身提供任何隐私保护。如果公告板是一个区块链那么链上存储的摘要大小33KB/轮和检索时的链上读取次数会直接影响gas成本。在以太坊这类gas敏感的环境中可能需要将多个轮次的信令批量打包以摊薄成本。参数裁剪是工程化的第一步。论文报告的 (2^{19}) 规模是一个通用基准实际应用中可以根据需求调整。如果只需要支持几千个接收者公告板规模可以缩小到 (2^{12}) 或 (2^{13})摘要大小和检索时间都会大幅下降。关键是找到“够用”的最小规模而不是无脑照搬论文的实验参数。关注后续的实现开源和优化。目前论文只报告了实验数据没有提及开源实现。如果后续有团队基于这个协议做工程化代码质量、API设计、以及针对特定硬件比如支持AES-NI和AVX的CPU的优化都会显著影响实际性能。建议在采用前先做小规模的概念验证测量在自己的网络和硬件环境下的实际表现而不是直接以论文数据作为部署依据。参考资料原始论文Haotian Chu, Xiao Wang, Yanxue Jia.Private Signaling Secure Against Actively Corrupted Servers. Cryptology ePrint Archive, Paper 2025/1056. https://eprint.iacr.org/2025/1056