事情是这样的，Alice 和 Bob 是一对 CP。两人之间难免要说一些 Secret，又不想被别人偷听，怎么办呢？
本文讲述这对 CP 之间如何安全隐秘地聊天。如何跟无（wěi）聊（suǒ）份子们斗智斗勇的故事。
先介绍一下将要登场的各个角色：
- Alice：话唠，严重的倾诉欲，和 Bob 是 CP。
- Bob：沉默男，理工男，和 Alice 是 CP。
- Eve：Alice 的室友，热衷于偷听八卦。
- Mallory：猥琐男，专业搞破坏 20 年。
- Trent：长者，相当具有权威性，大家都相信他。
如何不被窃听：加密
刚开始时，Alice 和 Bob 没有安全意识。平时说话聊天没有什么防范措施，经常被 Eve 偷听。但碍于情面又不好直说，为此烦恼不已。
偷听过程如下图：
Bob 是个技术男，想到一个办法。既然有人偷听，那我为什么不加密呢？说干就干，他事先和 Alice 商定一个密钥（key），是个随机值，别人猜不出来。
从此这对 CP 之间聊天就用这个 Key 进行加密保护，如下图：
从图中可以看到，Alice 在说话前，先用 Key 对消息内容进行加密。发送消息时，不再直接传递“我刚买了个包包”这么直白的明文，而是 “*&2#%/Qw@##” 这种谁都看不懂的密文。
即使被 Eve 窃听，她也完全看不懂神马意思，只能表示 WTF。Bob 收到密文后，先用 Key 对其进行解密，得到原始的消息内容“我刚买了个包包”。
旁白：这种加密方案在密码学里称为对称密码，加密方和解密方使用的是相同的密钥。
知名的密码算法有 AES（2001）、Blowfish（1993）、DES（1977），再远一点，有二战时期的恩尼格码（转轮机原理，德国）、紫色密码（转轮机原理，日本），以及著名的凯撒密码（没错就是地中海北岸那个凯撒）、栅栏密码等。后续会写文章专门进行各个算法的性能比较、安全性比较。
友情提示： 密码学里的“密码”和现实生活中的“密码”不是一回事儿！后者一般指的是口令（password），比如登录淘宝、QQ、ATA输入的那个东西。
顺便说下，有些耿直的 Boy 会把自己的口令设置得炒鸡简单，比如 12345678 、HelloWorld 等。这是万万不能够的，小心被人猜出来。
言归正传，一切看起来是那么完美。Alice 和 Bob 以为可以高枕无忧了，却没想到道高一尺，Eve 高一丈。
如何交换密钥：非对称加密
自从 Alice 和 Bob 使用了“加密”这种秘密武器之后，Eve 什么都听不到了。为此她寝食难安，没有八卦的生活还有神马意义！？
还好，Eve 不是普通的 Eve，她并不只是一个八卦女，她是个懂科技的 Girl。
思考几天之后，Eve 意识到这对 CP 肯定是用了加密的。一不做二不休，Eve 找到了破解办法，请看下图：
Eve 观察到那对 CP 之间为了安全性，会经常更换 Key。为此，她寻找一个合适的时机，把 Key 窃取到手。
之后，Eve 又可以愉快的窃听了，终于可以睡个安稳觉。窃听过程如下：
有 Key 在手，Eve 截获消息之后，就可以像 Bob 一样把消息明文解密出来。
不过好景不长，相对于 Eve 来说，Bob 才是掌握核心科技的。他很快发现 Eve 的这一行为，想到另一个办法： 非对称加密。
具体过程如下：
- Bob 事先生成一对公钥和私钥，私钥 pri 由自己保管，把公钥 pub 发给 Alice。
- Alice 使用 pub 对消息内容进行加密，Bob 用 pri 进行解密。
- 需要注意的是， 只有私钥才可以解密，所以即使 Eve 窃取到了 pub（只有 pub 被传输而容易被窃取），她也无法解密。
另外，这种方式还有个显著优点。假使 Bob 还有很多别的女友（严重抨击这种行为），他可以把同一个公钥 pub 都发给她们，各个女友都用这个 pub 和 Bob 进行通信。
构成“多对一”的通信关系，却不用担心女友 A 窃听到女友 B 和 Bob 之间的聊天内容，因为 pub 无法解密。
而在对称密码中，Bob 必须为每个女友都分发一个不同的 Key，这很难保管。
旁白：这种加密方式在密码学里称为非对称密码，所谓“非对称”指的是加密方和解密方用的密钥不一样。
知名的非对称算法有：DSA（数字签名算法，只能用于签名，1991）、ECC（椭圆曲线加密，1985）、RSA（公钥加密算法，1977）等。
这些算法除了用于加密外，还可以用于数字签名，本文后面会讲到。
非对称算法有个致命弱点： 性能很低。实际应用中一般采用混合加密体制、哈希签名体制。
好了，现在信道安全问题已经解决啦，不用再担心 Secret 被 Eve 偷听。但是情场多艰，猥琐男 Mallory 现在隆重登场。
如何防止数据篡改：MAC
文章开头说了，Mallory 是个专业搞破坏 20 年的男人，这次也不例外。请看下图：
Mallory 并不是八卦小女生，他对偷听秘密没有任何兴趣。生而不羁，他决定搞一些恶作剧，篡改一下消息吧。
于是他把 “我刚买了个包包” 改成“我决定跟你分手”，但 Bob 却不知道已被篡改，还以为是 Alice 的原话。那么问题来了，求此刻 Bob 的心理阴影面积。
经过一番狗血的情感纠葛之后，Alice 表示还是爱他的，Bob 终于意识到有人在从中作梗。
这还得了，之前我们一直强调，Bob 是个掌握核心科技的 Boy，他很快就想到了应对措施。
请看下图（为了简单起见，本例仅展示防篡改的情况，没有对 Message 做加密）：
图中的 MAC 指的是消息认证码（Message Authentication Code），你现在不需知道它的原理，只需要记住 ：
- 传入两个参数 Message 和 Key，进行一系列计算后得到一个值叫 MAC。
- 只有 Message 和 Key 相同的情况下，才能得到相同的 MAC。
- 跟对称加密一样，这对 CP 之间会事先协商一个 Key。
- Alice 使用 Key 对 Message 计算出一个 MAC1，并把 Message + MAC1 发给 Bob。
- Bob 收到之后，用自己的 Key 对 Message 计算出一个 MAC2，再比较 MAC1 和 MAC2 是否一致。
- 根据 MAC 的性质，如果 Message 被篡改，那么计算得到的 MAC2 一定不等于 MAC1，验证失败，Bob 得出结论：有人篡改了消息。
- 由于仅 Alice 和 Bob 拥有 Key，所以别人无法篡改 Message 后伪造出一个有效的 MAC。
- 在检测篡改方面，还可以用 HASH（散列）算法，包括 MD5、SHA1/224/256/384/512 等。比如版本控制系统 GIT 就使用 SHA1 来检查文件是否有修改。
旁白：消息认证码有多种实现方式，其中最常见的是 HMAC（Hash MAC），即使用哈希算法来实现 MAC，还有一种是基于分组密码算法的 MAC，不常见。
聪明如你，肯定会想到如果 Key 被窃取该怎么办？这就涉及到数字签名了，后文会讲到。
如何校验身份：MAC
Mallory 还有个小伎俩，那就是冒充身份，恰好 MAC 也可以对付这个。且看下图：
Mallory 发一个消息给 Bob，说“亲爱的，我是 Alice 哦，Balabala...”。如果没有校验措施，Bob 可能就中招了。
同样的，Bob 可以用以下方式进行防范：
只有 Alice 和 Bob 拥有相同的 Key，所以 Bob 只有在校验 MAC 成功时才会相信对方是 Alice。
而 Mallory 没有这个 Key，伪造的 MAC 肯定会校验失败的，所以计谋不能得逞。
旁白：MAC 包含几种实现方式，基于 HASH 的 MAC 称为 HMAC，应用比较广泛。
有些同学应该接触过阿里云的 Access Key，其实就是 HMAC 的原理。
有些同学在两个系统之间 API 调用时，会使用同一个 Key 做 MD5 计算来实现 API 鉴权，这称为“加盐HASH”，可以简单理解为 HMAC 的简化版。
同样的，如果 Key 被窃取该怎么办？这可以用数字签名来解决。
更进一步：数字签名
MAC 虽好，但是遇到和对称密码同样的问题：密钥如何交换。
其中一个解决方式就是数字签名，这个“签名”你基本可以想象成现实生活中的手写签名，具有类似的作用。
原理上和非对称加密有点像，但有个很大的区别，发送方是用私钥进行签名，而接收方用公钥进行验签，这跟加密情况正好相反。
Bob 可以用数字签名来校验消息是否被篡改，请看下图：
原理上和图 6 差不多，但区别在于：由 Alice 事先生成一对公钥 pub 和私钥 pri，并把 pub 发送给 Bob，前者用 pri 加签，后者用 pub 验签。验签失败说明消息被篡改。
也可以用于身份校验，请看下图：
Mallory 没有 Alice 的 pri，所以无论如何他也没法冒充 Alice 的身份。
看到这里，大家可能都松了一口气，以为这小俩口终于没事儿了。但情场多变，万一哪天 Alice 变心了呢，她给 Bob 发了一条消息，说“分手吧”，如下图：
可是发完之后又有点后悔，但他们使用的不是钉钉，并没有消息撤回功能。
怎么办？所以说 Alice 还是有点 Too Naive，她妄想可以矢口否认，把 Shit 盆子扣到破坏小王子 Mallory 身上，声称“刚才那句话是 Mallory 说的” 等云云。
Mallory 虽然猥琐，但也是个讲“原则“的 Man，你扣盆子也要讲基本法啊！于是他跳出来说， “表冤枉我，我又没有 Alice 的私钥”。
这是什么意思呢？原来数字签名还具有“抗否认”的神奇功效，Alice 讲的话里带有她的签名，是不能否认的（是不是有点类似现实生活中的手写签名？）。任何不讲基本法的栽赃陷害都是无效的...
公钥的身份证：数字证书
如果你以为 Eve 和 Mallory 就此屈服于非对称加密和数字签名的威力，那你就真的是图样了。
所谓 “两汪战一虎，四汪沉航母。六汪戏上帝，八汪创世纪”，他们决定联合起来，找出公钥机制的破绽。
伟大友谊自然会有效果，他们果真找到了破解之法（绝对不是剧情发展需要...）。
没错，就是伪造公钥。我们先拿公钥加密来举例子，图 4 中讲到，Bob 需要事先生成公钥 pub 和私钥 pri ，然后把 pub 分发给 Alice。
那么攻击过程就从这入手：
- Eve 生成自己的一对公钥 pub' 和 私钥 pri'，截获 Bob 的 pub，并用自己的 pub' 冒充 Bob 的公钥发给 Alice，如上图。
- Alice 用 pub' 加密消息，发送出去。
- Eve 截获 Alice 的数据，并用 pri' 解密得到消息明文。
- Eve 伪造一个假数据“干嘛呵呵去洗澡”，并用 pub 加密后发给 Bob。
- Bob 用 pri 解密，拿到伪造的数据，以为是 Alice 发给他的。
这是个“偷天换日”的过程，Eve 通过伪造公钥（中间人攻击），不光窃听到 Alice 的消息，还能保证整个过程中 Alice 和 Bob 都没有察觉！
再来看一下 Mallory 怎样用伪造公钥的方式来冒充身份。图10 中讲到，Alice 需要事先把自己公钥发给 Bob，所以攻击过程就从这入手：
- Mallory 生成自己的公钥 pub' 和 私钥 pri'，截获 Alice 的 pub，并用自己的 pub' 冒充 Alice 的公钥发给 Bob，如上图。
- Alice 用正常私钥 pri 进行签名，并发给 Bob。
- Bob 手里拿的是被伪造的公钥 pub'，所以对 Alice 的 sign 会验签失败，认为对方不是 Alice。
- Mallory 用自己私钥 pri' 进行签名，并发给 Bob。
- Bob 用被伪造的公钥 pub' 进行验签，可以验签成功，认为对方是 Alice。
这个过程中，Mallory 通过伪造 Alice 公钥，成功冒充了 Alice 的身份。
这种伪造公钥的攻击方式让 Bob 很头疼，思考了很久，终于想到一个办法。这次他找来了帮手—Trent。
文章开头有介绍过，Trent 非常具有权威性，而且能保证自身不受攻击（或者别人不敢攻击），就像现实生活中的公安局。
Eve 不是喜欢伪造公钥吗，Bob 这次就要请 Trent 为自己的公钥注册一张 “身份证”—数字证书。
见证如见人，哦不对，见证如见公钥！以下是注册数字证书的过程：
- Bob 请求 Trent 为自己的公钥 pub 注册一个证书。
- Trent 收到请求后，用自己的私钥 pri' 对 pub（以及身份信息） 进行签名，得到一个 sign。
- Trent 把证书 certificate = pub + sign 颁发给 Bob。
- Bob 把自己的证书 pub + sign 发给 Alice。
- Alice 使用 Trent 的公钥 pub' 对 sign 进行验签，如果校验成功则说明 pub 的确是 Bob 的公钥，因为她相信 Trent 的权威性。
Eve 不可能找 Trent 为她办一个 Bob 的数字证书，因为 Trent 不会同意的，就像警察蜀黍不会给我办一张别人的身份证一样。所以，Eve 无法伪造 Bob 的公钥。
同理，为了防止 Mallory 伪造公钥来冒充身份，Alice 也需要向 Trent 注册自己的公钥，得到一个数字证书，用于防止别人伪造公钥。
旁白：考虑到非对称算法的效率问题，实际应用中一般是先对数据进行哈希，然后才用私钥对哈希值（摘要）进行签名。
Trent 在密码技术领域中一般称为认证机构（Certification Authority，即 CA）。
以数字证书为基础，业界制定了一系列的规范和规格，比如由谁颁发证书、如何进行颁发、如何作废证书等，称为公钥基础设施（Public-Key Infrastructure，即 PKI）。
