加密技术

1、对称加密

1、什么是对称加密？

对称加密就是指，加密和解密使用同一个密钥的加密方式。需要用到的有加密算法和加密秘钥。例如加密算法可以类似这样的加密规则(a ->b，b->w，c->a)

2、对称加密的工作过程

发送方使用密钥将明文数据加密成密文，然后发送出去，接收方收到密文后，使用同一个密钥将密文解密成明文读取。

3、对称加密的优点 和 缺点

优点：加密计算量小、速度快，效率高，适合对大量数据进行加密的场景。
缺点：（1）密钥不适合在网上传输（容易被截取），（2）密钥维护麻烦

4、常见的对称加密算法

DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES。

5、数据加密标准DES

数据加密标准DES属于常规密钥密码体制，是一种分组密码。加密前，先对整个明文进行分组，每一组长为64位，然后对每一个64位二进制数据进行加密处理，产生一组64位密文数据。最后将各组密文串接起来，即得出整个的密文。使用的密钥为64位（实际密钥长度为56位，有8位用于奇偶检验）

DES的保密性取决于密钥的保密，而算法是公开的。尽管人们在破译DES方面取得了许多进展，但至今仍未能找到比穷举搜索密钥更有效的方法。DES是世界上第一个公认的实用密码算法标准，它曾对密码学的发展做出了重大贡献。目前较为严重的问题是DES的密钥长度，现在已经设计出搜索DES密钥的专用芯片。

DES算法安全性取决于密钥长度，56位密钥破解需要3.5到21分钟，128位密钥破解需要5.4 * 10^18次方年

注意的是：这里是没有密钥的情况下，直接穷举密钥尝试破解。如果密钥在传送过程中被人截取了，就相当于直接知道加密规则了，根本不需要破解，因此密钥在网络中传送还是不安全。

2、非对称加密

1、什么是非对称加密？

与对称加密算法不同，非对称加密算法需要密钥对，即两个密钥：公开密钥（公钥）和私有密钥（私钥）。

公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

公钥和私钥是怎么来的？
操作系统随机生成一个随机数，将这个随机数通过某个函数进行运算，分成两部分，公钥和私钥

2、非对称加密的工作过程

• A要向B发送信息，A和B都要产生一对用于加密和解密的公钥和私钥。
• A的私钥保密，A的公钥告诉B；B的私钥保密，B的公钥告诉A。
• A要给B发送信息时，A用B的公钥加密信息，因为A知道B的公钥。
• A将这个消息发给B（已经用B的公钥加密消息）。
• B收到这个消息后，B用自己的私钥解密A的消息，其他所有收到这个报文的人都无法解密，因为只有B才有B的私钥。
• 反过来，B向A发送消息也是一样。

3、非对称加密的优点 和 缺点

优点：安全性高
缺点：加密与解密速度慢。

4、常见的非对称加密算法

RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）。

5、为什么把公钥给了别人，而私钥一定要保存好，能不能给那个人发信息的时候也用私钥加密

答案是不能
鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥直接明文传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开这条数据。
然而由服务器到浏览器的这条路怎么保障安全？如果服务器用它的的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，这个公钥被谁劫持到的话，他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据时的安全性（其实仍有漏洞，下文会说）。

3、混合加密

1、先通过非对称加密技术，把对称加密的密钥X传给对方，使得这个对称加密的密钥X是安全的
2、后面再通过对称加密技术进行数据传输

详细流程
（1）服务器端拥有用于非对称加密的公钥A、私钥A’。
（2）客户端向网站服务器请求，服务器先把公钥A明文给传输浏客户端
（3）客户端随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器端。
（4）服务器端拿到后用私钥A’解密得到密钥X。
（5）这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。

image.png

4、数字签名

数字签名是基于公钥密码体制（非对称密钥密码体制）的。

1.1.基本特征

数字签名必须保证以下三点：

• 报文鉴别——接收者能够核实发送者对报文的签名；
• 报文的完整性——接收者不能伪造对报文的签名或更改报文内容。
• 不可否认——发送者事后不能抵赖对报文的签名；

1.2.数字签名的验证过程

image.png

上图位用户A使用数字签名向用户B传输一份文件的过程：

• 首先，文件经过单向散列函数的处理得到一份占128位的摘要（无论文件多大，经过单向散列函数的处理，生成的摘要都是128位），这份摘要相当于该文件的"指纹"，能够唯一地识别文件。注意：只要文件发生改动，经过单向散列函数处理后得到地摘要都会不一样。所以，文件和文件的摘要具有很强的对应关系。

• 随后，用户A使用自己地私钥对这份128位地摘要进行加密，得到一份加密地摘要。

