Aes 的两种不同实现是否有不同的密文？答案

【问题标题】：does two different implementation of Aes has different cipher text?Aes 的两种不同实现是否有不同的密文？
【发布时间】：2012-10-19 07:39:40
【问题描述】：

我正在使用库 1 Aes 算法实现，现在我想将其更改为库 2 的另一个实现，它工作正常，但问题是它给了我来自库 1 的差异加密数据，是否可以使用 ECB 模式实现 Aes 128 位，具有相同的密钥和纯文本，但仅在密文（加密数据）方面不同，用于 2 种不同的实现？

我发现另一件事是，如果我传递小于 16 字节的输入字节，那么两个库的加密数据就会匹配，但在 library1 中解密再次完美，但在 library2 中显示的加密和解密是相同的（不完全解密为原始文本）会有什么问题？

【问题讨论】：

他们在填充它吗？如果不是，并且它们使用相同的cipher mode 和相同的初始化向量，那么不，它们应该产生完全相同的输出。
这种差异的一个常见根本原因，至少从我们在 Stack Overflow 问题中看到的情况来看，是两种不同的情况使用不同的 文本编码。请记住，密码的输入是 bytes 而不是 text - 确保在比较它们时发送相同的 bytes。
我不知道他们是否正在填充它。如果他们正在填充呢？Blueraja 在这两种情况下我都使用 (unsigned char*) 作为密码的输入。
旁注：不要使用欧洲央行。使用经过身份验证的语义安全模式，例如 AES-GCM。

标签： algorithm cryptography aes

【解决方案1】：

鉴于您对小于 16 字节的字符串导致相同输出的评论，以及您对 ECB 的使用（您永远不应该使用），我怀疑您的一个库实际上并未使用 ECB，而是默认为CBC（这是一个更好的默认值）并且您将 NULL IV 传递给 CBC。如果我的理论是正确的，那么您应该期望前 16 个字节总是相同的，并且在那之后开始出现差异。

最好的解决方案是将所有代码从 ECB（除了一些非常罕见的情况外，在所有情况下都严重损坏）转换为 CBC 或您可以找到的任何其他模式。 CBC 是最常见的，您需要将随机生成的 IV 传递给它。

如果切换模式是不可能的，我会调查您的第二个库并确定如何将其设置为 ECB 模式，它目前可能不处于该模式。应该警告依赖您的加密的任何人，使用 ECB 模式会泄漏有关的重要信息明文。有时它几乎没有加密。请参阅entry at Wikipedia 以获得关于它到底有多糟糕的一个很好的视觉示例。这不是理论上的攻击。真的，真的坏了。

【讨论】：

这对我真的很有帮助，谢谢，因为我的积分少于 15，所以我无法投票，但谢谢

【解决方案2】：

是的，正如 cmets 所指出的那样，这是可能的。加密旨在显示输出的巨大变化，而输入的微小变化。理想情况下，输入中的一位更改将更改输出中 50% 的位。

避免大多数问题的方法是明确指定所有内容。不要依赖默认值，因为如果两个库之间的默认值不同，那么输出就会不同。

显式指定字符编码以将字符转换为字节。 UTF-8 很常见。
明确指定您使用的加密模式。 CBC 或 CTR 模式，如果您不希望包含身份验证，GCM（如果您愿意）。
明确指定 IV，最好使用字节，而不是字符。
明确指定要使用的填充。 PKCS7（又名PKCS5）很常见。

如果您仍然遇到问题，请检查两个库的所有内容是否逐字节相同。不要检查字符，而是检查字节。也就是说，在将它们转换为字节数组之后以及在将它们传递给加密方法之前立即检查。

附带说明，ECB 模式不安全且会泄露信息。它仅对测试密码方法的操作有用。正如我上面建议的那样，使用 CBC、CTR 或 GCM 模式。这些模式是安全的，GCM 包括身份验证。

【讨论】：

“加密货币旨在显示输出的大变化，而输入的小变化”这通常不是真的。使用语义安全的对称加密，即使没有任何更改，IV 也会产生完全不同的输出，并且在没有 IV 更改传播和安全性的情况下，很大程度上取决于模式。
我将 IV 中的变化视为“输入变化”。

【解决方案3】：

这里已经有很多正确答案了。唯一我想提的，以前没提过的。

可以使用 ECB 模式 128 位和相同密钥实现 Aes 和纯文本，但仅在密文（加密数据）方面有所不同 2 不同的实现方式？

在这种情况下，如果算法实现正确，相同的输入（纯文本、模式、IV、填充）应该产生相同的输出（密文）。

在这种情况下，如果您使用两个已建立的库，则很可能是前面提到的问题之一（其中一个输入的差异、编码等）。

【讨论】：