RSA算法
数据加密的目的：数据加密的目的即是保证数据的完整性、机密性以及双方的身份验证。
基本概念：
- 通过单向散列算法可以实现数据的完整性验证。
- 通过对方的公钥加密可以实现机密性。
- 通过自己的私钥加密可以实现身份验证
下面以RSA（非对称加密算法来举例）
身份认证：
身份认证比较简单，通过自己的私钥加密，对方通过自己事先公布的公钥解密，如果能打开就说明身份无误，我原本是这样理解的。但实际上比这复杂一点点儿，过程是这样的：
A给B发送数据之前，A会发一段不加密的随机数（同时保留一份），B通过自己的私钥加密后再发送给A，A通过B的公钥解密之后，与保留的随机数做对比，如果两者是一样的，说明B就是B，因为B的私钥只能由B拥有。反之即可实现A就是A。
以上就是利用非对称加密来进行身份认证的理论基础。
机密性：
假设A和B双方都已经生成公钥和私钥，而且已经有了对方的公钥（至于如何获得了对方的公钥，我们后面会详细讲的）。A给B发送数据时，A用B的公钥加密数据，然后发送给B，由于数据是用B的公钥加密的，所以也只能由B的私钥打开，B的私钥只有B自己知道（私钥是自己严格保存的），这样中间人即使截获了数据也无法解密，这样即保证了数据的机密性。
在实际的应用过程当中，是不会直接用非对称密钥加密数据的，非对密钥非常复杂，密钥比对称加密密钥要长很多，所以加密的速度非常慢，如何解决这个问题呢？对称加密的速度非常快，可以使用非对称加密和对称加密结合，这样即满足了速度也满足了机密性，过程如下所述。
双方不会直接将公钥发送给对方（怕中间人截获），而是通过非对称加密的方式加密一段素材和一个对称加密算法发送给对方，让对方通过这段素材和对称加密密钥计算出，A给B发送数据之前，A用B的公钥加密一段素材和一个对称加密算法，注意，这次加密的不是要传输的数据，而仅仅是一段素材，B用自己的私钥解开之后，就得到了一个对称算法和一段素材，B通过这个算法和素材，就可以计算出一个对称密钥，同样，B也变使用这样的方式告诉A对称密钥。以后A和B再交换数据时，就不再使用非对称密钥算法了，而使用对称密钥算法。
完整性验证：
使用私钥加密公钥解密的方式，不仅可以实现身份验证还能实现完整性验证，完整性验证还要单向散列算法的配合。
完整性验证又被称为签名功能，所谓签名就是在数据后面再加一段内容，然后用私钥进行加密这一段内容，注意数据这时并没有加密。
A把要发送的数据通过单向算法计算出一个特征码，附加在数据的尾部，然后通过自己的私钥加密特征码；当B收到之后，也根据同样的单向算法对数据提取了一个特征码，然后通过A的公钥将特征码解密出来，与自己计算出来的做一个对比，对比是否一样，如果是一样的，就说明数据没有被篡改过，数据是完整的。这样同时实现了身份验证和完整性验证，身份验证是通过私钥加密的特征码然后被对方拿着公钥解开实现的，完整性性验证是通过单向散列算法实现的。
证书证书的生成
通信双方每次都把自己的公钥发送给对方，这是最直接的方式。但是这种方式存在着安全问题，因为谁都可以生成公钥和私钥，仅凭一个公钥，我们无法判断收到的公钥到底是不是对方的。除非对方把公钥和身份信息同时发过来，并且有绝对可信的第三方做担保，证明这个公钥确实是对方发的。也就是说，通信双方就需要一个安全可信的载体也交换密钥，这个载体就是证书。
证书，也叫做数字证书，是网络世界中的“身份证”。证书将持有者的身份信息和公钥关联到一起，保证公钥确实是这个证书持有者的，通过证书就可以确认持有者的身份。证书由权威，公正的、可信任的第三方机构颁发，我们把证书的颁发机构称为CA，相当于现实生活中的公安局。
公钥是通过证书向外界公开分发的，证书中必然会有持有者的公钥信息。除此之外，证书当中还包含哪些信息呢？
- 签名算法：生成该证书时所使用的哈希密码学算法和公钥密码学算法，签名的时候需要哈希算法和非对称密钥两种算法
- 颁发者，CA的名字
- 主题，证书者持有者的名字
- 公钥，证书持有者的公钥信息
- 签名，CA对该证书的签名，又叫做CA的指纹信息。
CA使用签名算法中的HASH密码学算法，生成证书的摘要信息，然后使用非对称加密算法（配合CA自己的私钥）对摘要信息进行加密，最终形成签名。
数字签名实现了完整性和身份认证并没有实现机密性。
证书的颁发
普通的PC并不能直接生成私钥和公钥，需要CA帮忙生成私钥和公钥，然后在此基础上生成证书，然后PC将CA帮忙生成的：公钥、私钥、证书统统导入到自己的系统当中。此时CA就兼顾了证书颁发和密钥管理的功能。
而对于硬件防火墙、加密机、上网行为管理这些设备，可以直接生成公钥和私钥，然后将公钥和私钥以及申请的信息提交给CA，CA根据这些信息生成证书，防火墙只导入生成后的证书。其实也可以让CA帮忙生成。
如果让权威CA给我们颁发证书的话，过程太麻烦，有的时候我们可以自己搭建一个CA，比如像12306就是自己搭建的CA，我们自己搭建CA，想发随时就可以发，这样管理起来就比较方便，不用走流程。
证书验证
CA给我们颁发的证书包含着：用户的公钥和CA的数字签名。这意味着什么呢？意味着我们已经验证好了CA的身份，因为CA用自己的私钥对特证码进行签名，我们拿着CA的公钥能打开就说明这个签名就是CA签署的，当然同时也实现了完整性的验证。
证书颁发给使用者使用后，使用者就会拿着证书证明自己的身份，我们收到了这样一个证书，怎样才能判断这个证书就是合法的，不是伪造的呢？其实我们也可以使用与使用者一样的验证方式来验证这个证书是否是合法的，过程如下所述。
例如，A收到了B发过来的证书，A会首先把B的公钥进行哈希算法运算提取特征码（至于使用哪一种哈希算法证书里面有，这个算法一定要和CA给B签名时用的是一样的。然后用CA的公钥打开数字签名，如果能打开就说明为B颁发证书的CA是权威的，合法可信的，因为能用CA的公钥解密说明该CA确实持有私钥，最后A用解密得到的特征码和自己计算的特证码对比进行完整性验证。当然，顺便也会检查证书是否在有效期内。
写到这里大家可能有疑问，为A颁发证书的那个CA的公钥又该如何获取呢？答案还是证书，从CA的证书获取，也就是说，CA自己还有证书，这个证书是CA自己给自己颁发的，这个证书里面也有CA的公钥。权威机构的证书通常都是系统内置的，我们不用导入。如果是我们自己搭建的CA，那就要把CA的证书导入系统内部了，比如12306。
通常情况下，用户只需要验证网站的证书，而网站不需要验证用户的证书。但是在网络设备当中，就可能是双向的验证了（比如加密机），上述我们讲的A验证B，反之就是B验证A，过程再简单的描述一下。
- A要验证B的证书，A要事先获得为B发证CA的证书，用CA的证书验证B的证书。
- B 要验证A的证书，B要事先获得为A发证CA的证书，用CA的的证书验证A的证书。
- 如果A和B的由同一个CA颁发的，那么两者的CA是相同的；如果A和B是由两个不同的CA颁发的，那么两者获取的CA是不同的。
对于证书的使用方法，下面我们再进一步总结。
- 通信双方各自持有的自己的证书，当一方需要向另一方证明身份时，就把自己的证书发送过去。双方不用事先保存对方的证书，只在验证时接收对方发送过来的证书即可。
- 一方验证另一方证书的真伪时，必须事先获取到为另一方颁发证书的CA的证书，用这个CA证书来验证对方的证书。
- 因为不同的CA会颁发不同的证书，所以在证书的世界里面，每个设备可能会持有多个证书。同理，每个人也会获得多个不同的CA证书。在这种情况下，一方收到另一方的证书时，会根据证书中颁发者的名字，在自己的系统当中找对应的CA证书，找到后就用这个CA证书来验证。如果没有找到，那就说明事先没有获取到CA证书，也就无法判断对方发送过来的真伪。
CA的操作
- 生成一对密钥。
- 利用公钥和申请信息产生一份申请文件提交给自己（此文件当中包括自己的公钥）。
- 自己生成自己的数字签名证书：CA先利用hash提取出这个文件的特征码附加到文件的尾部，然后自己的私钥对此特征码加密，注意，文件并没有加密。
- 将此数字签名证书公布于众，各大操作系统的发行商会将其集成到自己的操作系统当中。
服务器
- 生成一对密钥
- 利用公钥和申请信息产生一份申请文件提交给CA（此文件当中包括自己的公钥）。
- CA对申请信息核实无误之后，会生成数字签名证书：CA先利用hash提取出这个文件的特征码附加到文件的尾部，然后自己的私钥对此特征码加密，注意，文件并没有加密。
- CA将此数字证书给HTTP，HTTP会将其放置到自己的工作目录的。
Client
Client默认就是有CA自己的数字签名的，也就是说用户有CA的公钥，发行商集成的嘛！
- 当客户端访问网站时，当然先建立虚链路、然后服务器会把CA签名过的数字证书发送给客户端。
- 客户端验证，怎样验证呢？用CA的公钥尝试打开网站给的数字证书当中被加密后的特征码，如果打开了就实现了身体验证，打开之后利用hash进一步验证完整性。
- 客户端拿到网站的公钥之后会随机生成对称密钥，通过公钥加密之后发送给网站，然后后面它们加密的数据都是用对称密钥处理之后再发送，我们抓包看到的HTTPS乱码都是通过对称加密之的。
