Scenario 1 (Like WWII 和 TEA)

双方共享一把密钥。
A 用密钥对信息加密。$E(K_AB,M_i)$，发送给 B
B 用 $D(K_AB,{M_i}K_AB)$ 解密读取信息。

问题是：
双方如何同步密钥？
怎么确定 B 收到的 ${M_i}K_AB$ 不是 replay of an old message?

Scenario 2 (Like Kerberos)

A 向第三方 S 索要一张和 B 通话的 ticket。
S 知道 A 的 password 所以他可以计算 $K_A$
S 发送给 A $\{\{Ticket\}K_B,K_{AB}\}, K_A$
A 知道自己的 password 所以可以计算 $K_A$，注意 A 的 password 不会在网络中传输。
A 可以计算出 $K_{AB}$ 和 $\{Ticket\}K_B$
A 向 B 发送一个读的请求，发送的信息是 $\{Ticket\}K_B$,Alice,Read
B 用 $K_B$ 来读取 Ticket 的内容，Ticket 的内容是 $K_{AB}$，Alice
A、B 可以用 session key 来交流了。

可以防止 replay，但 问题是:

难以 scale,S 必须知道 $K_A$, $K_B$,…
S 是唯一可能导致失败的因素。

Kerberos 这一名词来源于希腊神话“三个头的狗——地狱之门守护者”系统设计上采用客户端/服务器结构与DES加密技术，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证。可以用于防止窃听、防止 repla y攻击、保护数据完整性等场合，是一种应用对称密钥体制进行密钥管理的系统。

Needham-Schroeder protocol

这层协议是 Kerberos 的基础，在这之后，Alice and Bob share a secret (KAB)

Scenario 3 (Authentication)

数字签名，用私钥签名，公钥解密。注意公钥加密比私钥慢 100-1000倍。
很难找到 digest(M1) == digest(M2)

A 发送 Message＋用密钥加密的 Message 的 digest。{Digest(M)}$K_Apriv$
B 收到签名的文件，取出 Message，计算 Message 的 digest。
B 用 A 的公钥 $K_Apub$ 解密 {Digest(M)}$K_Apriv$ 然后和自己算的 digest 比较，如果匹配，签名验证。

问题：
如果 A 说他没有签名？说自己的私钥泄漏了？只要 A、B 互相信任，还是有用的。

Scenario 4 (Like SSL)

A 和 B 想要建立一个共享的密钥
A 拿到 B 的公钥，这个公钥被可信任的第三方 T 签名认证了，所以这个公钥确实是 B 的。
A 确认第三方 T 对 $K_Bpub$ 签名了。怎么确认？A 和 T 都有 B 的 public key，T 把 $K_Bpub$ 加密后给 A，A 对其进行解密然后比对自己手上的 B 的 public key 看是不是一致。
A 生成了 $K_{AB}$ 并用 $K_Bpub$ 加密。
B 有很多公钥所以 A 发送公钥的名字。
A 发送了 key name $\{K_{AB}\}K_Bpub$
B 用这个 key name 选择了对应的私钥并计算 $\{\{K_{AB}\}K_Bpub\}K_Bpriv == K_{AB}$

最后 A 和 B 共享了对称的钥匙 $K_{AB}$

问题：
在 A 第一次得到 B 的公钥时（A 认为这是 B 的公钥，然而这并不是，这是 C 也经过第三方 T 签名认证的公钥。

TLS 和这个相似

Message Authentication Codes(MACs)

对称加密生成的数字签名。
双方都有 Key(K)，sender 把 Key(K) 通过 MAC 算法加密后连同 message 一起给 receiver，receiver 比对收到的 MAC 和自己用 MAC 算法对自己这里的 Key(K) 加密后的 MAC 是否一致，如果一致，那么信息真实性和完整性就得到了证实。

用于数字签名，双方都算了一遍 MAC

JAVA 里的 keystore 和 truststore

keystore: 存了公钥、私钥、证书
truststore：存了公钥，只能存 server 发过来的东西