在 SRP 结束时，客户端和服务器相互隐式验证。“隐式”的意思是：“我不知道我是否与真正知道共享密钥的人交谈，但我知道只有当他知道共享密钥时，他才知道我刚刚从协议中获得的对称密钥”。如果您想确保这一点，请挑战对等方：让它使用对称密钥。

现在它并不像看起来那么容易。特别是，攻击者可以尝试让机器与自己对话。为确保安全，您应从 SRP 生成的对称密钥中派生多个对称密钥：一个用于从客户端到服务器的加密密钥，另一个用于从服务器到客户端的不同密钥。还有一对用于完整性检查的密钥。这很难做到正确，因此强烈建议使用一个协议，其中所有这些细节都经过多年的攻击和反击而痛苦地调整——即 TLS。我谈过RFC 5054吗？TLS 包含的Finished消息基本上就是我所说的挑战。当一台机器收到一个Finished来自对等体的消息，并且可以对其进行处理（正确的 MAC，解密时的正确值），然后对等体进行适当的显式身份验证。

“这些串联中有多少实际上增加了安全性？”

我认为安全性是指 K 的机密性。

K 通过不直接发送而受到保护。显然，如果您在不安全的通道上以明文形式发送 K，它将被截获，并且任何使用 K 的加密都会受到损害。

K 可以加密发送，但这需要另一个密钥，并且无法将我们带到任何地方。

因此该协议发送一个散列版本的 K。可以使用暴力破解或彩虹表攻击来击败散列。如果发送了 H(K)，对 H(K) 的成功攻击可能会向攻击者透露 K。由于散列可能存在冲突，对 H(K) 的成功攻击可能会产生 K 以外的值。将输入数据添加到散列会使成功攻击散列变得更加困难，因为要尝试的值域更大。哈希的输入越大，攻击成功的难度就越大。所以答案是每个连接都会增加安全性。

“例如，我想用连接替换 XOR 会同样安全。”

我不知道 XOR 的目的。SHA1 存在弱点，我怀疑 H(N) 和 H(g) 的 XOR 是为了减轻弱点。我认为由于 K 是 B、​​g、x、a、u 和 N 的函数的散列，因此 g 和 N 被散列和异或以防止某些模式连接输入数据的部分。从理论上讲，您希望将尽可能多的输入输入到散列函数中，与连接两个值相比，对两个值进行异或会减少输入数据的大小。由于 N 和 g 是众所周知的，因此 XOR 不会尝试在成功攻击散列的情况下保护这些值。

“在不降低安全性的情况下，我有多少自由来改变它？”

无法直观地判断订单或操作的更改何时会提高或降低安全性。安全的假设是任何更改都会降低安全性。请注意有关提高安全性的算法更改的公告频率与有关攻击破坏算法的公告频率。提高算法的安全性很难。阅读如何破解 MD5 和其他哈希函数，然后找出作者犯的任何错误。Wang 的 MD5 不充分条件至少是一篇批评第一篇论文发现的论文。

正如 Thomas Pornin 所指出的，您应该更喜欢 RFC（工程师规范）而不是论文（密码学家规范）。如果 RFC5054 不适合您，请使用 2945。

根据我对加密协议的了解，值 A、B、M 对于防止攻击者修改消息的顺序以及它们在与相同或其他主机的相同或并行连接中的重放至关重要。

原始论文中没有使用值 H(N) 和 H(g)，因为我认为它们是那里的常用参数，而实际上这些组参数是通过一些初始协议协商选择的。因此，如果参数突然改变，攻击是可能的。对于每个受支持的 (g,N)，现实生活中的服务器甚至可以为每个用户提供多个 SRP 验证器值，或者甚至为每个用户提供多个具有不同盐值的验证器值。我想 Tom Wu 将这些集成到哈希中以确保协议的安全性独立于这些奇怪的设置，这就是此类协议的设计方式。也许他甚至没有确定具体的攻击，而只是为了“良好的形式”。

也许，希望你只是忘了修正你对 U 的解释，但是：

您写道 U 在您的情况下是“私有的”，但加盐哈希和盐是公开的。最后一点，即验证者值是公开的，这很奇怪，并且不打算在 SRP 中使用。公共验证者值仅在服务器被攻破后才会发生。在这种情况下，SRP 与标准的基于哈希的质询-响应交换一样安全：验证者值容易受到离线暴力破解。

如果密码 (P?) 非常强，则无需担心，否则问题就大了。在任何一种情况下，您都不会比使用标准挑战响应更好。

U 不能是“私有的”，它在第一步中被明确传输。