• 然后，用户A把文件、加密的摘要和公钥打包一起发给用户B。传输的过程中并没有对文件进行加密处理。

• 用户B将收到的文件经过单向散列函数处理得出一份128位摘要，这份摘要是通过收到的文件得到的，存在被更改的可能；使用A提供的公钥对收到的"加密的摘要"进行解密得到另一份128位摘要，这份摘要是通过原始文件得到的，一般认为代表真正的文件；然后将两份摘要进行比较。

• 如果两份摘要相等，说明文件经过用户A签名之后，在传输的过程中没有被更改；若不相等，说明文件在传输过程中被更改了，或者说已经不是原来的文件了，此时用户A的签名失效。

数字签名三个特征的验证

• 不可否认——只有用户A拥有私钥A，并能使用私钥A产生"加密的摘要"，这样用户A就不能否认给用户B发送了经过签名的密文。
• 报文的完整性——用户B通过比较得出的两份摘要是否相等，可以判断签名或文件内容是否发生改变。
• 报文鉴别——用户B可以使用收到的公钥对"加密的摘要"进行解密，从而核实用户A对文件的签名。

需要强调

• 用户A使用私钥对由文件生成的128位摘要进行加密的过程称为数字签名的过程，得到的"加密的摘要"，称为该文件的数据签名。
• 用户A使用私钥加密的是摘要而不是文件。
• 用户B验证签名实际上是比较得出的两份摘要是否相等。

1.3.数字签名使用的场合

什么时候使用这种不对文件加密，而对文件的摘要加密（对文件进行签名）的技术呢？

• 数字签名解决的核心问题是：确保收到的文件没有被更改。
• 比如：公司的领导给员工下发放假通知，这时候就需要对邮件进行数字签名来证明这个通知是领导发的。员工收到通知，看到上面有领导的签名，于是就可以放心休假了。如果有人冒充领导发通知，上面没有领导的签名，员工休假回来就要扣工资。同样的，通知有了领导的签名，领导想抵赖也不行。

5、证书颁发机构CA

1.1CA简介

• 证书颁发机构，即认证中心CA (Certification Authority)，来将公钥与其对应的实体（人或机器）进行绑定(binding)；即给公司或个人颁发证书。

• 认证中心一般由政府出资建立。每个实体都有CA 发来的证书(certificate)，里面有公钥及其拥有者的标识信息。此证书被 CA 进行了数字签名。任何用户都可从可信的地方获得认证中心 CA 的公钥，此公钥用来验证某个公钥是否为某个实体所拥有。有的大公司也提供认证中心服务。
  

  image.png
  
  如图所示，用户A使用数字签名时给用户B发送了一个数据包，数据包中包含了A的公钥、文件和加密的摘要。那么问题来了：用户B如何确定收到的公钥是用户A发送的，而不是他人冒充用户A发送的呢？
  • 举个例子：把用户A的公钥和私钥假设为身份证。如果是用户A自己造的身份证别人会信吗？反之，用户A拿着真正的身份证去住宾馆，老板一开始也不相信身份证是用户A的，但是老板相信给用户A发身份证的公安局，老板通过比对公安网上对应身份证号码的信息就可以判断这个身份证是不是用户A的，由此可以确认用户A的身份。
  • 同理，B一开始并不确认收到的公钥是来自用户A的，用户A也可抵赖B收到的公钥不是自己发送的。这时就需要有一个双方都信任的第三方证书颁发机构来协调。

1.2.证书颁发和使用过程

image.png

• 首先，用户A向证书颁发机构提交个人信息，申请证书。通过CA审核后，CA生成用户A的证书，证书中包括了A的公钥和私钥还有CA的数字签名。证书颁发机构CA本身拥有一对密钥，这是对CA所颁发的证书进行数字签名和保密的基础，绝不能泄露。

• 用户A收到的证书中包括了带有CA数字签名的，专属A公钥和私钥，CA的数字签名确保了别人不能伪造用户A的公钥和私钥。

• 同时，用户B也必须信任给用户A颁发证书的第三方认证机构CA，即用户B拥有CA颁发的"CA公钥"。

• 通信时，用户A向用户B发送的数据包中的"加密的摘要"上有用户A的数字签名，“A公钥” 上有认证机构CA的数字签名。用户B收到数据包之后，先要验证收到的 “A公钥” 是否来源合法：是认证机构颁发的带有CA签名的公钥吗？用户B并不信任用户A，但是用户B信任第三方认证机构CA。所以，用户B先使用证书颁发机构颁发的 "CA公钥" 验证收到的 "A公钥" 是否由同一认证机构颁发，是否在颁发之后更改过。

