Question

我正在使用以下加密代码，它的功能类似于魅力，但我必须验证它符合FIPS 197，否则Legal会杀了我。

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))

Answer 1

Mcrypt的RIJNDAEL_256算法是具有256位块大小的Rijndael算法的版本。 AES（这是FIPS 197定义的）仅具有128位块大小（以及三种不同的密钥大小）的版本。

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

您的代码还有其他问题：

如果使用相同的密钥加密多个块，则不应使用ECB。所以，永远不要。请使用安全操作模式，例如CBC或CTR。
正如CodeInChaos评论的那样，您通常希望确保自己也具有真实性，而不仅仅是机密性（根据您的协议，您甚至可能需要进行身份验证以进行保密）。因此，在您的消息中添加MAC，或者使用一种操作模式，该操作模式还提供身份验证以及机密性（如CCM或GCM） - 不确定mcrypt中包含哪些内容。
您在加密（好）和解密（坏）上生成随机初始化向量。这对于ECB无关紧要，因为它不使用初始化向量，但是对于任何其他模式，您将为这两个操作获得不同的初始化向量，这意味着解密将获得不同的结果。对于CBC，只有第一个块是垃圾，而CTR一切都是垃圾（而CCM / GCM只会报告“失败”）。

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

Answer 2

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

这不是FIPS 197 验证的。经过验证的实施意味着它已经过NIST / CST实验室的专门测试，并且经过认证符合FIPS pub 197.您可以使用this list列出所有经过FIPS 197验证的供应商和产品。

Answer 3

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

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

我不了解其余部分（明文填充，PRNG的强度等），但ECB在99％的Rijndael实施中是一个<非常非常糟糕的事情，因此不是推荐使用。

PHP的mcrypt扩展名是否符合FIPS 197标准？

3 个答案: