数字摘要加密过程

① 详解https是如何确保安全的

（多文字预警）

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL

下面就是https的整个架构，现在的https基本都使用TLS了，因为更加安全，所以下图中的SSL应该换为SSL/TLS。

下面就上图中的知识点进行一个大概的介绍。

对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或单密钥算法。
常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）；并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥，非对称加密也称为公钥加密，在密钥对中，其中一个密钥是对外公开的，所有人都可以获取到，称为公钥，其中一个密钥是不公开的称为私钥。

数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
数字签名的过程如下：
明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

数字签名有两种功效：
一、能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
二、数字签名能确定消息的完整性。

对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机那里发布的，而且没有被篡改过呢？亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢？这时候，我们需要有一个权威的值得信赖的第三方机构(一般是由政府审核并授权的机构)来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生。

用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息(根证书私钥签名)。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布，数字证书各不相同，每种证书可提供不同级别的可信度。

浏览器默认都会内置CA根证书，其中根证书包含了CA的公钥

1、2点是对伪造证书进行的。3是对于篡改后的证书验证，4是对于过期失效的验证。

SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取，当前为3。0版本。

SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

用于两个应用程序之间提供保密性和数据完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

SSL与TLS握手整个过程如下图所示，下面会详细介绍每一步的具体内容：

由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

客户端需要提供如下信息：

服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端一并发送给客户端。这里的随机数是整个过程的第二个随机数

服务端需要提供的信息：

客户端首先会对服务器下发的证书进行验证，验证通过之后，则会继续下面的操作，客户端再次产生一个随机数（第三个随机数），然后使用服务器证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新秘钥加密一段数据一并发送到服务器，确保正式通信前无误。
客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成一个Session Secret。

服务端在接收到客户端传过来的第三个随机数的 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成秘钥，一切准备好之后，也会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

后续客户端与服务器间通信
确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。

对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。

session ID
session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。

session ticket
客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。

总结
https实际就是在TCP层与http层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。

收录自| 原文地址

② 数字摘要的基本原理

数字摘要的基本原理:

发送端把原信息用HASH函数加密成摘要,然后把数字摘要和原信息一起发送到接收端,接收端也用HASH函数把原消息加密为摘要,看两个摘要是否相同,若相同,则表明信息的完整.否则不完整.
它用来保证信息的完整性

数字信封的基本原理:
发送端使用对称密钥来加密数据,然后将此对称密钥用接收者的公钥加密,称为加密数据的”数字信封”,将其和加密数据一起发送给接受者,接受者先用自己的私钥解密数字信封,得到对称密钥,然后使用对称密钥解密数据.
它用来保证信息的保密性.

数字签名的基本原理:
发送方首先用HASH函数对原文件生成数字摘要,用自己的私钥对这个数字摘要进行加密来形成发送方的电子签名,附在文件后.然后用一个对称密钥对带有电子签名的原文件加密,再用接收方的公钥给对称密钥加密,然后把加密后的密钥文件传送给接受方.接收方用自己的私钥对密钥密文解密,得到对称密钥,用对称密钥对原文件密文进行解密,同时得到原文件的电子签名,再用发送方的公钥对电子签名解密,得到电子签名的HASH 值,然后用HASH函数对得到的原文件重新计算HASH值,并与解密电子签名得到的HASH值进行对比.
它用来保证信息的不可抵赖性和完整性.

③ 数字摘要的基本原理

（1） 被发送文件用SHA编码加密产生128bit的数字摘要（见上节）。（2） 发送方用自己的私用密钥对摘要再加密，这就形成了数字签名。
（3） 将原文和加密的摘要同时传给对方。
（4） 对方用发送方的公共密钥对摘要解密，同时对收到的文件用SHA编码加密产生又一摘要。
（5） 将解密后的摘要和收到的文件在接收方重新加密产生的摘要相互对比。如两者一致，则说明传送过程中信息没有被破坏或篡改过。否则不然。

④ 简述数字签名的原理

数字签名就是附加在数据单元上的一些数据,或是对数据单元所作的密码变换。这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据,防止被人(例如接收者)进行伪造。

它是对电子形式的消息进行签名的一种方法,一个签名消息能在一个通信网络中传输。基于公钥密码体制和私钥密码体制都可以获得数字签名,主要是基于公钥密码体制的数字签名。包括普通数字签名和特殊数字签名。

(4)数字摘要加密过程扩展阅读：

数字签名有两种功效：一是能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。二是数字签名能确定消息的完整性。

因为数字签名的特点是它代表了文件的特征，文件如果发生改变，数字摘要的值也将发生变化。不同的文件将得到不同的数字摘要。 一次数字签名涉及到一个哈希函数、发送者的公钥、发送者的私钥。”

数字签名技术是将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

⑤ 数字签名的基本原理是什么

数字签名是基于非对称密钥加密技术与数字摘要技术的应用，是一个包含电子文件信息以及发送者身份并能够鉴别发送者身份以及发送信息是否被篡改的一段数字串。

一段数字签名数字串包含了电子文件经过Hash编码后产生的数字摘要，即一个Hash函数值以及发送者的公钥和私钥三部分内容。

数字签名有两个作用，一是能确定消息确实是由发送方签名并发出来的。二是数字签名能确定数据电文内容是否被篡改，保证消息的完整性。数字签名的基本工作流程如下：

发送加密

1.数字签名用户发送电子文件时，发送方通过哈希函数对电子数据文件进行加密生成数据摘要（digest）；

2.数字签名发送方用自己的私钥对数据摘要进行加密，私钥加密后的摘要即为数字签名；

3.数字签名和报文将一起发送给接收方。

接收解密

1.接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要；

2.接收方用发送方的提供的公钥来对报文附加的数字签名进行解密，得到一个数字摘要；

3.如果以上两个摘要相一致，则可以确认文件内容没有被篡改。

4.发送方的公钥能够对数字签名进行解密，证明数字签名由发送方发送。

以上过程逆向也可以进行，即当文件接受者想要回信时，可以先通过hash函数生成数字摘要，再用公钥加密即可起到文件加密的作用，收信人（数字签名拥有者）可以用私钥解密查看文件数字摘要。

• 函数加密原理

Hash函数又叫加密散列函数，其特点在于正向输出结果唯一性和逆向解密几乎不可解，因此可用于与数据加密。

正向输出容易且结果唯一：由数据正向计算对应的Hash值十分容易，且任何的输入都可以生成一个特定Hash值的输出，完全相同的数据输入将得到相同的结果，但输入数据稍有变化则将得到完全不同的结果。
Hash函数逆向不可解：由Hash值计算出其对应的数据极其困难，在当前科技条件下被视作不可能。

了解了数字签名，我们顺便来提一嘴数字证书的概念：

• 数字证书

由于网络上通信的双方可能都不认识对方，那么就需要第三者来介绍，这就是数字证书。数字证书由Certificate Authority( CA 认证中心)颁发。

首先A B双方要互相信任对方证书。

然后就可以进行通信了，与上面的数字签名相似。不同的是，使用了对称加密。这是因为，非对称加密在解密过程中，消耗的时间远远超过对称加密。如果密文很长，那么效率就比较低下了。但密钥一般不会特别长，对对称加密的密钥的加解密可以提高效率。