我是否必须对每条消息进行签名，或者是否有更有效的方法来验证消息的来源？
我正在开发一个简单的加密协议以获得乐趣。当然我知道在任何一个严肃的项目中，我应该使用一些行业标准，比如OpenSSL，但这是用于学习和实验。
这个想法是通信终端交换RSA公钥，然后使用这些密钥安全地交换AES密钥，这样AES密钥就可以用来加密来自这一点的每条消息。我已经实现了所有这些，它工作正常。
问题是：潜在的攻击者无法通过AES读取任何内容，但仍可能导致错误或试图劫持通信或做一些其他令人讨厌的事情（例如她/他可以复制加密的信息并通过一次又一次地发送来破坏事物。我需要的是数字签名，所以我可以确认消息来自有效的来源，我很幸运，因为我已经有了一个有效的RSA实现。
我知道数字签名是如何工作的（获取消息的散列并使用私钥对其进行加密等），但我能想到的唯一方法是签署每条消息，然后检查签名在接收方是否有效。但是，我担心这会使我的协议慢。使用AES保护通信（或任何对称密钥加密）的全部目的是它比RSA（或任何公钥加密）快得多。不会这样做会破坏AES （或任何对称密钥加密）的目的吗？所以问题是：我是否必须签署每条消息？或者有更有效的方法吗？例如OpenSSL如何处理这个？
答案 0 :(得分：2)
TL; DR使用authenticated encryption。
在对称加密中，可以生成消息验证代码（MAC），使您可以检查您发送的邮件是否被（恶意）操纵。中间人攻击者只能为您尚未标记的邮件伪造身份验证标记带来微不足道的优势。
有很多方法可以做到这一点，但通常会看到MAC应该验证密文而不是明文（Should we MAC-then-encrypt or encrypt-then-MAC?）。流行的MAC算法是HMAC（例如HMAC-SHA256），CMAC / OMAC1或GMAC。还有一些不同的身份验证模式，如GCM，EAX，OCB，SIV，CWC等。这些模式结合了一种模式来实现机密性和一种真实模式，而不需要两者都有不同的密钥。
但这还不够，因为这只能使接收器检测到篡改或伪造消息。攻击者可能仍会发起其他攻击，例如重播或延迟攻击。因此，您需要发送随机数（如消息计数器）和时间戳。接收方必须保留先前发送的消息的记录（通过存储随机数），并且不接受通过其内部时钟判断发送得太晚的任何消息。
为了防止攻击者随意更改随机数和时间戳，还必须对其进行身份验证。大多数经过身份验证的模式实际上是带有关联数据的身份验证加密，可以验证其他非机密数据，如随机数和时间戳。
使用经过身份验证的加密可以使得纯对称通信相对防篡改，假设密钥是通过密码交换的，并且还通过传统的数字签名（如RSA-PSS或Ed25519（EdDSA）进行验证。