除非您使用经过身份验证的加密操作模式，例如GCM ，否则使用秘密对称密钥进行加密并不能证明真实性。经过身份验证的加密算法除了对消息进行加密外，还会生成一个消息验证码 (MAC)，如果共享密钥得到适当保护，这可以用来证明消息的真实性和完整性，但不能证明不可否认性（这是一个很大的“如果” - 稍后再说）。

使用共享密钥的常规对称密钥加密并不能证明消息的完整性或真实性，因为没有什么可以阻止攻击者生成随机消息，然后接收者将解密并接受该消息。尽管攻击者不知道解密后的消息会是什么样子，但在许多情况下，让接收者接受随机生成的消息可能对攻击者有利。

只有有权访问对称密钥的人才能生成消息的 MAC，因此使用经过验证的加密和适当保护的对称密钥就足以验证消息。MAC 不提供不可否认性，因为在对称加密中，接收者也具有相同的密钥，因此接收者无法证明是发送者而不是接收者签署了消息。

如前所述，使用共享密钥进行身份验证需要正确保护共享密钥。具体来说，如果接收方生成对称密钥，并用接收方的公钥进行非对称加密（这是使用 PKI 发送加密密钥的普通方式）将其发送给发送方，则该对称密钥不能用于证明发送方发送的消息的真实性。发件人，因为该过程中没有任何东西可以证明发件人的身份。任何有权访问接收者公钥（毕竟是公开的）的人都可以生成一个随机对称密钥，并用接收者的公钥对其进行加密。

只有当生成共享对称密钥的方案包括双向认证时，才能使用对称密钥对消息进行认证。包括两种身份验证以生成用于签名和加密消息的共享密钥的方案通常称为安全身份验证通道或 SAC。

加密不能防止恶意更改。如果您使用 RC4 或 AES-CTR 之类的流密码加密某些数据，那么攻击者可以决定翻转密文中他想要的任何位，并且在解密时，这会翻转明文中的相应位。这允许进行手术修改。使用 CBC 模式下的分组密码，事情就少了一些外科手术，但仍然包含足以让攻击者做很多漂亮的事情（使用 CBC 和具有 16 字节块的分组密码，如果攻击者翻转一位，那么这会扰乱相应的块并翻转下一个块中的相应位）。

因此，您需要检查完整性和加密。分组密码的一些加密模式，例如EAX，结合了加密和完整性检查。否则，一个独立的MAC就可以解决问题（但是正确地结合加密和 MAC并不是一项完全显而易见的任务，因此鼓励您使用已经完成所有硬规范工作的模式，即 EAX）。

有些人使用术语“签名”来表示 MAC；这是一种不恰当但广泛使用的用法。MAC，更何况仅仅是不受保护的加密，不提供不可否认性。不可否认性是关于拥有可用于对抗签名者的证据；可以想象，可以说服像法官这样的第三方。在发送者和接收者之间使用共享秘密的计算不能成为令人信服的证据，因为根据定义，发送者和接收者都知道它（并且争议在发送者和接收者之间）。不可否认性是一个具有法律后果的复杂概念，但至少，计算机部分必须使用真正的数字签名 对不可否认的数据进行计算（不仅是通过共享密钥）。

边注：出于同样的原因，SSL并没有提供不可抵赖性，即使在使用客户端证书。如果 SSL 服务器记录了来自客户端的所有 SSL 连接，并且客户端通过证书进行了身份验证，那么服务器可能有一个给定客户端确实来自的证据，但服务器无法向第三方证明什么在 SSL 隧道中发送的客户端。对于网上银行而言，这实际上是一个具有法律挑战性的问题。