27、密码认证密钥交换协议：标准模型与效率优化

PAKE协议：标准模型与效率优化分析

最新推荐文章于 2025-09-14 14:18:12 发布

火锅TCP

最新推荐文章于 2025-09-14 14:18:12 发布

阅读量86

点赞数

CC 4.0 BY-SA版权

分类专栏：非对称密码学探秘文章标签： PAKE协议 EKE2 PPK

本文链接：https://blog.youkuaiyun.com/r7s8t/article/details/151751118

非对称密码学探秘专栏收录该内容

30 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

密码认证密钥交换协议：标准模型与效率优化

1. 标准模型下的PAKE协议

在之前的研究中，EKE的两个版本（EKE2和PPK）仅在理想化的随机预言机模型（ROM）中被证明是安全的，其中确定性哈希函数被视为随机预言机。然而，随机预言机方法只是一种启发式方法，如果随机预言机被实例化，可能会导致不安全的协议。因此，一个自然的问题是，PAKE是否可以在标准计算模型中被证明是安全的，即不假设像随机预言机这样理想化且不可实例化的黑盒。

1.1 KOY协议

第一个这样的解决方案由Goldreich和Lindell提出，但他们的标准模型PAKE并不实用，并且仅在有限的意义上被证明是安全的。Katz等人在2001年构建了第一个在DDH假设下，在BPR模型中安全的实用PAKE，假设存在公共参考串（CRS）。

KOY协议的思想受到Cramer和Shoup引入的平滑投影哈希函数（SPHF）概念的启发。如果每个参与方P发送其密码pw P的承诺cP，那么如果参与方A可以（1）向参与方B证明其承诺cA是对B的密码pw B的承诺，并且（2）这个证明可以与密钥交换（KE）相关联，使得A和B仅在两个被证明的陈述都正确时建立共享密钥，那么就可以实现PAKE。

然而，不清楚如何使用零知识证明来完成任务（1）而不导致离线攻击，因为A需要在ZK中向B证明的陈述x是“cA是对pw B的承诺”，因此密码不是ZK证明隐藏的证据，而是ZK证明可以揭示的陈述的一部分。通过用Cramer和Shoup的SPHF替换ZK证明可以解决这个问题。

为了防止中间人攻击，还需要解决一些细节问题。首先，承诺必须是不可变形的，例如，Katz等人通过CCA加密（具体是Cramer - Shoup加密）来实现这一点。其次，由于SPHF是可变形的，除非SPHF与cA、cB值更好地“绑定”，否则会发生中间人攻击。在KOY中，使用一次性签名（OTS）方案来实现这一点：
1. 发起方A选择一个OTS公钥，并将其用作其密文cA中的标签，因此即使攻击者使用另一个OTS密钥重新使用cA，cA仍然隐藏pw A。
2. B使用其投影密钥hpB作为密文cB中的标签，因此即使攻击者使用另一个投影密钥重新使用cB，cB仍然隐藏pw B。
3. 在最后一条消息中，A对其投影密钥hpA和B的加密中使用的标签进行签名。

KOY协议的通用形式如下：

CRS includes public key pk CRS of CCA PKE scheme Enc
Party A on input pw A
Party B on input pw B
(sk S, pk S) ←$ OTS.KG(1κ)
rA ←$ R, ℓA := (0|pk S)
cA ←Enc(pk CRS, pw A, ℓA; rA)
-
cA, pk S
xA =(pk CRS, cA, pw B, ℓA)
[xA =(pk CRS, cA, pw A, ℓA)]
(hpB, sk B) ←$ H(xA)
rB ←$ R, ℓB := (1|hpB)
xB =(pk CRS, cB, pw A, ℓB)
cB, hpB
cB ←Enc(pk CRS, pw B, ℓB; rB)
(hpA, sk A) ←$ H(xB)
[xB =(pk CRS, cB, pw B, ℓB)]
σ ←OTS.S(sk S, (ℓB, hpA))
-
hpA, kσj
abort if OTS.V(pk S, (ℓB, hpA), σ) = 0
sk ′
B ←PH(hpB, xA, rA)
sk ′
A ←PH(hpA, xB, rB)
output(∗) sk ←sk A ⊕sk ′
B
output(∗) sk ←sk ′
A ⊕sk B
(H, PH): SPHF for LCE = { (pk, c, m, ℓ) | ∃r c = Enc(pk, m, ℓ; r)}
OTS = (KG, S, V): one-time signature, all OTS-related items jboxed
R: randomness space of CCA PKE scheme Enc
(∗): in (Katz et al. 2001) sk = sk A · sk B because SPHF outputs sk A, sk B are
group elements

