这是如何围绕仅实现 CBC、CFB、CTS、ECB 和 OFB 的系统实现 CTR 的？

信息安全 密码学 加密
2021-08-30 04:04:33

我的编程语言中的加密库不支持 CTR，尽管它支持 CBC、CFB、CTS、ECB 和 OFB。我假设理论上可以围绕这些其他模式之一安全地实现 CTR。

所以我想知道，这些引用是否从安全角度描述了 CTR 的正确实现？据我所读，我认为它们是，但我只是想确保我没有遗漏任何东西。

我进行了更多研究，发现 CTR 模式的块变换实际上只是用单调递增计数器的 AES ECB 变换对明文进行异或运算的结果。有了这种理解，我就能够在 .NET BCL 中内置的 AES ECB 模式之上轻松实现 AES CTR 模式。

和，

可以使用 AesManaged 类在 CTR 模式下实现 AES 加密，尽管它需要一些额外的工作。要使用 .NET AesManaged 类实现 CTR 模式，我做了以下操作：使用 CipherMode.ECB、PaddingMode.None。[在 CTR 模式下不需要填充，因为我们总是加密一个 16 字节的计数器。] 加密时，调用 CreateEncryptor()。使用生成的 ICryptoTransform，对于每个块，转换一个 16 字节的随机数（与 AES 块大小相同），然后将该转换的结果与明文进行异或以获得密文。在每个块之后增加随机数。继续，直到没有更多的块 - 不要忘记最后的块转换，对于 16 个或更少字节的最后一个块。

一方面，当引用说“增量”时，它应该是什么样的增量？确定不是线性的？

1个回答

您引用的文本是正确的：CTR 模式确实是关于加密计数器的连续值，并将生成的字节流与要加密的数据进行异或。

正如NIST所述，CTR 模式是一种“已批准”的操作模式。对于“增量”，它可以是任何你想要的通过 128 位值的方式（我假设一个具有 128 位块的分组密码，例如 AES），但是如果你寻求互操作性，那么“the”标准点击率模式如下：

  • 计数器是一个 128 位无符号整数，即介于0和2 128 -1之间的值。
  • 计数器使用大端约定（第一个字节最重要）编码为 16 个字节的序列。
  • 初始值 (IV) 是第一个计数器值的大端编码；换句话说，对于 AES/CTR，密文的前 16 个字节是明文的前 16 个字节与 IV 加密（作为 16 字节块）的 XOR 的结果。

由于大多数编程语言没有 128 位整数值，因此计数器递增通常是逐字节完成的（从字节 15 开始，递增它；如果结果为 0，则有进位，然后从字节 14 继续，依此类推开；否则，就停在那里）。

CTR 模式的安全性依赖于一个给定的密钥永远不会使用相同的计数器值两次。128 位块是一个很大的空间；随机且一致地选择 IV 足以确保这种不重用策略。将 CTR 模式与具有较小块（例如 3DES 及其 64 位块）的块密码一起使用可能很危险，因为2 64空间并没有那么大。

查看 CTR 模式的一种方法是将分组密码转换为长伪随机字节流的生成器。将此流与要加密的数据进行异或运算，使其成为流密码。

其它你可能感兴趣的问题
上一篇SSL 会话恢复和 ID 下一篇您喜欢使用什么 FOSS 软件来构建入侵检测堆栈？