Haproxy 公共密钥过弱 公钥密码应用

之前写了一篇密码学入门，看大家反馈还不错，所以根据之前的的经验，继续写一篇应用篇，算是一种延续。
这篇文章我会按照几个在产线中的应用模型逐个介绍。

通用模型

 

这个模型公私钥由资源服务方管理平台统一生成，并颁布给使用方，使用方用于自己的服务，例如微信公众等平台都类似采用这种方式。

这个模型公私钥都由用户方生成，用户一般通过账号密码登录资源方系统，将公钥注册进平台，这是典型的ssh验证，例如github等平台都是采用这种。

看来上面两个模型，都有一个共同点，都需要人去介入，所以大家可能会有问题，为啥资源方系统不直接放出公私钥接口，使用方直接调用就好了。如下图：

理论上是可行的，不过这种方式需要分情况讨论，如果使用方和资源方都是自己内部的服务系统没有问题，如果是第三方接入就会出现安全性问题。假设A是资源方，B是使用方

    情况一

1. 密钥由A产生，如果传输私钥给B，在网络传输过程就可能会被截取
2. 如果传输公钥给B，这种更不可信，不但是截取问题，公钥本身就是属于公开性质 情况二
3. 密钥由B产生，如果传输私钥给A，在网络传输过程就可能会被截取
4. 如果传输公钥给A，那么公钥可能在网络传输过程中被串改。
   难道就没有办法了吗？接着往下看。

复合型模型

 

从图中大家应该很容易看清流程。这里需要说明一点，为了增加安全性，对称算法的密钥的生成的规则也是双方规定, 一般可以采用种子随机数 + 时间性随机数，而只对种子随机数采用非对称加密，并在网络上传输，到达租户的端后，租户解密种子随机数，再通过某时间性算法生成基于这个时间窗口的随机数，两者组合起来就是完整的对称算法的密钥。
这样做的好处有几个：

1. 三重安全性，对称算法 + 非对称算法 + 时间有效性 + 组合规则
2. 更高效，采用RSA对对称密钥加密，采用对称算法对内容加密。

缺点：

1. 比较复杂
2. 对租户的时间有强一致性要求。不能差的过分离谱，要在一定的时间窗口内。

总结

虽然目前非对称算法有足够的安全性，不过在具体的应用中的使用，需要综合评估。只有最合适的才是最好的。喜欢的话，