Katz等人在2001年用Cramer - Shoup加密实例化了图10.5中的通用协议，每个参与方需要11个固定基（fb）指数运算和1个可变基（vb）指数运算。假设1个vb ≈ 6个fb，总成本大约是EKE2或PPK的3倍，而EKE2和PPK仅在ROM中被证明是安全的。

1.2 其他标准模型下的PAKE

改进Goldreich - Lindell模型 ：Nguyen和Vadhan、Barak等人以及Goyal等人改进了Goldreich - Lindell的纯模型PAKE，但这些纯模型构造都不实用。
CRS模型的改进 ：Gennaro和Lindell对KOY协议进行了推广，允许使用其他SPHF友好的Cramer - Shoup加密实例化，例如在二次剩余假设或Paillier加密中使用的N - 剩余假设下。同一篇论文还指出，CCA安全的加密可以放宽为不可变形的承诺。Katz等人观察到，B的加密可以只是CPA安全的。Gennaro表明，可以用MAC替换A的一次性签名。Jiang和Gong展示了对KOY的更强简化，A的加密可以是CPA安全的并关联SPHF，而B可以使用不需要SPHF的CCA安全加密。Abdalla等人展示了一个BPR安全版本的KOY，其中B的加密是CPA安全的，A的加密是PCA安全的。

1.3 最小轮数的PAKE

Katz和Vaikuntanathan表明，KOY协议可以是非交互式的，即每个参与方可以独立选择一个SPHF哈希密钥及其投影，加密其密码，将加密和投影对发送给对方，然后每个参与方可以使用接收到的投影密钥对自己的陈述进行本地哈希，并使用自己的哈希密钥对对方的陈述进行哈希。这需要CCA PKE具有一种SPHF，其中投影密钥可以在不需要完整陈述的情况下计算（这种SPHF从那时起被称为KV - SPHF）。

他们在标准群中使用Naor - Yung CCA PKE和Sahai的模拟可靠非交互零知识证明（NIZK），以及在双线性映射群中使用决策线性（DLIN）假设和Groth - Sahai NIZK实现了这一点，每个参与方使用70个群元素。Libert和Yung将其减少到32个元素，Jutla和Roy通过放松模拟可靠NIZK，在双线性映射曲线上的对称外部Diffie - Hellman（SXDH）假设下，实现了每个参与方使用20个群元素的非交互式BPR模型PAKE。Benhamouda等人展示了一种用于Cramer - Shoup CCA PKE的高效KV - SPHF，在DDH假设下，使用标准群实现了每个参与方仅使用6个群元素的非交互式BPR模型PAKE。

1.4 标准模型下的UC PAKE

Canetti等人通过在KOY协议的最后一轮添加密码重新加密和模拟可靠NIZK，展示了第一个通用组合（UC）PAKE。Groce和Katz对Jiang和Gong的BPR模型PAKE方案进行了推广，并展示了其UC安全版本，形式化为UC PAKE - EA。

Katz和Vaikuntanathan将他们的非交互式BPR模型PAKE扩展到非交互式UC PAKE，通过在SPHF中构建陷门，使得模拟器即使在不正确的陈述上也能计算SPHF哈希值。Benhamouda等人将这种类型的SPHF形式化为陷门SPHF（TSPHF），并展示了一种在SXDH下更高效的TSPHF构造，实现了每个参与方使用11个群元素的非交互式UC PAKE。

1.5 自适应UC PAKE

