之前访问服务器，clone git 仓库时经常会涉及到 SSH Key Pair，偶然一次浏览博客，博主将 GPG 公钥放在博客上，当时不明白有什么用。
最近又想起来，翻阅了一些资料。做点总结。
在讨论之前，先定义一些约定俗称的概念
基本概念#
加密通信有两个方面：即发送方和接收方。
加密的目的是为了让发送方发送的内容，只有接收方可以正常读取。
加密通信目前有对称加密和非对称加密两种。
什么是对称加密#
对信息进行加密和解密，是使用同一个密钥进行的。
这有一个条件就是，发送方和接收方需要知道同一个密钥。
其最大的缺陷是，发送方与接收方是分离的，两者并非一心同体，在双方同步密钥的过程中，密钥可能会被第三方获取，从而导致信息泄露。
其最大的优点是，加密和解密的速度非常快，适合大量数据的加密。
常用的 password 即可视为（实际不是）是对称加密的实践。
其用途主要是验证身份，理想的情况是，该用户是该用户，而不是其他人。
什么是非对称加密#
对信息进行加密和解密，是通过密钥对进行的，也就是公钥和私钥。
但是我们暂时抛开 密钥对 这个名称，只讨论公钥和私钥。
用公钥加密的内容，只能用私钥解密。即使是公钥的持有者自己加密的内容，也无法用私钥解密。
发送方持有公钥，接收方持有私钥。
发送方通过公钥加密明文，发送密文给接收方，接收方通过私钥解密密文，得到明文。
它破除了对称加密的缺陷，发送方和接收方不需要知道同一个密钥，只需要知道公钥即可。
当然，代价就是加密和解密的速度不如对称加密快。
这时候，可以保证发送方通过公钥发送的内容，只有接收方自己可以正常读取，可以认为这样的单向通信是安全的。
只要保证私钥的安全，即可保证单向通信的安全。
这一对密钥如何分别分发给发送方和接收方？
接受方负责生成公钥和私钥，并在通信前将公钥发送给发送方。即使公钥被第三方获取，也无法解密密文。
从而构建由发送方到接收方的单向通信。
但是这只是单向的安全通信，还不够。
还需要构建从接收方到发送方的单向通信。
既然可以保证第一次单向通信的安全，那么此时生成一个临时对称加密的密钥，发送给接收方，
也可以认为这个密钥除了接收方，其他人无法获取，后续用这个对称密钥进行通信也是安全的。
另外一种方法是发送方在发起通信的时候，生成另外一对公钥 A 和私钥 A，并将公钥 A 发送一并发送给接受方，接收方返回信息时，使用公钥 A 进行加密。
这很对称，有一种对称性的美，但是，略微有点代价沉重。
这是现在 TLS/SSL 保证安全通信的手段。
到这里解决了双向通信的加密问题。
再进一步，公钥和私钥还是 “对称” 的，还可以数字签名#
现在，用 公钥 加密的内容，能用 私钥 解密。
同时，用 私钥 加密的内容，也能用 公钥 解密！
然后再来看密钥对这个概念，就很名副其实了，公钥私钥是 “对等” 的。
我们不妨假设，我们将通常说的“私钥”分发出去，“公钥”保留在本地。让私钥公开，公钥保密。
其实也能够实现加密通信。但是往往私钥和公钥的密码学性质不等，生成的算法公钥会更简单，破解难度更小。
::
这很对称，太漂亮了。
那么这有什么用呢？
假设是这样的，私钥是一个人持有的，公钥是公开的。
用私钥加密的内容，能够用公钥解密。
那么能够用公钥解密出来的内容，和实际内容相同，就可以认为这个内容一定是私钥的持有者发出的。
证明了这份内容是私钥的持有者发出的。
这里的作用就是签名和验签。
这就顺带实现了数字签名的功能。
致辞
应用#
抛开概念再来看看应用。
GPG#
相关历史背景，可以参考这里。
我提交时，要签名的内容 ->ops 后的内容 -> 私钥加密 -> 签名
发送内容 + 签名
GitHub 收到提交
1. 用公钥解密签名的到期望的 ops 内容
2. 同时用要签名的内容进行同样的 ops-> 实际的 ops 内容。
3. 比对两者，相同则是有效签名