但是，实现SRP实际上需要进行模块化算术，并且类似于实现Diffie-Hellman。也就是说，您必须具有恒定时间的求幂算法，快速的bignum库，并且要从任何一种微妙的错误中获得一个，否则您可能会遭受可怕的旁通道攻击。诸如AES或Curve25519之类的算法，没有太多包含SRP原语的加密库，因此无论如何都不可避免地要“自己滚动”。像SRP这样的数学仅是根据更多标准的原语实现的，例如“任何安全的密码哈希”，“任何安全的Diffie-Hellman类交换”，“任何安全的签名方案”？显然它是安全的-乍一看SRP显然不是安全的，除非您实际遵循离散日志问题的简化-并且只要您具有原语的安全实现，就更容易安全地实现。 />
例如，我可以想到一个弱PAKE，您只需在其中进行Diffie-Hellman密钥交换，但是双方都将MAC附加到从密码派生的临时公共密钥上。如果密码很强，那么这显然是安全的，但是与SRP不同，攻击者可以获得足够的信息来进行离线暴力攻击，并且服务器必须以明文形式存储密码。
我正在寻找是否具有类似于SRP的PAKE，其强度与上述弱方案一样容易直观地理解和实现其他原语。
#1 楼
出现在加密社区中的第一个用于密码验证密钥交换的协议是Bellovin-Merritt方案（另请参阅本调查第4页）。该协议非常简单，可能实际上满足您的需要：恰好是Diffie-Hellman密钥交换，其中的流使用分组密码（使用公共密码作为密码的密钥）加密，其中玩家同意的密钥是通过对Diffie-Hellman元组进行哈希处理而得出的。在各种模型（理想密码模型或随机预言模型，基于不可区分性的框架或基于模拟的框架...）中对该协议的安全性进行了多次分析。尽管它不能在普通模型中获得安全性证明，但您可能会对在随机oracle模型中证明是安全的协议感到满意。在这种情况下，此方案似乎完全符合您的要求：您需要“交换了任何Diffie-Hellman密钥”，以及“任何（好的）哈希函数”和“任何分组密码”，以便您使用密码对流进行加密。在本文中，将介绍Bellovin-Merritt方案的变体，它可能使其变得更加简单（它们本质上是用一个简单的一次性填充代替分组密码，并且有两种变体，一种是非并行安全的，一种是同时安全的）。 br />
编辑：因此，在与Ricky Demer讨论之后，这还不太可行。这项工作的必要条件是，DHKE生成的消息（作为组元素）应该与随机位字符串没有区别。对于某些大型素数$ p超过$ \ mathbb {Z} ^ * _ p $的DHKE，$组元素可以自然地映射到在统计上与位字符串无法区分的分布，并且现有的实现可能已经将这些消息编码为随机位字符串（但这必须进行检查）。对于较稀疏的组（例如椭圆曲线），我相信可以进行这种映射，但是从实现的角度来看这将更加麻烦。我感谢Ricky Demer指出了这一点。
本文中介绍的变体不使用分组密码，当编码的元素看起来不是随机的时，它会使用字典中的某种形式来引发字典攻击。一次性乘法垫：Alice通过将其流量$ g ^ x $与$ M ^ {\ mathsf {pw}} $相乘来掩盖自己的流量，其中$ M $是组元素，而$ \ mathsf {pw} $是密码（和鲍勃的扮演相似）。在这里，您不必关心组元素的表示方式。但是，您必须执行幂运算（具有小指数）和乘法运算，因此它不会使DHKE密钥交换成为黑盒。
编辑： >因此，我今天与我的博士学位顾问讨论了这个问题，他恰好是PAKE领域的许多论文的作者（特别是我提到的这篇论文）。它证实了我的想法：用黑匣子访问DH密钥交换和对称基元来构建PAKE似乎并不可行。以某种方式，您必须至少能够将两个组元素相乘（因此必须知道它们的结构）。我当然不能证明这是行不通的，但这在科学界目前尚不为人所知，而且也不可行。
评论
$ \ begingroup $
仅交换任何Diffie-Hellman密钥是不够的-人们还需要对组元素进行简单的采样，或者非常接近的采样。
$ \ endgroup $
–user991
17 Mar 5 '17 at 13:54
$ \ begingroup $
好吧，这取决于您是否将该协议看作是仅提供公用密钥的完整黑盒，还是一些会生成Alice消息给Alice的消息，Bob消息给Bob的消息的预先存在的代码，并且然后提供相应的密钥。在这里，您可以简单地获取为DH密钥交换生成的消息，并对其进行加密以获取PAKE消息。
$ \ endgroup $
– Geoffroy Couteau
17 Mar 5 '17 at 14:26
$ \ begingroup $
不一定奏效-假设所有组元素均以安全性参数零开头。
$ \ endgroup $
–user991
17 Mar 5 '17 at 14:30
$ \ begingroup $
我不确定我是否在关注您，如果您有几分钟的话，我们可以在聊天中讨论吗？
$ \ endgroup $
– Geoffroy Couteau
17 Mar 5 '17 at 14:37
$ \ begingroup $
我有时间，但是不知道如何在此处创建聊天室。
$ \ endgroup $
–user991
17 Mar 5 '17 at 14:49
#2 楼
基于Geoffroy Couteau的答案，可以解决此处所解决的问题。Bellovin-Merrit（来自第3节，使用指数密钥交换的EKE）方案大致如下：
-爱丽丝和鲍勃同意一个安全的素数模数和该组的生成器（存在泄漏其Legendre符号的问题）
-爱丽丝和鲍勃首先进行普通的DH密钥交换；这是通过使用密码作为密钥的对称加密方案进行加密的。
-之后，将进行挑战-响应以对付已交换密钥加密的重播攻击。
问题是：如果您使用另一种KE协议，对那些元素进行编码可能具有一定的结构，我们不能认为它们与随机值没有区别。而且，如果使用低熵密钥加密非随机值，则可能会变成离线或字典攻击。
使用通用密钥交换协议和对称性的ECB操作模式加密，我认为这是不可能的：如果您除了向原始邮件提供攻击者所有$ 0 $的加密（这可能是组元素表示的一部分）之外，攻击者可以尝试检查密码。
如果使用基于密码的KDF，这会增加暴力破解密码的工作量，但不能完全解决问题。
使用其他操作方式也不用解决问题：使用已知的IV和低熵密码，也可以将其用于攻击。
解决此问题的唯一方法是确保在第一个$ k $组元素的二进制表示形式的位至少具有$ kx $的熵位（甚至是硬核位），然后对chai使用某种操作模式宁。
另一个想法是使用SPEKE，它是在其他协议之后不久开发的：
关于带有安全素数$ 2的公共参数的协议p + 1 $
密码经过哈希处理，与组元素匹配，然后平方。这是具有主要订单$ p $的子组的生成器。
Alice和Bob只是与此生成器进行密钥交换，只有他们应该知道。
关于方案，上行空间攻击者无法测试密码的猜测，因为密钥交换发生在二次残差子组中，并且该组具有素数。注意，可以将协议与椭圆曲线一起使用，但是确实需要一种将密码与组元素匹配的方法。 Wiki文章为此指出了IOP或IEEE P1363.2中的Integer-to-Point功能。
但是，在2014年，论文《重新审视SPEKE协议》（Hao，Shahandashti）展示了对SPEKE的攻击，本文还讨论了对协议的必要更改。
一种可能性是，一旦解决了这些攻击的问题，实际上就会得到与SRP非常相似的东西。
评论
$ \ begingroup $
看到，所有这些解决方案都需要“手动”进行大量数学运算。我的问题的重点是，是否存在不需要我这样做的协议。我不需要担心Diffie-Hellman甚至使用数字：它只是一个具有两个功能的黑匣子：“生成密钥对”和“从我的私钥及其公钥派生共享机密”。
$ \ endgroup $
– ithisa
17 Mar 6 '17 at 19:05
$ \ begingroup $
SPEKE本身就是一个哈希函数，对一个元素和一个密钥交换进行平方。尽可能多地开箱即用。但是，如果您采用“ gen keypair”算法，则与基于密码的密钥交换完全不同。只需使用经过身份验证的Diffie-Hellmann。
$ \ endgroup $
– tylo
17 Mar 7 '17 at 10:23
$ \ begingroup $
正如我说的那样，使用从密码派生的MAC进行身份验证的经过身份验证的Diffie-Hellman的安全性不如SRP，因为被动攻击者会获得足够的信息，以在密码薄弱时对其进行暴力破解。 SRP 1.不需要服务器存储等效的密码2.不允许被动攻击者获取有关离线暴力的信息。经过身份验证的DH不能满足这些要求。
$ \ endgroup $
– ithisa
17年7月7日14:30在
$ \ begingroup $
@ user54609然后，我不明白您之前的评论是什么意思。术语“生成密钥对”根本不适合基于密码的密钥交换。我并不是说使用密码派生的密钥对DHKE进行身份验证-我是使用适当的PKI对DHKE进行身份验证-您将证书存储在本地，并可能用密码短语对其进行解锁。
$ \ endgroup $
– tylo
17 Mar 7 '17 at 15:37
$ \ begingroup $
@tylo：但是，该术语确实适合非交互式密钥协议，以及基于安装程序的$ \ hspace {1.4 in $$版本的版本，例如Diffie-Hellman。
$ \ endgroup $
–user991
17 Mar 8 '17 at 7:33
评论
嗯，索要清单是有点题外话，但是这个问题显然需要客观的原因（使用已建立的原语）。此外，我想知道我们是否会超过列表中的1个或什至0个项目，而这个问题很有趣。让我们打开它吧！看来SESPAKE和J-PAKE都不适合您：(
我能找到的最接近的是咸挑战响应身份验证机制（SCRAM），但它不是PAKE。它使用“标准” SHA-1 / SHA-256，PBKDF2和HMAC加密原语。