由于密钥每秒都在变化，因此 OTPAUTH URI 也是如此。我想知道在这种情况下，一旦客户端进入 TOTP，服务器应该如何验证 TOTP？

服务器必须知道以前生成的密钥以提供可用性。要么通过动态生成以前的键（我可以想象一种算法，它会尝试t-0，如果失败t-1，如果t-2在预定义的范围内失败，则允许用户在移动到下一个后的某个时间输入一个值。

否则，整个生成-插入-发送-验证过程仅限于一个短窗口。一次接受多个有效密钥是可以接受的，因为范围仍然很短，值仍然难以预测，暴力破解仍然不可能（这可以通过在多次错误尝试后限制接受密钥的范围来进一步缓解）。

我如何使用此密钥生成器向服务器进行身份验证，知道该密钥生成器正在使用 srand(time(NULL)) 作为种子，同时连续 8 次调用 rand() 以生成 32 字节的随机序列。

没有对整个密钥生成算法和实际生成过程进行逆向工程是不可能知道的。您需要对函数调用进行逆向工程，rand()并为密钥生成过程构建模拟器。

如果您描述的是整个过程，那么您将需要弄清楚这些rand()值是如何连接在一起的（它们是连接在一起的吗？彼此异或？最终值是如何编码的？）

编辑：回答“漏洞”下提出的其他问题

服务器是否容易创建未来的 TOTP 并将它们保存在存储库中？

确实如此，但正如我在回答您的第一个问题时提到的，这不一定会发生。验证代码可以在每次需要执行验证时生成它认为合理/潜在的 TOTP 密钥。

此外，这需要攻击者破解该安全存储的访问权限，但是如果攻击者获得该安全存储的访问权限以窃取 TOTP 密钥，他也可能窃取用于生成这些密钥的主密钥并获得生成 TOTP 的能力钥匙如他所愿。因此，将密钥存储在存储主密钥的同一位置不会增加风险。

显然，服务器有能力生成密钥以验证它们，并且必须确保该机制值得信赖才能安全运行。这是大多数加密协议的共同要求，即某些点是可信的。毕竟，为了让服务器验证用户，假设服务器受到保护是合理的。

人们可以考虑使用某种非对称密钥协议而不是对称密钥。但是，由于该协议旨在通过服务器验证用户，因此只要服务器变得不受信任，它就会变得毫无意义。

如果攻击者侵入服务器以生成未来的密钥，一旦检测到这种情况，就需要更换主密钥（以及相应的所有未来 TOTP 密钥）。

服务器执行的验证过程是否可以隐藏在密钥生成器中，或者密钥生成器是它唯一期望的密钥生成器？！

密钥生成器和服务器执行相同的基本过程。曾经作为提供知识证明（密钥生成器）的一种方式，以及一种对其进行验证的方式（服务器）。

密钥生成器能够执行验证，服务器能够具体证明，但这不应该发生（尽管它可能会发生，并且可能会带来风险并使协议暴露于漏洞中）。

反汇编有一堆类似于我假设的 openssl 子例程的字符串。例如digest.c、pmeth_gn.c、pmeth_lib.c等。代码可以在网上找到。但是，我没有找到适合外行的清晰文档。我怀疑这里是否定义了服务器的验证参数。我还能够使用 findcrypt2 在反汇编中检测 SHA256 和 SHA512 加密常量。

我不太确定这里的问题是什么。我不认为任何 SSH 功能与密钥生成直接相关，但我可能是错的。

我被警告说密钥是使用 Linux 生成的。这可能会产生什么影响？我仍然在 Windows 轨道上！

Windows和Linux的实现srand和rand不同。具体来说，他们使用不同的常量或不同数量的迭代和迭代之间的组合。常见的 rand 函数的基本块是这样的：

int myrand(void) {
    next = next * 1103515245 + 12345;
    return((unsigned)(next/65536) % 32768);
}

其中 1103515245 和 12345 是两个常量值，在实现之间经常发生变化。

这是 glibc 的版本。你可以看到它更复杂。对具体实现进行逆向工程可能是最安全的方式。