1. 首页
  2. 个性签名

【区别】摘要、数字签名、数字证书的工作原理

数字签名如何计算验证

1、摘要


一段信息,经过摘要算法得到一串哈希值,就是摘要(dijest)。

信息是任意长度,而摘要是定长。

摘要算法有MD5、SHA1、SHA256、SHA512等,算法把无穷的映射成有限,因此大概会有碰撞(两个差别的信息,算出的摘要相同)

摘要差别于加密算法,由于不存在解密,只不外从摘要反推原信息很难(可以以为能加密但无法解密还原,但可以用于比对)。类比到人的话:时间不停向前走 ,我没有措施从如今的你身上反观到你已往的样子,也没法从如今的他身上反观到他已往的样子……但你们如今的样子依然有作用,那就是在于“是否相同”:我可以通过比对如今的你和如今的他是否相同,来判定已往的你和他是否相同,而无需知道已往的你和已往的他详细是什么样子。

摘要相同,信息肯定相同。 假如两张图片的md5相同,说明图片完全一样,不需要重复爬取。

使用这个特点,摘要还可以用于应用在网站后台数据库中,用于比对用户的 输入密码和预设密码是否相同 。这里都无需体贴密码本身是什么,关注的是密码是否相同,而密码是否相同取决于摘要是否相同,以是问题转化成了 摘要是否相同 。将用户密码的摘要而不是密码本身保存在数据库中,由于反推很难,以是真实密码是保密的……非要袒露的话,也是通过比对而不是反推。



2、非对称加密算法

算法重要的观点是公钥和私匙。

先有私钥,再用函数天生公钥。公钥包含了私钥的信息,但也掺杂了其他随机变量,因此不能反推。

私匙不要泄漏,公钥要告诉和你通讯的对方。公钥加密,只有对应私钥能解开(保密);私钥加密,只有对应公钥能解开(不可狡辩)。

详细有两种情况:

(1)对方用你的公钥加密信息,你收到后用私钥解开。

只有你有私钥,以是只有你能解开,换句话说,有私钥才能看到信息,很安全。

(2)你拿私钥加密信息,对方收到后用你的公钥解开。

公钥是公开的,以是其他人也可以看到你的信息,不保密。

私钥加密,只有对应公钥能解开。既然用你的公钥能解开,说明加密肯定是你的私钥。私钥只有你有,以是肯定是你发送的,你不可狡辩。



3、数字署名 摘要经过加密,就得到数字署名

数字署名在发送方,分两步:(1)从内容算摘要(哈希算法)(2)从摘要明文到摘要密文,也称数字署名(发送方私钥+加密算法)

数字署名验证在吸收方,分两步:(1)从摘要密文(数字署名)到摘要明文(发送方公钥+解密!算法)(2)从收到的内容就地盘算摘要(哈希算法),与(1)的结果比对是否同等


假如同等,可以说明两点:

(1)内容未被窜改(摘要同等)

(2)内容只能是私钥拥方发送,不可狡辩(密文可以或许用对方的公钥解开)


然后单独想一下,

(1)为什么要对摘要加密后再发送?为什么不直接发摘要?摘要不可以逆向推导原文,摘要泄漏了也没事……

答:摘要泄漏是没事,但不怀美意的人的目标大概并不在想要窃听你发送了什么,而是想伪造发送的内容让你相信。通过同时更换摘要和内容,很easy就实现了。以是摘要需要经过加密,不怀美意的人没有私钥,无法完成加密。要么说你收到的工具只要能用公钥解密,你才以为这个工具确实是对应私钥持有者完成的。这叫做当事人不可狡辩,同时别人无法仿冒。(数字署名:不可狡辩+无法仿冒)

(2)为什么不直接对内容加密,而是老师成摘要,对摘要加密?

答:大概是内容很长吧,直接加密算半天!摘要算法可以把无穷长的内容输出发展度固定的摘要,再进行加密时间就是可以预估的


4、数字证书

上面的所有都很完美,你用公钥可以或许解密,说明白实是私钥方发送的,你很放心……

但有没有想过,万一这把公钥本身,就被人做了手脚???

为了保证“公钥”是可信的,数字证书应运而生。

数字证书里有个重要观点,CA,发送方先把自己的公钥给CA,CA对其进行加密得到加密后的发送方公钥(用的是CA的私钥和CA加密算法),也就是CA的数字证书。

留意这里有两个差别的非对称算法(对应2个公钥私钥对),一个算法是发送方加密摘要的,用于天生数字署名;另一个算法是CA加密发送方公钥的,用于天生数字证书。两个算法相互独立,没有一定联系。

