3

我正在使用以下加密代码，它就像一个魅力，但我必须验证它是否符合 FIPS 197，否则法律会杀了我。 

mcrypt_encrypt(MCRYPT_RIJNDAEL_256, SALT, $plaintext, MCRYPT_MODE_ECB,
               mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB),
                                MCRYPT_RAND))

和

mcrypt_decrypt(MCRYPT_RIJNDAEL_256, SALT, $plaintext, MCRYPT_MODE_ECB,
               mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB),
                                MCRYPT_RAND))
4

3 回答 3

6

Mcrypt 的RIJNDAEL_256算法是 Rijndael 算法的版本，块大小为 256 位。AES（这是 FIPS 197 定义的）只有 128 位块大小（和三种不同的密钥大小）的版本。

所以不，你在这里没有使用 AES。请改用 RIJNDAEL_128，这与 AES 相同。

您的代码还有其他问题：

  • 如果您使用相同的密钥加密多个块，则永远不要使用 ECB。所以，从来没有。请改用安全的操作模式，例如 CBC 或 CTR。

  • 正如 CodeInChaos 评论的那样，您通常希望确保自己也具有真实性，而不仅仅是机密性（并且根据您的协议，您甚至可能需要对机密性进行身份验证）。因此，在您的消息中添加一个 MAC，或使用一种操作模式，该模式还提供身份验证和机密性（如 CCM 或 GCM） - 不确定哪些包含在 mcrypt 中。

  • 您生成一个关于加密（好）和解密（坏）的随机初始化向量。这对 ECB 无关紧要，因为它不使用初始化向量，但在任何其他模式下，您将获得两个动作的不同初始化向量，这意味着解密将得到不同的结果。对于 CBC，只有第一个块是垃圾，而对于 CTR，一切都是垃圾（并且 CCM/GCM 将简单地报告“失败”）。

    由于初始化向量不需要保密（只是不可预测或不可重复，具体取决于模式），因此可以自定义将其与消息一起发送（作为前缀）或派生它（on双方）来自一个共同的秘密（就像 SSL/TLS 中的第一个初始化向量，它是从主密钥派生的，就像加密密钥和 MAC 密钥一样）。

于 2011-11-08T17:45:44.177 回答
1

取决于您对“合规”的定义。它是否符合 FIPS 197 规定的所有规则 - 是的，我相信如此。

它未经 FIPS 197验证。经过验证的实施意味着它已经过 NIST / CST 实验室的专门测试并被证明符合 FIPS pub 197。您可以使用此列表获取所有经过 FIPS 197 验证的供应商和产品的列表。

于 2011-11-08T15:58:49.237 回答
1

FIPS 197 仅指定 Rijndael 算法，而不是实现。所以是的，它是合规的。

然而，实施在 NIST SP 800-38A 中指定。

我不知道其余的（明文填充、PRNG 的强度等），但在 Rijndael 的 99% 的实现中，ECB 是一件非常非常糟糕的事情，因此不推荐。

于 2011-11-08T16:09:35.307 回答