“在基本OPRF中,客户端看见 $V$,却无法知道服务器是否真的计算了预期的 $kU$。可验证版本先固定一个经过可信途径获得的公钥 $K=kG$,再检查两对点 $(G,K)$ 与 $(U,V)…”
形式陈述
普通伪随机函数由一方同时拿到密钥和输入后求值。不经意伪随机函数把这两份信息分给不同参与者:服务器持有钥匙
本页使用RFC9497的P256-SHA256、OPRF模式0,并将代数正确性、输入隐藏和计算安全分开陈述。[1] 群为素数阶
输入、编码和域分离
固定
context = ASCII("OPRFV1-") || 00 || ASCII("-P256-SHA256")
DST = ASCII("HashToGroup-") || context
模式 00 是一个零字节,不是ASCII字符 0。令
传输点统一用33字节压缩编码:首字节为 02/03,其余32字节为大端横坐标。接收端检查长度、前缀、True 当成标量1。
私钥
两条消息完成求值
客户端保留
其中 Finalize为八个ASCII字节。诚实执行满足
故结果与同时知道
直觉
可以把
“请求被隐藏”和“拿不到更多函数值”是不同问题。前者由一个均匀双射证明;后者面对会任意提交群元素的恶意客户端,必须限制服务器查询次数并采用相应困难假设。一个代数正确、请求也均匀的错误构造,仍可能让一次查询提供所有输入的求值能力。
例子与边界
复现一条公开P256记录
RFC Appendix A.3.1.1取输入单字节 00,公开教学私钥与盲因子为
k = 159749d750713afe245d2d39ccfaae8381c53ce92d098a9375ee70739c7ac0bf
r = 3338fa65ec36e0290022b48eb562889d89dbfa691d1cde91517fa222ed7ad364
私钥与盲因子都按规范32字节表示。请求、响应和输出分别是
U = 03723a1e5c09b8b9c18d1dcbca29e8007e95f14f4732d9346d490ffc195110368d
V = 030de02ffec47a1fd53efcdd1c6faf5bdc270912b8749e783c7ca75bb412958832
F = a0b34de5fa4c5b6da07e72af73cc507cceeb48981b97b7285fc375345fe495dd
参考程序还从公开种子 a3 重复32次及ASCII信息 test key 导出这把钥匙,再逐层核对结果。这些值用于离线复算;使用公开种子无法生成秘密密钥,Python参考运算也不提供常时保证。
换一个新鲜非零
一个看似简化、实际破坏查询限制的替换
假设把
此后对任何新输入
协议也不是数字签名。客户端最终持有的是32字节函数值,普通旁观者没有一项仅凭公开钥匙就验证
哪些观察会改变隐藏结论
同一个
服务器可以拒绝响应,也可以在基本OPRF中换一把钥匙。输入隐藏不保证可用性,更不保证响应属于既定公钥。对低熵输入,拥有服务器钥匙的一方能够枚举候选并计算其输出;消息盲性不会把公开输出变成信息论秘密。
推论与应用
服务器视图的精确模拟
固定任何合法
是从
完整本地视图还包括服务器的钥匙、辅助信息、随机币和它生成的响应。固定这些输入的同一条件分布,模拟器先独立抽一个均匀非单位点
这个模拟器不接收也不模拟客户端后来对外公布的输出;若应用增加该消息,需要重新证明。它也不证明客户端只学到一次授权结果。
伪随机性需要什么附加假设
理想目标把每个新输入分配一个一致的随机输出,重复输入返回同一个值。恶意客户端可任意形成请求,安全论证还要把它获得的新输入求值数量与服务器实际参与次数联系起来。基础CDH只给一个计算挑战,没有这类查询预算。
One-More Gap DH的一种原论文形式给攻击者
JKK14的具体2HashDH-NIZK协议在随机预言机模型中把这类假设接到理想功能。RFC9497的编码、上下文和组合证明与原协议有差别,§7.2.1明确提示其多钥匙/批处理分析边界。本页执行单钥匙基本求值,给出了去盲和输入视图的证明;完整恶意客户端伪随机性使用相应论文/RFC模型,不能由上述双射推出,也不把固定SHA-256当成无条件随机函数。
代价与终点任务
一次诚实在线求值需要客户端盲化、服务器求值、客户端去盲三次标量乘法,另有哈希到曲线、一次标量求逆和一次Finalize。线上各发一个33字节点,客户端存输入和盲因子。参考程序以二进制倍加做一次标量乘法,至多
终点任务:用同一
参考资料
- Alex Davidson等,RFC9497: Oblivious Pseudorandom Functions Using Prime-Order Groups,2023-12,IRTF Informational;§§2.1、3.1–3.3.1、4.3、5.1、7.1–7.4、Appendix A.3.1:协议、P256编码、输入与安全边界。它不是IETF Standards Track标准。
- RFC Editor,RFC9497 Erratum8392,2026-01-27 Verified:RandomScalar排除零;完整勘误表中8393为Held,8720是向量字段名的编辑修正。
- Stanislaw Jarecki、Aggelos Kiayias、Hugo Krawczyk,Round-Optimal Password-Protected Secret Sharing and T-PAKE in the Password-Only Model,ASIACRYPT2014扩展版,§3.1、Figure3与Theorem1,PDF pp.9–10:双哈希协议、One-More Gap DH接口与原协议安全定理;原论文的sid、公钥输入与理想功能不能直接删掉后照搬其结论。