标签：七夕 私密 安全 密钥 密文 加密 之夜 服务端 客户端
七夕之夜，想和另一半聊一些私密的话，如何保证聊天内容不被***窥探，看完此文，终于略知一二了。
一、初级阶段：信息裸传
特点：在网络上传递明文;
***定理一：网络上传递的数据是不安全的，网络属于***公共场所，能被截取。
如何改进呢?很容易想到，先加密，再传输。
二、进阶阶段：传输密文
特点：
服务端和客户端先约定好加密算法，加密密钥;
客户端，传输前用约定好的密钥加密;
传输密文;
服务端，收到消息后用约定好的密钥解密;
***定理二：
客户端是不安全的，属于***本地范畴，能被逆向工程。
任何客户端与服务端提前约定好的算法与密钥都是不安全的，那如何改进呢?不能固定密钥，一个用户一个密钥。
三、中级阶段：一人一密，服务端生成密钥
特点：
客户端和服务端提前约定好加密算法，在传递消息前，先协商密钥;
客户端，请求密钥;
服务端，返回密钥;
然后用协商密钥加密消息，传输密文;
这么传输安全么?
答案是否定的。
根据***定理一，网上传输的内容是不安全的，于是乎，***能得到加密key=X;
根据客定理二，客户端和服务端提前约定的加密算法是不安全的，于是乎，***能得到加密算法;
于是乎，***截取后续传递的密文，可以用对应的算法和密钥解密;
应该如何优化呢?
根本上，密钥不能在网络上直接传输。
四、再进阶阶段：一人一密，客户端确定密钥，密钥不再传输
特点：
协商的密钥无需在网络传输;
使用“具备用户特性的东西”作为加密密钥，例如：用户密码的散列值;
一人一密，每个人的密钥不同;
然后密钥加密消息，传输密文;
服务端从db里获取这个“具备用户特性的东西”，解密;
***定理三：用户客户端内存是安全的，属于***远端范畴，认为是安全的。
画外音：中了***，电脑被控制了另说。
使用“具备用户特性的东西”作为加密密钥，一人一密，是安全的。但这仍不是最优方案。
五、高级阶段：一次一密，密钥协商
每次通信前，都进行密钥协商，一次一密。
密钥协商过程，如下图所述，需要随机生成三次动态密钥：
两次非对称加密密钥(公钥，私钥);
一次对称加密密钥;此称为，安全信道建立的“三次握手”，安全信道建立之后，再进行密文发送。
密钥交换的步骤为：
(1) 服务端随机生成公私钥对(公钥pk1，私钥pk2)，并将公钥pk1传给客户端;
画外音：此时***能截获pk1。
(2) 客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk11，通过pk1加密，传给服务端，服务端收到密文，用私钥pk2解密，得到pk11;
画外音：此时***能截获密文，也知道是通过pk1加密的，但由于***不知道私钥pk2，是无法解密的。
(3) 服务端随机生成对称加密密钥key=X，用pk11加密，传给客户端，客户端收到密文，用私钥pk22解密，可到key=X;
画外音：同理，***由密文无法解密出key。
至此，安全信道建立完毕，后续通讯用key=X加密，以保证信息的安全性。
六、总结
信息安全方案设计三大假设：
网络上传递的数据是不安全的，能被截取;
用户客户端是不安全的，属于***本地范畴，能被逆向工程;
客户端内存是安全的，属于***远端范畴，可以认为是安全的;
对于信息安全传输的不同阶段：
明文消息传递如同裸奔，不安全;
客户端和服务端提前约定加密算法和密钥，不安全;画外音：好多公司都是这么实现的=_=。
一人一密，服务端随机生成密钥，发送给客户端，不安全;
一人一密，客户端使用“具备用户特性的东西”作为加密密钥，安全;
一次一密，三次握手建立安全信道，安全;
好了，这下可以嘿嘿嘿了。
对了，很多公司说，我们绝不存储，绝不窥探用户聊天记录，你信不?
【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】
【编辑推荐】
【责任编辑：赵宁宁 TEL：（010）68476606】
标签：七夕,私密,安全,密钥,密文,加密,之夜,服务端,客户端 来源： https://blog.51cto.com/14887308/2524560
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。