非对称加密算法

1976年，两位美国计算机学家Whitfield Diffie 和 Martin Hellman，提出了一种崭新构思，可以在不直接传递密钥的情况下，完成解密。这被称为"Diffie-Hellman密钥交换算法"。这个算法启发了其他科学家。人们认识到，加密和解密可以使用不同的规则，只要这两种规则之间存在某种对应关系即可，这样就避免了直接传递密钥。

这种新的加密模式被称为"非对称加密算法"。

（1）乙方生成两把密钥（公钥和私钥）。公钥是公开的，任何人都可以获得，私钥则是保密的。

（2）甲方获取乙方的公钥，然后用它对信息加密。

（3）乙方得到加密后的信息，用私钥解密。

如果公钥加密的信息只有私钥解得开，那么只要私钥不泄漏，通信就是安全的。

CA：产生和确定数字证书的第三方可信机构。

画外音：没有经过公证的秘钥对是不可信的。

在我们实际开发中，一般会用到加密和签名，总结一句：

加密，公钥负责加密，私钥负责解密；

签名，私钥负责签名，公钥负责验证。

既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密；同理，既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。

非对称加密应用十分广泛，系统对接，https等。相比对称加密更加安全，但也存在两个明显缺点：

CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。

非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。

所以公钥加密目前只能用来作密钥交换或者内容签名，不适合用来做应用层传输内容的加解密。

知识点：用非对称加密来加密传输对称加密的秘钥，用对称加密来加密数据，两者相互结合，优势互补。

RSA公钥和私钥的推导过程：

挺有意思的，一定要自己推理一遍，不明白的地方，谷歌一下！

每周一句|自律是一步一步的，一点一点的，一口气吃不了个胖子。没关系，有三分钟热度就有三分收获，有三分钟的收获就会有四分钟的……