附加哈希然后加密整个批次不一定安全。实际上，取决于加密系统，它可能非常弱。例如，假设加密是使用诸如 RC4 之类的流密码完成的：加密是通过与密钥相关的伪随机流进行异或运算来完成的。因此，攻击者看到了这一点：

   E = ( m || h ( m )) XOR S ( K )

其中m是消息，h是哈希函数，S ( K ) 是从密钥K生成的伪随机流。如果攻击者猜测了m的值（从上下文中），那么他可以重新计算h ( m )，然后得到：

   S ( K ) = ( m || h ( m )) XOR E

然后，攻击者选择自己的消息m'，具有任意内容，并发送：

   E' = ( m' || h ( m' )) XOR S ( K )

瞧！诚信被打败了。

我刚刚熟悉了您链接的文章中概述的 Padding Oracle 攻击，我相信您已经回答了自己的问题。如果 Padding Oracle 攻击可以导致完全发现纯文本，则加密未加密的消息消息和哈希仍然需要填充，因此容易被发现。

要实现两者，您可能希望对原始消息进行哈希处理，将它们附加在一起，对其进行加密，然后对生成的密文进行哈希处理并将其附加到您的加密组合中。这将实现您想要的，但是当原始解决方案似乎完全可以接受时，它似乎需要做很多工作。

一方面，效率低下。接收者必须完成查找密钥、解密消息的所有工作，然后才能知道它是否值得解密。

同样，它增加了风险。如果 MAC 不计算，则接收者甚至永远不会检索解密消息所需的密钥，并且接收者将永远不会拥有您的有效负载。如果有效载荷是恶意的，这可能很关键。

考虑这种情况。假设您的应用程序是一个 Web 服务，它接受来自世界各地为您工作的艺术家的新图纸。您的所有艺术家都已获得其作品的签名密钥，并使用您的公钥对其进行加密以将其发送给您。假设您的服务器容易受到恶意 WMF 文件的攻击。

我是攻击者，所以我制作了一个恶意 WMF，为 MAC 创建一些随机字节，加密文件，然后将其上传到您的服务器。您的服务器解密 WMF 文件，并保存它以计算 MAC。但是您服务器的索引工具会读取中间 WMF，并执行包含在预览器中的恶意软件，因此无论如何您都会被黑客入侵。*请注意，即使您尚未验证 MAC，也会发生这种情况。

如果您先检查 MAC，您就不会解密有效负载，也不会暴露于 WMF 文件中的恶意软件。

*是的，被 WMF 文件破坏的索引器是 Windows 上的一个真正漏洞。假设一个系统完全没有任何漏洞是愚蠢的。