在OpenSSL GCM解密的后期认证 [英] Late authentication in OpenSSL GCM decryption

问题描述

我使用OpenSSL的EVP接口来实现使用GCM模式的AES加密。

I am using OpenSSL's EVP interfaces to implement AES encryption using GCM mode.

现在，GCM作为身份验证模式之一，提供了密文完整性。这意味着它对密文（以及附加数据，如果提供）生成标记（MAC - 消息认证码）。此标记稍后可在解密之前检查，以确保密文未经修改。

Now GCM, being one of the authentication modes, provides cipher text integrity. Meaning it generates a tag (MAC - message authentication code) on the cipher text (and additional data, if provided). This tag can later be checked before decryption, to ensure that the cipher text has not been modified.

我已按照本博文实施加密：
http://incog-izick.blogspot.in/2011 /08/using-openssl-aes-gcm.html

I have implemented the encryption as per this blog post: http://incog-izick.blogspot.in/2011/08/using-openssl-aes-gcm.html

解密时，我使用以下API调用（按此顺序）：

While decrypting I am using the following API calls (in that order):

    // setting cipher, key and iv
    EVP_DecryptInit (ctx, EVP_aes_128_gcm(), key, iv);

    // setting tag
    EVP_CIPHER_CTX_ctrl (ctx, EVP_CTRL_GCM_SET_TAG, taglength, tagbuffer);

    // adding Additional Authenticated Data (AAD)
    EVP_DecryptUpdate (ctx, NULL, &length, aad, aadlength);

    // decrypting data
    EVP_DecryptUpdate (ctx, decrypteddata, &length, encrypteddata, encryptedlength);

    // authentication step
    EVP_DecryptFinal(ctx, outbuffer, &length);

问题是，如果我修改密文或AAD，密文仍然被解密并且在解密过程的最终调用中，即在对EVP_DecryptFinal的调用中检测到错误。返回一个零值，指示错误。

The problem is that, if I modify the cipher text or the AAD, the cipher text is still decrypted and the error is detected in the final call of the decryption process i.e. in the call to EVP_DecryptFinal . A zero value is returned indicating error.

在我看来，错误应该抛出在EVP_DecryptUpdate调用本身，解密应该失败。

In my opinion error should be thrown in EVP_DecryptUpdate call itself and decryption should fail. The late error detection defeats the purpose of Authenticated Encryption.

这里有什么问题？

推荐答案

如何知道MAC在到达密文结束之前会失败？流API需要在知道它已经到达结束之前产生输出。

How would it know that the MAC will fail before it reaches the end of the ciphertext? A streaming API needs to produce output before it knows it has reached the end.

为了避免这种情况，将整个消息解密成一个临时缓冲区，并且只有在使用生成的纯文本完成解密工作后。有一些API（例如NaCl的 unbox ），只有在验证后才会提供密文，但不支持流式使用。

To avoid this decrypt the whole message into an a temporary buffer, and only once you're finished decrypting work with the produced plaintext. There are APIs(such as NaCl's unbox) that only give you the ciphertext once it's verified, but those don't support streaming use.

或者，您可以创建一个新的加密方案，将MAC定期放入密文，这允许您解密和验证这些较小的块。平原AES-GCM是不够的。

Alternatively you could create a new encryption scheme that puts MACs at regular intervals into the ciphertext, which allows you to decrypt and verify those smaller blocks. Plain AES-GCM isn't enough for that.

这篇关于在OpenSSL GCM解密的后期认证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！