发送时不但发送内容、数字署名,还包含发送方的数字证书。吸收方拿到后,首先从数字证书中解密出发送方公钥(用的是CA的公钥和CA解密算法),这个公钥一定是可信的。然后就是和前面一样的流程,拿发送方公钥去解密数字证书,得到摘要;最后比对摘要是否同等。


一个问题:既然数字证书是为了保证发送方公钥不是别人伪造的,那怎么保证“CA”的公钥不是伪造的呢?

答:CA是第三方机构,CA公钥是公开的,吸收方可以跟别人比对(好比在网上查询),因此不大概伪造。但是发送方公钥,吸收方是通过通讯得到的,收到后无法验证。


【实例1】https


工作流程,基本分为三个阶段:
1、认证服务器。browser内置一个受信托的CA机构列表,并保存了这些CA机构的证书。第一阶段服务器会提供经CA机构认证颁发的服务器证书,假如签发该证书的CA,存在于browser的受信托CA列表中(也就是签发该证书的CA的根证书,可以或许与客户端中保存的CA根证书比对上),说明这个CA是可信托的,可以保证证书不假。然后,再进一步判定服务器证书中的信息与当前正在访问的网站(域名等)同等,那么browser就以为服务端是可信的,并从服务器证书中取得服务器公钥,用于后续流程。不然,browser将提示用户,根据用户的选择,决定是否继续。 客户端是否可以或许信托这个站点的证书,首先取决于客户端程序是否导入了证书颁发者的根证书。

2、协商会话密钥。客户端在认证完服务器,得到服务器的公钥之后,使用该公钥与服务器进行加密通讯,协商出两个会话密钥,分别是用于加密客户端往服务端发送数据的客户端会话密钥,用于加密服务端往客户端发送数据的服务端会话密钥。在已有服务器公钥,可以加密通讯的条件下,还要协商两个对称密钥的缘故,是由于非对称加密相对庞杂度更高,在数据传输過逞中,使用对称加密,可以节流盘算资源。别的,会话密钥是随机天生,每次协商都市有不一样的结果,以是安全性也比较高。

3、加密通讯。此时客户端服务器两边都有了本次通讯的会话密钥,之后传输的全部Http数据,都通过会话密钥加密。这样网路上的别的用户,将很难盗取和窜改客户端和服务端之间传输的数据,从而保证了数据的私密性和完备性。

客户端是否可以或许信托这个站点的证书,首先取决于客户端程序是否导入了证书颁发者的根证书。
服务器找CA签发证书,以及客户端辨认证书的過逞(加密机找CA签证书基本也是这个流程,只不外两台加密机通讯,两台都要签证书)
IEbrowser在验证证书的时间重要从下面三个方面观察,只要有任何一个不满意都将给出告诫
  1. 证书的颁发者是否在“根受信托的证书颁发机构列表”中
  2. 证书是否逾期
  3. 证书的持有者是否和访问的网站同等

这会儿我恰好在装Fiddler。默认Fiddler不对https traffic加密,假如勾选,就会弹出如下对话框,大意是:Fiddler会在https流量收发两边中间,类似代理的角色,为了参与https通讯,Fiddler自己也要有一个证书,然后这个证书由一个CA颁发,如今这个CA的根证书需要导入windows,用户需要让windows信托这个CA。

点击yes

之后是windows的告诫:由于在往系统里加一个新的CA根证书,windows并不确定这个根证书是否是真的,以是问你(根证书责任重大,选择相信根证书意味着相信这个CA的所有操作……))


【实例2】加密机

个人明白,大概有错。欢迎指正~

加密机A和加密机B双向通讯,没有绝对的客户端和服务端之分。要么更正确地说,每台加密机既是服务端,需要找CA给自己签个签证书;也是客户端,需要提前导入CA根证书,用于辨认收到的证书是否是可靠CA签发的(比对收到证书的根证书是否在可靠CA列表中)。CA签发证书的過逞,就是对【包括发送方公钥在内的发送方信息】进行加密(用CA加密算法和CA私钥)。因此签出来的证书,在吸收方可以被解密得到【包括发送方公钥在内的发送方信息】(用CA解密算法和CA公钥)。

别的,A需要导入B的证书,B需要导入A的证书。

