我一直在考虑将HMAC添加到PHP mcrypt加密中。
这是使用加密密钥使用hash_hmac对加密数据进行哈希处理并将其附加到加密数据中吗？然后在解密时你拆分HMAC，再次使用密钥hash_hmac其余数据并检查它是否与HMAC匹配。
我很困惑，因为在这个问题 When authenticating ciphertexts, what should be HMACed? 中它说：
这是这样吗？如果这是真的，为什么不在加密数据上使用hash_hmac呢？你必须在HMAC输入中包含影响解密过程的所有内容，即不仅包括加密结果本身，还包括用于加密的IV，如果整个协议支持算法敏捷性，你应该还输入了加密算法的规范（否则，攻击者可以改变你的消息的标题，用“AES-128”标签替换标有“AES-256”的标签，你会在不知不觉中用错误的算法解密）。
答案 0 :(得分：2)
简答：是
长答案：
HMAC是基于哈希的消息身份验证代码。您应该HMAC任何您想要进行身份验证的内容，或者换句话说，任何您希望防止被修改的内容。
尽管the RFC standard更复杂，但将HMAC视为盐渍哈希可能是有意义的。
e.g。 hmac（message，key）= hash（message + key）
攻击者（没有HMAC密钥）无法在不使现有HMAC无效的情况下修改部分HMAC消息。它确实取决于您的数据格式和您对该数据的使用，以确定HMAC消息和HMAC密钥中应包含的内容。但假设您正在使用HMAC来验证解密，那么您应始终在HMAC消息中包含解密所依赖的任何内容。对称密钥通常用作HMAC密钥。
在你的引文中，海报上说IV和算法也应该进行哈希处理。考虑由
组成的文件/数据库格式ALGORITHM + IV + CIPHERTEXT + HMAC
如果您只对密文进行HMAC，则攻击者可以修改算法或IV（破坏文件）而不影响HMAC的有效性。这很糟糕，因为您可以使用有效的HMAC结束损坏的加密文件。解密将正常进行，因为您的软件会认为一切正常。结果是一个完全乱码的解密，但关键是你的软件坏了，因为它在解密时返回了错误的输出并且没有给出任何错误。如果您的应用程序尝试对该错误数据执行某些操作，则可将其归类为'安全风险'，因为它假定它是正确的。从某种意义上来说，不是一种安全风险，它会使底层加密变得更弱或更容易破解。 HMAC和对称加密是两种截然不同的技术。使用HMAC的关键是你可以假设解密层正在返回100％正确的数据。
在上面的例子中，ALGORITHM是一个动态的数据，我用它来解释OPs引用中的“算法敏捷性”。它定义了使用的加密算法。关键是它是动态所以它需要从某个地方读取而不是硬编码。这个事实使得解密的依赖，因此应该包含在HMAC消息中。但是，如果您始终使用某些静态算法，那么应该通过（硬编码）您的解密代码来假定它，并且无论如何都不需要存储此数据。不需要在HMAC消息中包含静态数据，因为它对解密没有影响。
使用静态算法的文件格式示例为the open source AES-256 Crypt File Format。算法是一致的，所以总是假设。由于速度原因，它实际上使用2个HMAC。 1用于验证IV和密钥，第2用于验证加密数据部分。