Abdalla等人使用可提取和可等价（E2）承诺将Canetti等人的UC PAKE升级到自适应对手设置，但他们的构造使用了Ω(κ2)个群元素。Abdalla等人使用SPHF友好的E2承诺改进了这一点，使得得到的自适应UC PAKE（带擦除）是非交互式的，并且在SXDH曲线上使用Ω(κ)个元素。Jutla和Roy展示了Katz - Vaikuntanathan非交互式PAKE的一个版本，使用他们引入的双系统模拟可靠NIZK保持安全，在相同的SXDH设置下，使用仅四个群元素实现了自适应UC PAKE（带擦除）。关于无擦除的自适应安全，目前仅知道Canetti等人基于OT的PAKE，它使用Θ(κ)个UC OT实例。

下面是KOY协议的流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A([Party A]):::process -->|(sk S, pk S) ←$ OTS.KG(1κ)<br>rA ←$ R, ℓA := (0|pk S)<br>cA ←Enc(pk CRS, pw A, ℓA; rA)| B([Party B]):::process
    B -->|xA =(pk CRS, cA, pw B, ℓA)<br>(hpB, sk B) ←$ H(xA)<br>rB ←$ R, ℓB := (1|hpB)<br>cB ←Enc(pk CRS, pw B, ℓB; rB)| A
    A -->|(hpA, sk A) ←$ H(xB)<br>σ ←OTS.S(sk S, (ℓB, hpA))| B
    B -->|abort if OTS.V(pk S, (ℓB, hpA), σ) = 0<br>sk ′ B ←PH(hpB, xA, rA)<br>sk ←sk A ⊕sk ′ B| End([End]):::process
    A -->|sk ′ A ←PH(hpA, xB, rB)<br>sk ←sk ′ A ⊕sk B| End

2. PAKE效率优化

之前讨论的EKE的两个版本（Bellare等人的EKE2协议和Boyko等人的PPK协议）在CDH和/或DDH假设下，在理想化模型（IC和ROM）中被证明是安全的。然而，假设理想化模型的PAKE并不局限于Bellare等人和Boyko等人的结果。

2.1 EKE2和PPK的问题

EKE2版本的最大问题是它在一个群上使用了IC，而PPK版本使用了一个到群的哈希。此外，这两个版本的完整证明都花了一些时间才出现，并且/或者是由后续工作开发的。

2.2 其他协议的安全证明

AuthA协议 ：Bresson等人在IC + ROM模型中，在CDH假设下为Bellare和Rogaway的AuthA协议提供了BPR模型安全证明。AuthA协议类似于EKE2，但A先发送gx而不进行密码加密，并且有第三个协议轮次，其中A发送密钥确认消息。AuthA意味着四轮的相互PAKE - EA，与Boyko等人的EKE的三轮PAKE - EA版本PAK形成对比，PAK也节省了一方的密码加密，但来自响应方B。
Boyko等人协议的变体 ：Bresson等人在ROM中，在CDH假设下为Boyko等人的PAKE - EA的一个变体提供了BPR模型安全证明，该变体切断了最后一个A到B的密钥确认轮次，导致了一个具有服务器到客户端认证的两轮PAKE。

2.3 SPAKE2协议

Abdalla和Pointcheval展示了一个名为SPAKE2的最小轮次版本的EKE在ROM中在CDH假设下的BPR安全性。SPAKE2协议类似于PPK，但CRS中增加了两个随机群元素M和N，H(pw A)和H(pw B)分别被群元素M pwdA和N pw B替换。SPAKE2协议提供了第一个不需要IC或到群的RO哈希的BPR安全EKE版本，每个参与方需要在DH KE的1个fb + 1个vb指数运算的基础成本上增加2个固定基指数运算。

2.4 SPEKE协议

Jablon和Hao以及Shahandashti提出的SPEKE协议对EKE进行了改进，在使用DH KE实例化的EKE中，双方可以使用DH基g = H(pw)运行DH KE，其中H是到群的RO哈希。Haase和Labrique提出了SPEKE的一个特定椭圆曲线实例化CPace，并被IETF CFRG对称PAKE类别竞赛推荐采用。MacKenzie表明，SPEKE在倒置加法DDH假设下是BMP模型安全的。