上述预备工作(初始化)完成后,A和B首先创建连接(不涉及应用数据,只是协商同等创建一条加密隧道),实在就是A需要验证如今与我通讯的另一端、证书里天生的B,是不是真正的B。这个就依赖B发送自己的证书给A,A收到后首先确认这个证书颁发CA是可靠的(依据CA的根在自己的可靠根列表中),说明证书可信,再从对质书进行解密(CA的公钥+CA解密算法),得到【包括B的公钥在内的B的信息】,据此证实对端就是真正的B,并拿到了B真正的公钥,验证完成。同理,B也要验证对端确实是A,就不再赘述。

相互验证完成后,A与B的链接创建,等候真正的数据收发。之后的加解密,应该就是加密机自己的算法和秘钥了,硬件上是由加密卡完成,加密卡也是加密机最值钱最焦点的部件……



(加密机部分纯属个人明白,欢迎指正。偶然间我会再带着这个思绪去阅读加密机的说明书……)



参考:

数字署名是什么? - 阮一峰的网络日记 白话Https - 程序员赵鑫 - 博客园​www.cnblogs.com 浅谈https\ssl\数字证书 - P_Chou - 博客园​www.cnblogs.com 浅谈https\ssl\数字证书 - P_Chou - 博客园

数字署名是公钥底子布局的底子部分。当我们说PKI时,一样平常想到的是数字证书,证书颁发机构(CA),银行使用的Key,以及SSL通讯等等。

数字证书,一样平常都是成对存在的,包含证书的公钥,和证书对应的私钥,公钥本身有肯定的身份标识功能(!如ssl证书中的域名信息,邮件客户端证书的邮箱地点等),对于数字证书的应用比较广泛,但其基本原理简单来说就是公钥用来加密,私钥用来解密。私钥用来署名,公钥用来验证署名。

那么,在我们理解数字署名的技能原理之前,我们先要明白一个和数字署名密切相关的算法:Hash算法。

hash算法是一种散列(密码杂凑)算法。简单来说这个算法有几个很明显的特性:

1.易压缩性,可以很轻易的将任何长度的数据映射到固定长度的输出。

2.单向性,它是一种单向密码体制,根据源数据盘算一个哈希值很轻易,但是要根据盘算出的结果得出源数据是不大概的。

3.高敏捷性,就是对于输入数据的变革非常敏捷,纵然很小的变革都市输出差别性很大的结果。

4.抗碰撞性,对于差别的数据块,其hash值相同的大概性极小;对于一个指定的数据块,找到和它hash值相同的数据块极为困难。

由于具有这些特性,以是它非常合适用来做数据完备性和文件完备性的校验。现在应用较为广泛的哈希算法重要有sha1,sha256,sha384等,而我们国密与之相对应的是SM3算法,其安全性也是递增的。几年前Google就对SHA-1碰撞试验,就是为了验证其安全性。如今随着科技的飞速的发展和盘算本领的提高,sha1也即将要退出历史舞台。

一、工作原理:创建数字署名

如今,让我们渐渐理解一下数字署名的過逞:

1、将要署名的文件进行hash盘算。

2、用私钥将文件的hash值进行署名。

3、除了署名外,还可以添加时间戳以指示署名时间。

这个就是数字署名的重要過逞,总的来说就是先对文档进行哈希处置,然后署名者用自己的私钥对文件天生的哈希值进行署名,使用时将原文件和署名数据一起发送。

值得留意的是,数字署名并没有对整个文件进行署名,而是对文件的hash值进行了署名。这样的不但节省了资源并且进步了服从。

好的,接下来我们讨论一下怎样读取和认证署名。

二、工作原理:阅读数字署名

我们已经知道了创建数字署名的過逞,随着要来进行数字署名验证。重要過逞有以下步骤:

1、将原文件进行hash盘算得到hash值。

2、将署名的公钥从署名数据中盘算出署名数据中的hash值。

3、将步骤1中得到的hash值和步骤2得到的hash值进行对比,假如对比结果同等则验证通过,反之验证失败。

三、为什么我们要对全部内容进行数字署名?(数字署名的优势)

防伪造:数字署名中的私钥具有唯一性,除署名者之外都不能伪造署名,并防备被冒充。

完备性:由于数字署名中包含hash算法,对署名文档的任何未经授权的修改将立刻被显见。

身份标识:证书颁发机构可以对质书的持有者的身份进行辨认和验证,可信的CA机构签发的证书可以用于做身份标识。

时间戳:知道文档签订的时间是很重要的,数字署名可以盖上指示创建署名时间的时间戳。

防狡辩:数字署名不但可以成为身份辨认的依据,同时它也是署名者进行署名操作的有用证据,防备署名方对其产生的行为进行狡辩。

除了要点之外,数字署名的应用会越来越广泛,现在连电子发票和电子条约都!参加了数字署名的应用行列,以是它的重要性可以预见。

