一、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 ASCII码，所以刚才那一套认证、加密走完之后的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公钥证书。