• 验证通过后，用户B便相信收到的 "A公钥" 确实来自真实的用户A。随后再使用 "A公钥" 对 "加密的摘要" 进行解密，进行上文提到的对比操作，以判断文件是否更改。

注意：这里强调的是只有“A公钥” 上有认证机构CA的数字签名，意思是CA用它的私钥对“A公钥”的内容进行单向散列函数得到的加密摘要（数字签名），该签名放在“A公钥”中（左上角那个），对于B用户来说，它从可靠的路径拿到CA的公钥，使用CA的公钥解密“A公钥”的内容得到的128位的摘要 和 “A公钥”的内容通过单向散列函数计算出来的是否一致，如果是表示认可这个“A公钥”

image.png

1.4.证书的吊销

当用户A遗失或泄露了CA颁发的证书后，为了避免他人使用该证书冒充用户A，用户A向认证机构CA "挂失" 该证书。于是认证机构CA把该证书放入该认证机构的证书吊销列表（CRL）中，并在网上公示。

用户B在收到用户A的公钥时，除了要验证该公钥是否位认证机构颁发的，还要登录认证机构的网站查看该公钥是否已被认证机构吊销变为无效证书。

1.5.总结

认证机构CA的作用：

• 为企业和用户颁发数字证书，确保这些企业和个人的身份是真实的；
• 发布证书吊销列表，供用户查询收到的证书是否已被机构吊销而无效；

6、http 和 https的区别

1、http连接很简单，是无状态的，明文传输。https协议 = http协议 + SSL，可以进行加密传输，身份认证
2、http连接的是80端口，https连接的是443端口
3、https协议需要服务器端到CA申请SSL证书，即客户端请求的时候，服务器端发送SSL证书给客户端，SSL证书内容包括公钥、CA机构的数字签名。验证了服务器端的身份以及公钥的可靠性。（注意：混合加密那里“将公钥A给客户端”，严格的来说是把SSL证书给客户端）

SSL提供以下三个功能
1、SSL服务器鉴别。允许用户证实服务器的身份。具有SSL功能的浏览器维持一个表，上面有一些可信赖的认证中心CA和它们的公钥
2、SSL客户鉴别。允许服务器证实客户的身份。
3、加密的SSL会话，通过混合加密实现的。客户和服务器交互的所有数据都是发送方加密，接受方解密

SSL的位置

image.png

7、http请求报文

1、请求行

（1）方法：get，post，head，put，delete，option，trace，connect
（2）URL字段
（3）HTTP协议版本

2、请求头

User-Agent：产生请求的浏览器类型
Aceept：客户端可识别的内容类型列表
Host：主机地址

3、请求数据 （post方法中，会把数据以key value形式发送请求）

4、空行 （发送回车符和换行符）

8、http的常见状态码

200：请求被成功处理
301：永久性重定向
302：临时性重定向
403：没有访问权限
404：没有对应资源
500：服务器错误
503：服务器停机

9、http1.0 和 http1.1的区别

• http1.0 一个文件建立一个TCP连接（例如一个网站有3张图片，需要额外建立多3次TCP连接）
• http1.1 访问网站，建立一个TCP连接，可用这个连接传输所有文件，有流水线和非流水线两种方式

10、HTTP协议中的长连接和短连接

HTTP协议的底层使用TCP协议，所以HTTP协议的长连接和短连接在本质上是TCP层的长连接和短连接。由于TCP建立连接、维护连接、释放连接都是要消耗一定的资源，浪费一定的时间。所对于服务器来说，频繁的请求释放连接会浪费大量的时间，长时间维护太多的连接的话又需要消耗资源。所以长连接和短连接并不存在优劣之分，只是适用的场合不同而已。长连接和短连接分别有如下优点和缺点：

• 长连接优点：可以节省较多的TCP连接和释放的操作，节约时间，对于频繁请求资源的用户来说，适合长连接。

• 长连接缺点：由于有保活功能，当遇到大量的恶意连接时，服务器的压力会越来越大。这时服务器需要采取一些策略，关闭一些长时间没有进行读写事件的的连接。

• 短连接优点：短连接对服务器来说管理比较简单，只要存在的连接都是有效连接，不需要额外的控制手段，而且不会长时间占用资源 。

• 短连接缺点：如果客户端请求频繁的话，会在TCP的建立和释放上浪费大量的时间。

注意：从HTTP/1.1版本起，默认使用长连接用以保持连接特性。使用长连接的HTTP协议，会在响应消息报文段加入: Connection: keep-alive。TCP中也有keep alive，但是TCP中的keep alive只是探测TCP连接是否活着，而HTTP中的keep-alive是让一个TCP连接获得更久一点。