对加解密相关概率的一些理解的简述
不太严谨的概括性描述
对称密钥算法加密解密都是同一个密钥，所以需要让接受密文方事先知道密钥，而事先知道的方式一般通过网络或者预先存储在物理机器上，网络通信容易被获取，所以不安全;非对称密钥算法会生成公钥和私钥，如果用私密对一个明文进行加密（亦称为签名），目的是为了证明给“拿了它的公钥对密文解密（亦称为验签）的人”知道，这段信息是发布这个公钥的人发的；而如果用公钥对一个明文进行加密，目的是为了证明给“这个公钥对应的私钥的所有者”知道，这段信息是要发给他的;- 以上两种方法都无法无视直接地从物理上获取密钥/私钥;
对称密钥算法因为计算速度较快，一般信息加解密。而非对称密钥算法数字签名由信息发送方填写，作用为：证明“数据是该公钥生成人编写的，没被篡改”;数字证书由CA（证书授权中心）颁发，作用为：证明“你收到的公钥，的确是张三的”。
对称密钥算法
由对称密钥算法生成，生成的数量有可能是一个，也有可能是两个（有没有更多的我没了解过，这里只是代表值不一样，但是作用依旧一样），经常会遇到有人说，对称加密算法生成的密钥只有一种，是因为“对于同一段加密的明文，都可以通过任意一‘个’密钥进行解密”
非对称密钥算法
由非对称密钥算法生成两个，让别人随便获取的称为公钥，不能给别人知道的是私钥，但这两个密钥本质上并没有区别（在你将这一对密钥公布出去之前）。
因为只要这个公钥与私钥是同时由非对称加密算法生成的，公钥加密的内容，就可以被私钥解密；私钥加密的内容，就可以被公钥解密。
迪菲-赫尔曼密钥交换
其实在非对称密钥算法RSA出来以前，有个这么一个操作起来更为简单一点的交换加解密密钥的协议。通过这个协议，可以直接在网络环境下，非明文地交换对称密钥。至于实际会使用哪种对称密钥算法，则视实际而定。类似的密钥交换被广泛应用于TLS/SSL协议中的密钥协商阶段。
数字签名
例如：甲发出一条消息，其他收到这条消息的人需要确定消息发出人是不是甲。首先，甲需要公开它自己的公钥，而其他人如何获取“这个甲的公钥”，这个时候就需要作为第三方的认证中心（CA）了。此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。
作用：证明消息来自解密时使用的公钥生成人
而当接收方收到甲发出的“通过甲的私钥加密的消息”以后，就可以通过这个“可信的”公钥进行解密。同时也因为非对称加密的唯一加解密性，所以能被这个公钥解密的消息，也只有持有这个私钥的人。而为了避免消息内容其实是别人随意捏造，通常会在消息明文头部加上这段消息的哈希值后一齐加密再发出。接收方收到以后，就可以通过检查这段解密后的附加哈希值，是否与消息内容的实际哈希值相等，来判断消息是否来源于甲方了。
数字证书
上述所有加解密，还没有解决“中间人攻击”（传输过程中，有人截获并伪造公钥后转发假的公钥给你）问题。所以引入了数字证书的概念，数字证书可通过Certificate Authority（证书授权中心）颁发。作用相当于派出所，就是提供一个能够证明我是我（那个公钥是我生成的）的地方。而实现的方法，一般是把CA的证书预先内置在程序里面，到需要验证某个公钥是不是张三的时候，问内置的派出所（CA）所发的证书就好了。
综上所述
- 对称加密方式，不能直接防止信道监听的问题。可以密文传输，但一旦一开始被知道了对称密钥，将没有秘密可言；
- 非对称加密以及密钥交换协议在对称加密功能的基础上，增加了防止信道监听的问题。但是依旧会有第三方攻击的风险；
- 针对第三方攻击（第三方直接拦截了双方通讯的全过程，并伪造自己身份）的问题，增加了CA内嵌的技术。预先在程序中内嵌数字证书，也就是先预设一个公证。
题外：可靠加密通讯
证明“是我发的，也是要发给你的”。甲乙双方各自生成一对非对称密钥，并且通过一定的方法，交换双方的公钥。当甲需要发消息给乙的时候，先将消息用甲私钥进行加密，证明是自己发的，然后再将消息用乙公钥进行加密，证明是发给乙的（其实顺序不重要，即使是先用乙公钥加密，再用甲私钥加密，效果都一样）。
同理，乙发消息给甲的操作一样。以此来达到“可靠加密传输”。
