虽然这是无聊的废话，但请在观看时坚持住：

我们瞄准的是商业计划，一些关键术语和概念还是很严肃的。00-1010一个故事

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

一个国王英年早逝，留下了一个年轻的yjfdrjb，国王的弟弟变成了一个滑稽的精灵。yjfdrjb快18岁的时候，他宽容的馒头派他去当信使，给另一个国王送信，让勤奋的刺猬跟着他。Yjfdrjb在勤劳的小刺猬晚上睡着的时候偷偷打开信，看到里面写着：请杀了这个信使。Yjfdrjb随后修改了这封信：请把你的女儿嫁给信使。Yjfdrjb成了那个国家愚蠢的纸鹤。几年后，tdjr也死了，他成了国王，带领他的军队回去为自己报仇。00-1010暂时不讨论善恶。让我们站在一个包容性馒头的立场上，看看他有哪些地方做得不好。

数据的秘密：他信的内容被别人看到了。数据篡改：他的邮件被冒充了。所以从技术上来说，我们可以给他一个有效的建议，并与其他国王达成协议：

对于第一种情况：他写的信，每个字母向后移动10个位置，——的数据被加密；对于第二种情况，讨论了一个公式。对于每个字母，把所有字母的数字加起来，用这个公式计算出一个新的数字，写在字母的末尾，这样除了他们之外，就没有人能伪造字母——了，数据签的是

加密签名

。事实上，信息是被传递的。老外的想法是认清这个情况，然后从数理逻辑上处理这个问题。

公共基础设施，公钥系统，就是针对这种情况。该系统的特点是算法思想和实现都是开放的，只要密钥是安全的。

在本章中，我们只需要讨论加密和签名。

加密

加密可以根据密钥大致分为两类。

对称加密

对称加密，即在加解密的过程中，使用的所有密钥都是——，我们称之为SecretKey。

AES:一般记住这个就够了，因为现在看来是最好的DES，3Des:我经常在代码里看到。其他业务跟进：前面我们给君秀蜗牛的建议，显然是一个比较土的对称加密方案。

不对称加密

非对称加密，加密和解密的密钥是不同的，称为加密的公钥和解密的私钥。

业务跟进：我们的建议是国王有自己的一套公钥私钥，自己保管私钥，把公钥公布给大家。任何想给某人写信的人都是用那个人的公钥加密的，信件中途被截获，内容无法解密。

Rsa:最著名的一个，在过去，非对称加密被分为RSA和其他，ECC:目前最好的规范，而RSA也成为了其他：对称和非对称优缺点的比较。

对称加密在技术上有优势。在相同的安全级别下，加解密速度要快得多。对称加密同时还具有签名功能。但是在多用户业务场景下，存在一些无法解决的问题：一套SecretKey够三个人玩，三套四个人玩，12套，n组合数量。结论：我们将在后面讨论适当的场景。

包容的小馒头的反思和改进

业务跟进：我们的建议是，王者有自己的一套公私钥，保留自己的私钥，把公钥发布给大家。谁要发邮件，用私钥对内容“签名”，把签名结果写在信封上；收到邮件的人会用[发件人的公钥][内容][签名]进行检查和签名，以确保邮件是国王发送的。

Java伪代码表示如下

签名：byte []符号(byte []内容，私钥PRV密钥)验证：Boolean verify (byte []结果，byte []内容，公钥pubkey)

PKI里的加密和签名

其实对称加密可以忽略，所以我们记住非对称加密和签名更重要。

私钥放在你自己手里解密和签名。这两件事显然是个人的私人行为。因此，私钥的公钥被释放用于加密和签名验证。这两件事显然是个人的公共行为。因此，当公钥

签名和验签

来到这里时，我们可以给君秀蜗牛等国王一个完美的RSA方案。

每个国王都制作自己的一组公钥和私钥来保存自己的私钥，将公钥发送给其他每一个国王，同时也保存其他国王发送的公钥。名字不能混淆，更不能让别人代替发送电子邮件的过程如下：用自己的私钥在邮件正文上签名，附在邮件末尾，用收件人的公钥加密邮件正文。发送信件接收电子邮件的过程如下：用他的私钥解密，得到邮件正文和签名。拿着发件人的公钥，验证身体和签名，把你的公钥发给别人这边。你需要打包。那是公证书，你的私钥也要打包好。这是私人证书。

00-1010证书故障

假设国王已经建立了证书制度。这个时候，某个国王英年早逝，他的弟弟支持他？/人质？年轻和独家面包摄政王。不幸的是，国王的突然去世烧毁了象征权力的个人证书和其他国王的公证书。

所以搞笑的雪碧需要她自己。

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

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

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

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

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

证书的本质就是信任

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

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

更完美的方案

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

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

其它

摘要MessageDigest不是加密

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

MAC

message authentication code，一般不用。