ECB / CBC / OFB / CTR 模式的测试相当简单。查看该模式是否具有像 EAX / GCM 这样的经过身份验证的加密也很简单（尽管要查看哪种 AE 模式并不简单）。

• ECB：在明文中有一个包含许多相似块的文件。您在密文中看到相同的块吗？（是的，这类似于丹的回答，阿德南回答的最后一部分，但为了完整性而包括在内）。
• CBC：加密一个文件，然后在IV中翻转一点（一般在密文的第一个块中）；假设您翻转了第一个块的第五位。解密后，您是否在明文的第一个块中看到相同的翻转位？类似地，稍后在文件中翻转一个随机位，例如密文第 10 个块中的第 8 位。当您解密时，您是否看到第 10 个块是乱码，然后第 11 个块的第 8 位被翻转？再次参考CBC解密的操作模式图，原因应该很清楚。
• OFB/CTR：测试你是否有流密码。在不触及 IV / Random Nonce（通常是第一个块）的情况下，如果您稍后在密文中更改一点，您是否在解密的明文中看到相同的位翻转？如果是这样，您有一个流密码；与 CBC 的一个重要区别是在这种情况下没有乱码块。我同意 CodesInChaos 的评论，即 OFB/CTR 之间的安全差异很小。如果您将加密密钥¹称为 K，则可以区分 OFB / CTR。例如，设c[1]是c[2]密文的第一个和第二个块，而p[1]是p[2]明文的第一个块。计算D(K, c[1] XOR p[1]),D(K, c[2] XOR p[2])哪里D(K, c)是c用密钥解密的块K. 如果它们是连续的数字，则您有 CTR 模式。如果D(K, c[2] XOR p[2]) = c[1] XOR p[1]那么你有OFB模式。
• EAX/GCM - 两者都是经过身份验证的加密 - 它们包含消息身份验证代码 (MAC)，如果文件被更改，文件将不会解密（甚至是乱码），因为 MAC 极有可能无效。

当然，其中很多假设您知道块大小，但这应该很容易弄清楚。例如，加密一个非常小的（1 字节）消息。然后假设不涉及 MAC，您可能会创建一个两块消息（IV + 一个填充密文块 - 尽管 CTR/OFB 可能不填充）；然后加密更长的消息。通过反复试验，您应该能够找出块大小和 IV 大小。

编辑：我绝对同意 Thomas Pornin 提出的观点。这种逆向工程可以帮助发现分组密码，但并不能真正测试安全性。有许多后门可能被偷偷地放进去，如果没有痛苦的逆向工程，你就无法通过逐步检查程序集来检测它们。例如，您可能认为您有一个经过身份验证的加密块密码，该密码只能使用根据您的密码构建的密钥解密。但实际上文件是使用随机密钥加密的，该密钥本身在文件开头使用您的密码加密，然后使用他们的后门密钥加密一次。因此，他们将能够解密您使用的任何文件。或者该方案可能执行相同的方案，例如，在文件的开头存储要使用您的密钥解密的每个文件密钥，但只有大约十亿个左右的密钥（他们都知道）。或者可能只使用您的密钥对其进行加密，但密钥派生函数仅使用密码短语哈希的前 30 位作为您的密钥。因此，它可能会很快被十亿次尝试强制使用。同样，它不一定是故意的后门；它可能只是不恰当的微妙实现缺陷，允许侧信道 ataacks。同样，它不一定是故意的后门；它可能只是不恰当的微妙实现缺陷，允许侧信道 ataacks。同样，它不一定是故意的后门；它可能只是不恰当的微妙实现缺陷，允许侧信道 ataacks。

¹这不是针对其他部分的假设——您可以通过多种方式将密码输入解密系统，但不知道内部用于生成密钥的密钥派生函数（或加密函数）。

@dr jimbob 给出了关于检测分组密码模式的正确答案。我想用这个问题的另一种观点来补充这一点；即：如果仅从产品文档中无法知道使用哪种算法，哪种操作模式和哪种格式，则不应使用该产品。一般来说，安全是无法测试的；所以我们必须求助于下一个最好的事情，即努力确保产品的设计和实施都得到应有的注意，并遵循最佳实践和既定标准。这需要大量的文档和透明度。“最佳实践”的很大一部分是记录您所做的事情. 如果产品对您的数据使用加密但没有说明它是如何做到的，那么您已经知道它对于文档部分来说是不合标准的。因此，最安全的做法是假设该产品是草率的，而不是使用它。

另一个不相关的观点是，试图确定给定产品中的工作方式构成逆向工程，这可能是非法的，具体取决于您居住和/或工作的国家/地区。如果它是非法的，那么您应该避免这样做，并且相反，坚持正确的文件。如果它是合法的，那么一些反编译或反汇编通常会更准确地了解产品的功能，包括算法类型和加密模式。这种方法补充了@dr jimbob 建议的测试。

至少，只要您可以请求所选明文的加密版本，ECB 就很容易检测到。

只需比较 和 的加密0000000000000000000000...，1000000000000000000000...确保您的明文足够长以跨越几个块。

如果使用 ECB，则密文将仅在第一个块中有所不同- 后面的块将相同。这是因为 ECB 单独加密每个区块。如果使用了其他（传播）模式，则两个密文很可能在所有块中都不同。这是因为第一个块中的差异被合并到后续块中。

请注意，您无需了解加密密钥即可实现此目的。

由于您正在尝试查找链接模式，我假设您已经知道加密算法和加密密钥。

我能想到的最简单的解决方案是定义一个明文，然后将其提供给您的加密黑匣子并获取密文。然后编写一个脚本，该脚本将使用所有有限数量的可用链接模式独立解密密文，然后将结果与您的明文进行比较。无论哪个产生匹配，BINGO！

另一种方法是定义一个明文，使用所有可用的链接模式对其进行加密，然后将密文与相同明文的加密黑盒的输出进行比较。

欧洲央行的审计更有趣。将您的明文定义为具有相同的块（AES 为 16 字节块）并观察相同的 16 字节密文块的输出。此方法不需要密钥知识。