SPEKE需要一个到群的哈希，而SPAKE2不需要，并且SPEKE每个参与方需要2个vb指数运算，而SPAKE2需要3个fb + 1个vb指数运算，因此SPEKE仅在空间受限的情况下更便宜，因为这些情况无法使用预计算来加速固定基指数运算。Pointcheval和Wang展示了一个SPEKE变体TBPEKE，通过设置H(pw) = ¯g · ¯hpw解决了这些问题，其中¯g和¯h是CRS中的两个（随机）群元素。

2.5 J - PAKE协议

J - PAKE是一个不是EKE变体但在实践中获得关注的PAKE协议，它包含在OpenSSL库中。Abdalla等人展示了J - PAKE在ROM中在DDH的一个变体假设下的BPR安全性，但J - PAKE似乎没有比SPAKE2或TBPEKE更有优势，因为它需要更多的轮次和大约6倍的带宽和计算量。

2.6 基于RSA的PAKE

基于RSA的KEM实例化EKE构建PAKE似乎是一个有吸引力的选择，因为它可以创建一个成本不平衡的PAKE。如果客户端发送cA ←E(pw, (re mod N))，服务器恢复KEM密钥为r ←[D(pw, cA)]d mod N，那么如果指数e可以很短，这样的PAKE可以支持弱客户端。然而，服务器方可能会作弊，如果(e, N)被调整使得re mod N不是模N的随机整数。确实，几个基于RSA的EKE版本随后被破解。安全版本在ROM中在RSA假设下的BPR模型中被给出，但即使是Park等人的版本也要求|e| = Ω(κ)，并且客户端必须测试e的素性。基于RSA的PAKE提案都有较高的客户端成本或需要比使用素数阶群的PAKE更多的轮次和带宽。创建支持弱客户端的PAKE仍然是一个未解决的难题，并且对基于RSA的解决方案的兴趣似乎已经减弱，可能是因为任何客户端侧的成本节省都会以固有的更高带宽为代价。

2.7 RO或IC模型下的UC PAKE

Abdalla等人表明，三轮EKE变体AuthA在IC + RO模型中，在CDH假设下，即使对抗自适应对手且无需擦除，也能实现Canetti等人的UC PAKE功能。Bradley等人展示了两个实现UC PAKE的两轮EKE变体。

以下是几种PAKE协议的比较：
| 协议 | 安全性假设 | 轮数 | 成本 | 特点 |
| ---- | ---- | ---- | ---- | ---- |
| EKE2 | CDH和/或DDH，IC + ROM | - | - | 使用IC |
| PPK | CDH和/或DDH，IC + ROM | - | - | 使用到群的哈希 |
| AuthA | CDH，IC + ROM | 4 | - | 类似EKE2，有密钥确认消息 |
| SPAKE2 | CDH，ROM | - | 每个参与方3fb + 1vb + 2fb | 不需要IC或到群的RO哈希 |
| SPEKE | 倒置加法DDH | - | 每个参与方2vb | 需要到群的哈希 |
| J - PAKE | DDH变体，ROM | 更多 | 约6倍带宽和计算量 | 非EKE变体 |
| 基于RSA的PAKE | RSA，ROM | - | 高客户端成本或更多轮次和带宽 | 成本不平衡，可能支持弱客户端 |

密码认证密钥交换协议：标准模型与效率优化

3. 不同PAKE协议的综合分析

3.1 安全性比较

不同的PAKE协议在安全性假设和适用模型上存在差异。在标准模型下，KOY协议及其相关改进协议如Gennaro和Lindell推广的版本、Jiang和Gong简化的版本等，通过不同的技术手段实现了在不依赖随机预言机等理想化模型下的安全性。而在理想化模型（IC和ROM）中，EKE2、PPK以及AuthA等协议在CDH和/或DDH假设下被证明安全。

对于自适应安全和通用组合安全（UC）方面，不同协议也有不同的表现。例如，Canetti等人的UC PAKE通过添加密码重新加密和模拟可靠NIZK实现，而Abdalla等人对其进行了自适应对手设置下的升级。Katz和Vaikuntanathan的非交互式PAKE扩展到非交互式UC PAKE，使用陷门SPHF等技术。