原文链接:https://blog.csdn.net/weixin_41838363/div/details/97890376

数字署名的全過逞分两大部分,即署名与验证。
一侧为署名,一侧为验证過逞。

发方将原文用哈希算法求得数字摘要,用署名私钥对数字摘要加密得数字署名,发方将原文与数字署名一起发送给担当方;
收方验证署名,即用发方公钥解密数字署名,得出数字摘要;收方将原文接纳同样哈希算法又得一新的数字摘要,将两个数字摘要进行比较,假如二者匹配,说明经数字署名的电子文件传输成功

1、数字署名的署名過逞
数字署名的操作過逞需要有发方的署名数字证书的私钥及其验证公钥。 详细過逞如下:首先是天生被署名的电子文件(《电子署名法》中称数据电文),然后对电子文件用哈希算法做数字摘要,再对数字摘要用署名私钥做非对称加密,即做数字署名;之后是将以上的署名和电子文件原文以及署名证书的公钥加在一起进行封装,形成署名结果发送给收方,待收方验证。

2、数字署名的验证過逞

吸收方收到发方的署名结果后进行署名验证,其详细操作過逞如下: 吸收方收到数字署名的结果,此中包括数字署名、电子原文和发方公钥,即待验证的数据。吸收方进行署名验证。验证過逞是:吸收方首先用发方公钥解密数字署名,导出数字摘要,并对电子文件原文做同样哈希算法得出一个新的数字摘要,将两个摘要的哈希值进行结果比较,相同署名得到验证,不然无效。这就做到了《电子署名法》中所要求的对署名不能窜改,对签订的内容和情势也不能窜改的要求。

3、数字署名的实现方法
基本原理是将原文用对称密钥加密传输,而将对称密钥用收方公钥加密发送给对方。收方收到电子信封,用自己的私钥解密信封,取出对称密钥解密得原文。

其具体過逞如下:

(1)发方A将原文信息进行哈希运算,得一哈希值即数字摘要MD;

(2)发方A用自己的私钥PVA,接纳非对称RSA算法,对数字摘要MD进行加密,即得数字署名DS;

(3)发方A用对称算法DES的对称密钥SK对原文信息、数字署名SD及发方A证书的公钥PBA接纳对称算法加密,得加密信息E;
(4)发方用收方B的公钥PBB,接纳RSA算法对对称密钥SK加密,形成数字信封DE,就似乎将对称密钥SK装到了一个用收方公钥加密的信封里;
(5)发方A将加密信息E和数字信封DE一起发送给收方B;

========
(6)收方B担当到数字信封DE后,首先用自己的私钥PVB解密数字信封,取出对称密钥SK;
(7)收方B用对称密钥SK通过DES算法解密加密信息E,还原出原文信息、数字署名SD及发方A证书的公钥PBA;
(8)收方B验证数字署名,先用发方A的公钥解密数字署名得数字摘要MD;
(9)收方B同时将原文信息用同样的哈希运算,求得一个新的数字摘要MD;
(10)将两个数字摘要MD和MD进行比较,验证原文是否被修改。假如二者相称,说明数据没有被窜改,是保密传输的,署名是真实的;不然拒绝该署名。这样就做到了敏感信息在数字署名的传输中不被窜改,未经认证和授权的人,看不见原数据,起到了在数字署名传输中对敏感数据的保密作用。

原文链接: https://www.cnblogs.com/coolYuan/p/8658737.html

将原文进行哈希盘算

1)A----------------------------------------------------------------------------->哈希值(即数字摘要MD)

A的私钥对数字摘要进行加密

2)A--------------------------------------------------------------------------->数字署名(DS)

使用对称密钥对原文、数字署名、A的公钥进行加密

3)A------------------------------------------------------------------------------->加密信息

使用B的公钥对对称密钥进行加密

4)A------------------------------------------------------------------------------>数字信封(DE)

5)A------------->将加密信息和数字信封发送给B

用B的私钥解密数字信封

6)B----------------------------------------------------------------------------->对称密钥

用对称密钥解密加密信息

7)B----------------------------------------------------------------------------->原文、数字署名、A的公钥

用A的公钥解密数字署名

8)B------------------------------------------------------------------------------>哈希值(即数字摘要MD)

使用相同的哈希算法(摘要算法)对原文进行哈希运算

9)B------------------------------------------------------------------------------>新的哈希值

对比两次哈希值

10)B----------------------------------------------------------------------------->相同没有被修改,保密传输,署名真实

本文网址: http://www.v4ad.com/d/2021020182220_9142_593980913/home