关于对称和非对称加密的细节不赘述，至于为什么要组合应用，主要因为：

1、对称加密加解密用同一个密钥，速度快，但安全欠缺。

2、非对称加密使用不同的密钥进行加解密，速度慢（被加解密内容越大越明显），但是更安全。



如上图所示，利用非对称加密来加密对称加密的密钥，然后用对称加密的密钥加密整个网络交互的数据包。

对称加密的密钥，密钥字符串不会很大，使用非对称密钥加解密速度不是问题。而忘了交互直角传输的整个数据包可能比较大，采用对称加密的密钥加解密也比较合适，也不会很慢。
（结束）

区别

对称加密:加密解密用的都是一个秘钥。常见的算法有DES、IDEA、RC2等
非对称加密：私钥加密的内容只有公钥才能解开，公钥加密的内容只有私钥才能解开。也就是说，用其中一个钥匙加密，那么必须用另一个钥匙解密。常见的算法有RSA、DAS、ECC等。

非对称加密的使用场景
在了解使用场景之前，先分析一下非对称加密。

公钥私钥本质上是一样的(也就是说两者可以互换)，之所以这么区分，就是因为一个公开了，另一个没公开，公开了就意味着有风险。

如果我们先用私钥加密一个信息，然后把信息发出去，让别人用我们之前公开或发送的公钥解密来获取信息，这是一种使用方法。相应的场景有签名(服务端加签、客户端解签验证)。像我们平时通过xshell直连服务器，一般是通过ssh协议，xshll生成一对公钥私钥，把私钥放在本地C:\Users\用户名.ssh目录下并导入shell，把公钥发送给服务器管理员，放在服务器中。这样我们连接服务器的时候，使用自己私钥加密，然后发给服务器使其用公钥解密，达到一个签名的效果。再比如git中也是支持https和ssh两种协议。
相反的一个场景就是加解密了，比如常见的https中，服务端先给客户端发送一个公钥，客户端通过公钥解密一些信息(比如客户端生成的会话秘钥)，发送给服务端，服务端通过自己的私钥解密，达到信息安全传输的目的。

对称加密的适用场景
对称加密一般用在，我有一个秘钥，你也有这个秘钥，这个秘钥只有我们两个知道，所以可以用来传递一些隐秘的信息。

还是上面的https的流程，客户端和服务端拥有同一个会话秘钥，这样两者就可以通过这个秘钥加密会话，进行安全传输。

至于这个秘钥怎么来的，就是通过上面非对称加密的加解密场景。

声明：图片来自  github：https://github.com/russelltao/geektime-nginx 

对称加密与非对称加密各种的应用场景



	
对称加密
	


在对称加密这样一个场景中：两个想通讯的人，Bob和Alice，他们共同持有同一把秘钥，Bob可以通过这把秘钥把原始文档生成加密文档，Alice可以使用这把秘钥把加密文档还原成原始文档。而中间的任何人没有持有这把秘钥，即使他知道了对称加密的算法，他也没有办法把密文还原成明文。
	
对称加密实现原理
	
以RC4这样的一个对称加密的序列算法来看一下，利用了异或的特性
		
优点：性能好，加密或者解密遍历一次就完成了。
	
 





	
非对称加密
	



根据数学原理生成一对秘钥，如果我们称其中一个为公钥，那么另一个为私钥，公钥与私钥特性：

	
同一份明文文档，如果用公钥加密，那么只有用私钥才能把它解密；
		
如果用私钥加密，只有用公钥才能解密。
	
	
应用场景：
	
假如Alice有一对公钥和私钥，她就可以把公钥发布给大家，比如Bob，如果Bob想要传递一份原始文档给Alice，Bob就通过Alice的公钥给原始文档加密，把密文再发送给Alice，Alice拿她的私钥去解密，其他人用了公钥以后就没办法解密。
	
	
公钥和私钥还有一种用途：身份验证
	
比如现在有一段信息，Alice用她的私钥进行加密，然后把密文发送给Bob或者任何人，只要Bob拿到了Alice的公钥，公钥本身就是公开的，公钥能成功地解开这段密文，就这证明这段密文确实是Alice发出的。这为我们TLS的秘钥交换算法提供了基本的签名保证
	

强推：推荐一篇通俗易懂的对称加密和非对称加密的文章：https://segmentfault.com/a/1190000004461428
推荐一篇文章：对称加密算法与非对称加密算法的优缺点：https://zhuanlan.zhihu.com/p/38307899
 
1.对称加密


2.非对称加密
 
 

转载于:https://www.cnblogs.com/zkfopen/p/10261247.html