一、PGP（Pretty Good Privacy）
PGP是一种邮件加密手段，他在发邮件一方加密，然后发给发送方邮件服务器，发送方邮件服务器再发送给接收方邮件服务器，然后接收方再从接收方邮件服务器pop出来，这整个过程都是pgp加密过的，接收方拿到之后才会解密。
所以整体走的发邮件流程还是先前提到的SMTP那套，只不过在源加了密，在接收方解了密。
1.PGP加密流程
这个流程包括了Authentication 和Confidentiality，看看他是怎么做的
首先邮件消息哈希之后用A的私钥签名，连接到原来的消息上，这一步做了认证。
然后刚才的消息加签名过压缩。
然后A自己生成一个session key，这个是对称加密，用来加密消息的，他用这个session key加密刚刚压缩完的东西，同时，他也需要把这个session key告诉B啊，他用B的公钥加密session key，然后把他连接到刚才用session key加密过的东西上，这一步提供了机密性。
然后这就是最终加过密的消息了。
所以说整个过程不管是认证还是加密，都是基于双方非对称密钥的安全的，因为如果非对称密钥被妥协了，那么整个流程就不安全了。
在考虑一个问题，压缩的目的是什么，为什么要在加签名之后，加密之前压缩？
首先压缩最根本的是为了减少传输的字节，其次，压缩同时消除了原文的统计特性，减少了被crypto analysis的风险。
在签名之后压缩，是基于签名的意义，那就是对数据完整性提供认证，而如果对压缩过后的信息签名，那虽然也能达到同样的效果，但是丢失了原本的含义。同时我认为这是某种设计理念，但是目前还不是很能理解。
在加密之前压缩，一方面是可以减少加密和解密的时间，另一方面就是刚才说的，如果压缩在加密，黑客拿到的是加密的压缩文件，是没法进行crypto analysis从而进行唯密文攻击的，而如果是先加密再压缩，黑客拿到了压缩的加密文件，那他只要解压缩之后，就可以进行crypto analysis从而进行唯密文攻击了。
还有一个比较扯淡的说法，是说，如果是先压缩再签名，那么接收方就需要存压缩文件来验证签名，尽管我看不出来这有什么问题。他还说，如果想不存压缩文件的话，那就需要解压缩之后再压缩，这更是扯淡，如果先压缩在签名，对称解密完就是签名和压缩文件，直接验证就好了，哪还需要重复压缩。
2.PGP解密
那就是刚才，拿到用公钥加密的session key和加密消息的连接，那就先拿自己的私钥把session key解出来。
然后就可以拿session key解密加密的压缩文件了。
然后再解压缩，拿到签名和原文，用A的公钥解签名，对原文做哈希，比对来验证签名，也就是数据完整性。
3.PGP提供的邮件适应性
因为之前说了，SMTP只传7-bit A服务器托管网SCII码，所以刚才那一套认证、加密走完之后的8-bit octets stream，也就是服务器托管网字节流，要想进SMTP，他需要转换成7-bit ASCII码。
它采用的是Radix-64 algorithm，他把原来的字节流的每6bit，映射成一个Radix-64的ASCII字符，包括26个大写字母（A-Z）、26个小写字母（a-z）、10个数字（0-9），以及两个额外的符号（通常是+和/），或者从字节角度理解，就是把每3字节（24bit）映射成4个Radix-64的ASCII字符。
他还增加CRC。
所以看下面整体的PGP发送的格式，从下往上看，数据部分，签名部分，这两部分是对称加密的，然后上面就是对称加密的session key。整体的消息会过一遍64-radix。
这里的两个公钥上面都有一个id，这涉及下面要说的PGP的公钥管理。
4.PGP公钥管理
从上面的PGP流程可以看出，非对称密钥安全是整个加密安全的保障，因为对称密钥也要通过非对称加密来传。
PGP用户没人维护两个表，一个私钥表（Private-key ring）一个公钥表（Public-key ring），私钥表存自己的公私钥对，公钥表存别人的公钥id和公钥。
PGP每个用户可能有多个公私钥对。
私钥表比较好理解，每个entry如下，主要就是这个公私钥对的id，公钥，以及使用passphrase key加密的私钥。
这个passphrase key就相当于是对自己的私钥提供了一层额外的保障，黑客只有同时妥协了passphrase key和私钥表，才能有他的私钥。
公钥表较复杂，
除了key id，公钥，所有者id以外，还有一堆trust什么的，传统的对称密钥通过一个公认的CA签名来确保公钥的合法性，PGP系统里使用这些信任来确定，这里一个一个看。
Owner trust就是我是否相信这个人给别人签的名，当然这里是一个degree。
signature就是某个人给这个公钥签的名，signature trust就是我是否相信这个签名。
key legitimacy是PGP系统算出来的，就是通过所有拥有这个公钥对应签名的人的signature trust来算出来的。
5.总结
总结以上内容，再来看一版完整版的PGP发送和接收流程。
发送的时候，还是先hash，这里签名之前，先要找到私钥，那就是先选择key id，然后去私钥表里找到加密过的私钥，用Passphrase key来解出来私钥，再来签名，签完名再把这个id和签名一起连接到原来的消息上。
然后还是压缩。
然后生成session key，对压缩文件进行加密，之后要用B的公钥加密session key，首先要找到B的公钥，他选择一个B的公钥id，去公钥表里找到B的公钥，加密session key，再把这个公钥id和加密的session key以及加密后的消息连接，这就是最终的发送的东西了。
再来看解密，拿到之后，先拆开，处理session key部分，用这个公钥id去自己的私钥表里找到对应的加密过的私钥，然后用Passphrase key解密出来私钥，再用私钥来解密session key。
有了session key就可以解密了，解出来是压缩文件。
解压缩，出来是签名部分和原文部分。
先处理签名部分，根据这个A的key id，去自己的公钥表里找对应的A的公钥，然后解签名出来一个哈希值，同时自己在对原文做一遍哈希，对比是否一致。
以上就是完整的流程了。
二、SMIME
这个比较简单，和PGP类似，但没有那么复杂的钥匙管理。
发送方就是哈希出来一个消息摘要，私钥签名，然后生成一个content-encryption key，对称加密，AES-128加CBC，然后再用对方的公钥加密这个对称密钥，附上一起传过去。
解密就是先拆出来对称密钥，用自己的私钥解密，然后把用对称密钥解密消息，然后拆出来签名，用对方的公钥验证签名。
公钥管理采用X.509 v3公钥证书。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
树 105. 从前序与中序遍历序列构造二叉树 思路 先序遍历中，树的根节点放在第一位，后面是左右子树。中序遍历中，树的根节点放在中间，两边分为左右子树 可基于以上规则区分出每棵树在数组中的区间 先从先序数组中拿到根节点的val 因为val不重复，定位到该树在中…
