文章目录
密钥配送问题
上面几篇文章我们讲到了对称加密，包括它的几种实现AES，DES算法。那么有了对称加密算法，我们是否就可以安全的和第三方进行通信了呢？ 考虑如下情况：
小明想写一封情书给小红，但是这封情书是很私密的东西， 小明不想让除了小红之外的其他人知道。小明看过flydean的博客，他知道了有个对称加密的好东西。
于是小明想，如果我将情书使用对称加密算法进行加密，然后再把加密后的情书传给小红岂不就是安全了？ 但是小明又仔细思考了一下，发现了一个问题，对称加密算法必须需要密钥才能解密，除了传递情书以外，小明还需要把对称加密算法的密钥也传过去，这样小红才能正常解密。
但是怎么才能安全的传递密钥呢？ 密钥必须要发送，但是又不能发送，这个就是密钥配送的问题。
下面我们将一下解决密钥配送问题的几个方法。
事先共享密钥
解决密钥配送问题的最简单方法就是事先共享密钥，也就是小明提前将密钥交给小红。如果他们两个离得很近，那没有问题，直接线下见面交给小红就可以了。
如果他们分隔两地那就麻烦了。因为邮寄或者远程传输的过程中，密钥可能会被劫持。
即使能够有效的共享密钥，也会存在一个密钥保存的问题，每两个人间进行通信都需要一个完全不同的密钥，如果通信的人数很多的话，则需要保存一个相当大数量的密钥个数。实际操作起来不是很方便。
密钥中心分配密钥
为了解决保存大数量的密钥的问题。可以采用密钥中心来对密钥进行集中管理。我们可以将密钥中心看成是一个服务器，它里面保存了每一个人的密钥信息，下面我们看一下具体的通信流程：
- 小明和小红需要进行通信
- 密钥中心随机生成一个密钥，这个密钥将会是小明和小红本次通信中使用的临时密钥
- 密钥中心取出保存好的小明和小红的密钥
- 密钥中心将临时密钥使用小明的密钥加密后，发给小明
- 密钥中心将临时密钥使用小红的密钥加密后，发给小红
- 小明收到加密后的数据，使用自己的密钥解密后，得到临时密钥
- 小红收到加密后的数据，使用自己的密钥解密后，得到临时密钥。
- 小明和小红可以使用这个临时密钥自由通信啦 。
大家请注意，这里的临时密钥的使用方法很巧妙，后面我们会讲到大家最常用的https通信协议中对这个临时密钥的巧妙使用。
密钥中心很好，但是也有缺点，首先密钥中心的密钥是集中管理的，一旦被攻破，所有人的密钥都会暴露。
其次所有的通信都要经过密钥中心，可能会造成性能瓶颈。
使用Diffie-Hellman密钥交互
Diffie-Hellman 通过交互一些信息，双方来生成相同的密钥。具体的细节我们后在后面的博客中讲到。
使用公钥私钥
密码配送的原因就在于对称加密使用的密钥是相同的。 如果我们使用非对称加密算法（公钥只用来加密，私钥只用来解密），这个问题是不是就能够解决了？
回到小明和小红通信的问题，如果小红事先生成了公钥私钥，并把公钥发给了小明，则小明可以将情书使用公钥进行加密，然后发给小红，这个情书只有小红才能解密。即使公钥被窃听了也没有关系。
当然这里也有一个问题，就是小明要确保生成的公钥的确是小红发出来的。这个问题的解决方法我们会在后面讨论。
公钥密钥还有一个问题就是速度的问题，只有对称加密算法的几百分之一。
下面画个序列图，解释一下公钥密码的交互流程：
