4

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

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

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

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

    // 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 的调用中。返回零值表示错误。

在我看来，应该在 EVP_DecryptUpdate 调用本身中引发错误并且解密应该失败。后期错误检测违背了认证加密的目的。

这里有什么问题？

4

1 回答 1

3

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

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

或者，您可以创建一个新的加密方案，将 MAC 定期放入密文中，这样您就可以解密和验证那些较小的块。普通的 AES-GCM 是不够的。

于 2012-10-19T10:54:43.247 回答