版权声明：不自见故明；不自是故彰；不自伐故有功；不自矜故长； https://blog.csdn.net/LightUpHeaven/article/details/83384227
说是加密，不是只用一种加密方法，而是多种方法协作，达到我们的加密目的。
加密不是说加密完，就完事了，还要考虑第三方能不能解密 如果解密了该怎么办？
怎么加密更快？
如果对方解密了？我们怎么确保被解密的数据不被篡改？
加密特点：
对称加密：快速（加密数据，防止数据被查看，接收方反向解密得到数据明文）
非对称加密：认证身份（私钥签名，公钥解签，验证身份或数据）
单向加密：验证数据内容（生成数据签名，接收方用相同密钥运行单向加密，验证数据签名）
加密目的： 1.验证通信双方的身份 2.保证数据不能被（第三方）查看 3.保证数据没有被（第三方）篡改 加密流程： 首先公钥和密钥在加密的流程中其实牵涉到多个密钥。 其中包括：a.CA机构的公钥和私钥。b.CA认证的Server私钥和证书中的公钥。c.CA认证的Client的私钥和证书中的公钥。d.对称加密的密钥。 有7个之多，但不管有多少密钥，只要是成对出现的，都是一个公钥，一个私钥。这种成对出现的密钥用于非对称加密。如RSA加密。公钥用来加密，私钥用来签名，用法是固定的。 加密和签名的区别在于： 加密的数据针对的是接收者，而不是发送者。即只希望被接收者一个人看到加密之后的明文数据。 签名针对的则是发送者，不是被接收者。即解密之后，任何接收者都可以查看这个被加密的明文，因为这个明文只是为了说明发送者的身份，并没有其他不想让别人知道的数据。 正常情况下需要CA颁发的证书，这个的作用就相当于现实生活中的身份证。 一般的认证流程为： Server Client --下发CA的证书--> 验证证书的有效性。 [在OS或者浏览器中自带的证书中，找到该CA对应 的证书（注意是证书链，不是单个证书） 比如 用chrome打开www.wosign.com 然后点更多 工具->开发者工具->Security我们就能看到证 书。 打开证书，在证书的路径这一选项卡中，详细显示 了证书链： DigiCert（A） : WoTrus EV SSL Pro CA（B） : www.wosign.com（C） 可以看到最下层是CA颁发给这个网站的证书。往上 则是颁发证书的中间证书颁发机构。最上面则是受 信任的根证书颁发机构。且者三个证书都是可以查 看的，主要包括颁发者，使用者，有效期，公钥， 指纹。这里先验证证书的有效性。要验证C的有效 性，先要用它的上一级CA命名为B_CA的公钥来解 密C上的CA（即B_CA）签名，解签后如果明文和上 一级的B_CA信息匹配， 说明证书C确实是B_CA颁 发的。但是还要证明B_CA的有效性，所以要验证 证书B的可靠性，同样要用到证书A上的公钥要解密 B上的CA（即A_CA）签名，解签后，如果明文和上 一级的A_CA信息匹配，则说明B证书确实是A_CA颁 发的。这样递归检测父证书，直到出现信任的根证 书（证书列表内置于操作系统）。由此可见，除了 最底层的证书的公钥没有用到之外，上层的每一层 证书的公钥都用来解密下一层证书的证书指纹签 名。所以证书是否可靠呢？一句话，根证书可靠， 整个证书链就可靠。而根证书要看是否在操作系统 或浏览器内置的可信证书内。在的话就可靠。 此时，Client就可以确定Server的真实身份了。 ] <--将Client的证书发给Server-- Server验证Client证书的有效性。 使用单向加密（MD5，SHA）生成数据D的特征码X。 得到DX=D+X。 保证数据不被篡改。 用Server私钥将X用RSA加密生成数据签名S。 得到DS=D+S。 对DS使用Server的AES密钥AK进行AES对称加密。 得到DS=>New_DS。 对AK使用Client公钥加密生成EAK，并附加在DS上。得到EDS=New_DS+EAK; --发送EDS到客户端--> 先用Client私钥解密EDS中的EAK。得到AK。此时 数据有New_DS+AK. 再用AK解密EDS中的New_DDS。得到DS(D+S)。此 时数据有D+S. 使用Server公钥解密数据签名S。得到特征码X。 此时数据有D+X. 对数据D进行单向加密。得到Y特征码。 和进行对比。如果X==Y,说明数据D没有被篡改。 ============================================================================================== /**在本Server中没有使用CA颁发的证书，而是预先使用ssl命令获得RSA密钥和公钥.客户端服务器都省略了各自验证身份 的这一步骤。只是保证了数据不被第三方篡改和查看内容，并未实现各自身份的校验。所以服务器流程先各自预备好了，自己的 私钥和公钥，和对方的公钥。以营造一种已经互相验证过身份的环境。 **/
这种步骤是一般比较常见的通讯步骤，加密和解密都相当繁琐。效率不高。
当然还有SSL这种方式，不过用在游戏服务器中，也是首先模拟好已经各自验证过彼此身份的代码环境。
但是在握手之后，已经彼此信任的情况下，我们就不必对数据进行如此繁琐的加密方式，只需要简单的进行对称加密就行了。
当然对称加密的密钥肯定大有讲究的。SSL通讯详细步骤可参考。
SSL/TLS协议运行机制的概述
SSL/TLS 握手过程详解
此文参考：信息安全第三篇（网络传输的加密与解密）