这个虽然是闲扯淡的，但是看的时候请抓牢：

• 我们一切以业务方案为目的，
• 一些关键名词和概念还是很认真。

加密签名

一个故事

这是从别人那边听来的故事，作为安全知识的入门非常有意义。

1. 一个国王英年早逝，留下年幼的王子，国王的弟弟就做了摄政王。
2. 王子快18岁的时候，他叔叔派他做信使，给另外一个国王送信，还让侍卫长跟着。
3. 王子晚上趁着侍卫长睡着了，偷偷打开信件，看见里面的内容是： 请您杀了这个信使。
4. 王子于是把信件修改了一下：请把您的女儿嫁给信使。
5. 王子然后做了那个国家的驸马。过几年后，岳父也死了，他就做了国王，带兵杀回去报仇。

叔叔的反思和改进

暂时不讨论善恶，我们站在叔叔的立场上，看他哪些事情没做好？

• 数据的隐秘：他的信件内容被别人看到了。
• 数据的篡改：他的邮件被人冒充了。

所以从技术层面上，我们可以给他一个有效建议，跟别的国王约定：

• 针对第一个情况：他写的信，每个字母向后偏移10个位置——数据被加密了
• 针对第二个情况：商量了一个算式，每个信件，把全部字母的数字加起来，通过这个算式算出来一个新的数字，写在信件最后，这样除了他俩，没谁能伪造信——数据被签名了

PKI里的加密和签名

在事实上，信息传输的物理通道是不安全的，【信使】作为信息的传递人，可以轻易的偷窥别人的信息，甚至“代表”别人发言。老外的思路是认可这个现状，然后从数理逻辑上来应对这个问题。

Public Key Infrastructure，公开密钥体系，就是针对这个情况的。 
这个体系的特点是，算法思路和实现都可以是公开的，只要保证Key的安全就可以。

这个章节里面，我们只要讲到加密和签名就可以了。

加密

加密根据密钥可以粗略的分俩类

对称加密

对称加密，就是加密和解密的过程里面，用的key都是一个——我们称为SecretKey。

• AES：一般记得这个就可以了，因为现在好像也就它是最好用的
• DES、3Des：我经常在代码里面能看见的。
• 其它

业务跟进：在前面我们给王叔的建议，很明显是一个比较土的对称加密方案。

非对称加密

非对称加密，加密和解密的密钥不同，用于加密的称为公钥（PublicKey），用于解密的称为私钥（PrivateKey）。

业务跟进：我们的建议，国王们各自有一套公钥+私钥，私钥自己保留好，公钥发布给大家。谁想给某人写信了，就用这个人的公钥加密，信件半路上被人截胡了，也无法解密内容。

• RSA：最出名的，在以前非对称加密就是区分为RSA和其它，
• ECC：当前最牛的规范，rsa也变成其它了
• 其它：

对称和非对称的优劣对比

• 对称加密在技术上有优势，同样的安全级别下，加密解密的速度快很多
• 对称加密同时也兼具签名功能
• 但是在多用户业务场景，有无法解决的问题：
• 俩个人玩，一套SecretKey就够了
• 三个人玩，3套
• 四个人玩，12套，
• …… N的组合数量。
• 结论：后面讨论各自适合场景。

签名和验签

业务跟进：我们的建议，国王们各自有一套自己的公钥+私钥，私钥自己保留好，公钥发布给大家。谁想发邮件，用私钥对内容进行“签名”，签名的结果写在信封上；收到邮件的人，用【发件人的公钥】+【内容】+【签名】进行验签，以确保这个邮件就是那个国王发的

JAVA伪码表示如下

• 签名：byte[] sign(byte[] content, PrivateKey prvKey)
• 验签：boolean verify(byte[] result, byte[] content, PublicKey pubKey)

小结

其实对称加密可以忽略，我们就记得非对称加密和签名比较重要

• 私钥放在自己手里，用来解密和签名，这俩个事情都明显是个人的私密行为，因此私钥
• 公钥发布出去，用来加密和验签，这俩个事情明显是个人对外的公开行为，因此公钥

我们的“完美”方案

到这里，我们就可以给王叔和其他的国王们一个比较完美的RSA方案

• 每个国王自己做一套公钥私钥
• 把自己的私钥保存好，把公钥送给其他的每个国王，
• 同时也保存好其他国王送过来的公钥，名称不能搞乱了，更不能让别人替换了
• 发邮件的过程如下：
• 把邮件的正文用自己的私钥签名，附在邮件最后
• 用接受者的公钥加密邮件的正文和签名
• 把信送过去
• 收邮件的过程如下：
• 用自己的私钥解密，获得邮件正文和签名
• 拿着发送者的公钥，对正文和签名进行验签

把自己的公钥送到别人那边，要包装一下，那个就是公证书 
自己的私钥也要好好的包装一下，这个就是私证书

证书和证书链

证书的烦恼

假设国王们已经建立了证书体系，这个时候，某个国王英年早逝，他的弟弟扶持？/挟持？年幼的侄子摄政。很不幸的是，暴毙的国王把象征权力的个人私证书和其他国王的公证书都付之一炬。

于是摄政王需要自己做一套公钥私钥，然后派信使去见每个国王，送去自己的公钥，拿回来对方的公钥。这是一个痛苦的折磨，对于所有涉及到的人：

• 对方国王怎么相信你？ 
  突然证书说换就换，我是不是要跑一趟去求证一下？
• 信使会不会有问题？ 
  信使是很乐意用自己的公证书来代表国王的公证书。他做俩个证书，左手的代表国王A把公证书给国王B，右手的代表国王B把公证书给国王A，用不着第三个代表证书，他就可以作为中间人来偷看+篡改来回的信件了。

就实际情况来说，最安全的方式是，其他的国王亲自过去，验证新王，交换证书。

但是很明显这个是一个成本很巨大的工作，而且很危险。说不定回家的半路上，哪个国王头疼脑热的，也英年早逝了，然后大家又要重新跑一趟，包括那个宝座还没坐热的摄政王。

注意：即使有了internet，这样的场景下证书交换是不能通过网络的，因为信任没能解决，只能亲自跑。

证书的本质就是信任

好在国王们都相信一个人——代表了神的意志的教皇。教皇说：你们也别这样跑，来回折腾。我给你们的公证书上面加上主的签名——当然也就是我代表主的签名，以后大家就只要如此如此：

• 保存一个公证书，那就是主的证书，只要相信他就可以了，这个是一切证书之根；
• 你们所有人的公证书，都要经过主的签名
• 你发给别人带有签名的信件的时候，也要把你的公证书带上——记得哦，是主给你签名的公证书
• 当别人收到你的信件、签名、公证书时候，
• 他首先要根据主留给他的公证书来验签你的公证书是不是经过主认证的，
• 再用你的证书来验证信件的签名

更完美的方案

用一个证书给别的证书做签名背书，产生了证书链，就解决了证书的 N*N 问题。

BTW：当某个国王派出军队出去征服新世界的时候，教皇一般也会派出一个大主教，授予他一个特殊的证书，这个证书是由教皇的证书签名，但是它还可以给别的证书签名。 
——这个就是多级授权。

其它

摘要MessageDigest不是加密

也不是所谓的“单向加密”，就是消息摘要

mac

message authentication code，一般不用。