协议类型	安全性假设	适用模型	自适应安全	通用组合安全
KOY及改进	DDH等	标准模型	部分协议支持（如Jutla和Roy的版本）	部分协议支持（如Katz和Vaikuntanathan扩展的版本）
EKE2、PPK	CDH和/或DDH	IC + ROM	未提及明显优势	部分变体实现（如AuthA实现UC PAKE功能）
SPEKE	倒置加法DDH	-	未提及	未提及
J - PAKE	DDH变体	ROM	未提及	未提及
基于RSA的PAKE	RSA	ROM	未提及	未提及

3.2 效率比较

效率方面主要考虑轮数、计算成本和带宽需求。最小轮数的PAKE如Katz和Vaikuntanathan实现的非交互式PAKE，通过使用特定的SPHF和加密方案，减少了交互轮数，提高了效率。而在计算成本上，不同协议所需的指数运算次数不同，例如KOY协议每个参与方需要11个固定基和1个可变基指数运算，而SPAKE2每个参与方需要3个固定基和1个可变基指数运算加2个固定基指数运算。

在带宽需求上，J - PAKE需要大约6倍于SPAKE2或TBPEKE的带宽和计算量，这使得它在效率上相对较低。

协议	轮数	计算成本（指数运算）	带宽需求
非交互式PAKE（Katz和Vaikuntanathan）	非交互式	不同实例化有所不同（如70个群元素到20个群元素等）	-
KOY	-	每个参与方11fb + 1vb	-
SPAKE2	-	每个参与方3fb + 1vb + 2fb	-
SPEKE	-	每个参与方2vb	-
J - PAKE	更多	约6倍于SPAKE2或TBPEKE	约6倍于SPAKE2或TBPEKE

3.3 应用场景分析

不同的PAKE协议适用于不同的应用场景。对于资源受限的设备或网络环境，如物联网设备，需要选择计算成本和带宽需求较低的协议，如SPEKE在空间受限且无法进行预计算的情况下有一定优势，而SPAKE2在综合效率上表现较好。

对于需要高度安全性和通用性的场景，如金融交易等，标准模型下的UC PAKE协议可能更合适，例如Katz和Vaikuntanathan的非交互式UC PAKE可以在一定程度上满足需求。

而对于已经有成熟加密库支持的场景，如使用OpenSSL库的系统，J - PAKE可以作为一种选择，但需要考虑其效率问题。

4. 未来发展趋势

4.1 安全性提升

随着计算能力的不断提升和攻击技术的发展，PAKE协议需要不断提升安全性。未来可能会出现新的安全性假设和证明技术，进一步完善标准模型下的PAKE协议，减少对理想化模型的依赖。例如，可能会有更高效的模拟可靠NIZK技术出现，用于增强协议的安全性。

同时，对于自适应安全和通用组合安全的研究也将继续深入，开发出更高效、更安全的协议来应对日益复杂的攻击场景。

4.2 效率优化

在效率方面，未来的研究可能会集中在进一步减少协议的轮数、降低计算成本和带宽需求。例如，探索新的加密算法和哈希函数，以减少指数运算的次数。同时，利用硬件加速等技术，提高协议在实际应用中的执行效率。

对于非交互式PAKE协议，可能会有更多的优化和改进，使其在更多场景下得到应用。

4.3 多场景融合

随着不同应用场景的不断涌现，PAKE协议需要更好地适应多场景的需求。未来的协议可能会结合不同场景的特点，实现一种协议在多种场景下的高效应用。例如，既能够满足资源受限设备的需求，又能够在高安全性要求的场景中使用。

以下是PAKE协议未来发展趋势的流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A([PAKE协议]):::process --> B([安全性提升]):::process
    A --> C([效率优化]):::process
    A --> D([多场景融合]):::process
    B --> B1([新安全性假设和证明技术]):::process
    B --> B2([增强自适应和通用组合安全]):::process
    C --> C1([减少轮数]):::process
    C --> C2([降低计算成本]):::process
    C --> C3([减少带宽需求]):::process
    D --> D1([适应资源受限设备]):::process
    D --> D2([满足高安全性场景]):::process