要回答您的问题：

{K_AB}**K_B_E被附加到消息中，以便接收者拥有解密消息的对称密钥。因为密钥K_B_E被使用，所以只有 Bob 可以解密对称密钥，因此只有他可以读取消息。

接下来是{h}由 key 加密/签名的哈希K_A_D。我假设这K_A_D是 Alice 的私钥，所以这是消息的签名。

对称密钥是由发送者为每条消息新创建的。发送者必须将用于解密目的的密钥发送给接收者。因此，密钥被预先添加（非对称加密）到每条消息。

是的，GPG 和 OpenPGP 使用这种方案。

作为扩展：

我可以在消息中添加多个（非对称）加密密钥，以便将消息发送给多个接收者。

如果我使用预共享密钥，那么我必须多次发送消息，或者必须与多人共享对称密钥。这将使该方案不安全。这就是我为每条消息创建一个新的对称密钥的原因。

另请注意，GPG/OpenPGP 不使用 CA，而是创建信任网络来验证所有其他参与者。

您的符号似乎与混合加密有关。消息用对称密钥K _AB加密；该密钥可能是由发件人随机生成的。为了让接收者知道它，有必要将它与消息一起发送，但不是明文，当然：K _AB是用接收者（鲍勃）的公钥加密的。

因此，Alice 做了以下事情：

1. 用一些强 PRNG生成K _{AB 。}
2. 以K _AB为密钥对消息进行对称加密；这就是{{h}**K_A_D, M}**K_AB意思（我用“ **”表示“加密”）。
3. 用 Bob 的公钥加密K _{AB ：}{K_AB}**K_B_E
4. 将两个加密的 blob 都发送给 Bob。

然后鲍勃这样做：

1. {K_AB}**K_B_E用他的私钥解密，从而恢复K _AB。
2. 使用K _AB，解密{{h}**K_A_D, M}**K_AB，产生消息M。

由于非对称加密算法（如 RSA）无法处理大量数据（人们通常说问题在于性能之一——像 AES 这样的对称加密比像 RSA 这样的非对称加密快得多——这一事实使得这个具有两次加密的过程变得必要）但这是一个半神话；真正的问题是 RSA 不能加密超过一百字节左右的消息）。

您的描述还显示了带有哈希值和某种带有密钥的加密的东西K_A_D。我想这是在尝试谈论MAC或数字签名。许多人试图将签名解释为某种“反向加密”。这是一个普遍但可怕的解释，只会传播混乱。

只有最后一行是实际发送的消息。

对称加密通常比非对称加密更快，并且可能更具未来性。为了安全，它需要更短的密钥长度。由于与 Bob 共享整个消息的意图是，Alice 不必使用 Bob 的公钥加密整个消息（长）。

相反，她使用自己生成的新对称密钥对整个消息进行加密。这使得消息的加密和解密速度很快，但她需要一种方法来与没有密钥的 Bob 共享密钥。

为了共享密钥，她使用 Bob 的公钥并用它加密消息对称密钥（短）。她将此作为附加数据添加到消息中。

当 Bob 收到消息时，使用他的私钥来解锁对称密钥是一件简单而快速的事情（只有他可以这样做，因为只有他拥有它的私钥）然后可以使用该对称密钥来解密整个信息。

添加消息的哈希值（然后由 Alice 的私钥签名，可以使用 Alice 的公钥进行测试），以便 Bob 可以知道 Alice 实际上是消息的发送者，并且在传输过程中没有被更改，尽管稍微快一点的变体是对对称密钥本身进行哈希处理并签名（或者简单地用 Alice 的私钥加密对称密钥以最小化消息大小）。

只要保持对称密钥的安全性直到 Bob 得到消息，它仍然向 Bob 证明 Alice 的消息没有被更改，因为没有其他人可以加密新消息，因为没有其他人知道密钥。它更快，因为它的哈希值要短得多（如果只是用私钥加密，甚至不需要哈希），但是它也没有提供那么多的身份验证。

它向 Bob 证明消息来自 Alice 并且没有被更改，但是在 Bob 拥有密钥之后，它不能用于向第三方证明 Bob 没有更改消息。如果必须能够证明消息是从 Alice 发给 Bob 之外的其他人的，那么 Alice 必须对整个（明文）消息进行签名。

我花了一些时间来理解讲师正在使用的奇怪语法，但基本上对称密钥是每条消息生成的“会话”密钥，而不是重复使用。因此需要在最终消息中包含它的加密副本。

我假设 H**K_A_D 是 Alice 用她的私钥加密消息摘要。