1、首先总结一下数字签名的使用规则和相关流程
讲解比较详细的网络日志可以参考：以及，我这里只做一些自己的总结。
一般来说现在的加密领域或者是认证体系中，都是在使用双秘钥：公钥和私钥，其中公钥用来加密信息，私钥用来数字签名。任何人都可以生成自己的（公钥，私钥）对，所以为了防止有人散布伪造的公钥骗取信任，就需要一个可靠的第三方机构来生成经过认证的（公钥，私钥）对。
私钥是本人所持有的，不对外公布，公钥是公布给他人的。一对密钥，使用一个加密，必定可以使用另一个进行解密。
一般情况下，数字签名以及验证的流程为：
首先对于要传输的原文，使用HASH计算(一般是SHA1或SHA2)，可以得到原文摘要，然后本人使用私钥将原文摘要进行加密，此密文即为传输过程中的签名；
接收者收到传输数据后，需要对内容进行验证，查看内容是否为原文，是否被篡改，使用公钥对签名进行解密，得到原文摘要，然后自己在本地也对取得的当前原文进行HASH计算，得到当前原文的摘要，将解密得到的摘要与自己计算得到的摘要进行比对，查看是否一致即可验证。
以上为本人---&接收者的过程，反过来接收者---&本人的过程与此相反，即使用公钥进行加密的过程。
需要注意两点：
1、整个过程中是对原始为篡改原文的摘要进行加密和解密，本地都会进行取得数据的文件摘要的计算，并且与解密出来的摘要进行比对后得出验证结论。
2、当需要验证的文件多了，就需要保存非常多的公钥，就无法管理了，并且本地保存的公钥有可能被篡改替换。为了解决这一问题就需要一个统一的***管理机构来管理所有需要发送数据方的公钥，对公钥进行认证和加密。这个机构也就是我们常说的CA。认证加密后的公钥，即是***，又称为CA***，***中包含了很多信息，最重要的是申请者的公钥。
这样就对于整个过程又添加了一步包装，申请者使用***发送数据时，用自己的私钥生成签名，将签名、 ***和发送内容一起发给对方，对方拿到了***后，需要对***解密以获取到***中发送方的公钥，解密需要用到CA机构的”统一密钥对“中的公钥，这个公钥也就是我们常说的CA根***，通常需要我们到***颁发机构去下载并***到相应的收取数据的客户端，如浏览器上面。这个公钥只需要***一次。有了这个公钥之后，就可 以解密***，拿到发送方的公钥，然后解密发送方发过来的签名，获取摘要，重新计算摘要，作对比，以验证数据内容的完整性。
验证签名的是否有效，通常是先算“摘要”, 再以摘要和公钥作为输入，调用验证算法来验证（verify）签名是否有效。而不是先验证签名（即题主所说的公钥解密），再算摘要来比对。
你只要想：既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密；同理，既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。
2、HTTPS协议实例
此协议主要是用于网页的加密传输，浏览器向服务器发出访问请求，该请求是以https协议来进行的，那么服务器在接收到请求后就使用私钥加密网页，连同自己本身的数字***一起发送给浏览器客户端，而浏览器的"***管理器"中有"受信任的根***颁发机构"列表，客户端会根据这张列表，查看解开数字***的公钥是否在列表之内。
当***可能被冒用，浏览器会发出警告，或者如果这张数字***不是由受信任的机构颁发的，浏览器会发出另一种警告。
如果数字***是可靠的，客户端就可以使用***中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。
3、进阶总结以及若干问题
综合上面的过程，需要考虑一下，数字签名的伪造问题，参考
1. 原文被篡改&
　　　　肯定是能检验出来的，直接公钥解密数字签名取得哈希值，对比原文的哈希即可验证。
2. 数字签名被篡改
　　　　这也肯定不可能，公钥解密被篡改的数字签名后得到的哈希值（因为加解密算法是公开的，应该能找到一种办法做出一种假的（至上看上去）哈希值）和原文的哈希也对不上
3. 两者皆被篡改
　　　　公钥解密被篡改后的数字签名后得到了假的哈希值，然后用彩虹表搞出原文，这时候，原文的哈希和假哈希一样了，理论上可行，但可能性不大！
理论上来说，有下面两种典型的攻击：1. 找与“旧”原文摘要值相同的原文，等价于攻击hash算法，找出碰撞。如使用题主提到的用彩虹表或者其他的手段。2. 直接伪造数字签名。
4、哈希碰撞来伪造数字***
1中的相关描述可以用一幅流程图来展示：
其中一个重点算法过程就是哈希运算，而其他的加密解密都是使用固定好的数据来进行，如果要对数字签名进行伪造，这里哈希运算的过程是第一个可以进行利用的。
获得签名***一般有几种途径：
1、***颁发机构购买***（获得的是原始真实***）
2、窃取CA的私钥（就可以自行添加指定的***对，就相当于自己是认证机构，可以为所欲为了，但这个是非常非常困难的）
3、伪造一个同可信***具有相同哈希值的***（随着硬件性能的增强，此方法已经是可行的了）
伪造的思路就是：
就是你找到一个跟签名消息具有相同哈希值的消息，你就可以替换原有的消息，而最终验证签名也不会出错。这就可以用来伪造任何人签署他们本没有签署过的消息。
&其实说到这里这个议题就变成了密码破解了，比如MD5密码破解等等。
&5、密码函数碰撞
方法是使用运用选择前缀碰撞法，找出两个具有相同MD5值的文件，2008年，一些研究人员(包括Marc Stevens和Alex Sotirov)使用选择前缀碰撞法。其POC在2008年的混沌通信大会上面进行了展示，而为了得到这个POC研究人员也仅花了几天的计算时间。
2012年，一个名为Flame的恶意软件被发现。Flame能通过劫持微软Windows Update服务来感染计算机。当时，Windows Update验证更新文件正是通过验证文件基于MD5数字签名得到的数字***。Flame的作者伪造了微软的数字***。通过对，发现作者很有可能就是基于选择前缀碰撞技术伪造的***。
阅读(...) 评论()基于数字签名的双向用户认证方案double-directio
简要介绍了RSA 算法及Feige-Fiat-Shamir 数字签名协议，利用这两种算法构造了一种交互式用户认证方案，并且在此基础上实现了双向认证。该方案充分体现了RSA 算法的安全性和Feige-Fiat-Shamir 算法的高效性，与只利用其中一种实现用户认证比较，增强了安全性，具有良好的应用价值和前景。关键词：RSA、Feige-Fiat-Shamir、数字签名、双向身份认证Abstract: This paper introduces RSA arithmetic and Feige-Fiat-Shami digital agreement. We make use of these two kinds of arithmetic to construct an mutual user attestation project., on which we realize double-direction user authentacation. This project fully embodies the safety of RSA arithmetic and the efficiency of Feige-Fiat-Shamir arithmetic. Compared to the use of the only one arithmetic, it strengthens the safety so that it possesses good application value and foreground.Key word: RSA， Feige-Fiat-Sdouble-direction user authentacation
基于数字签名的双向用户认证方案double-directio下载
下载资料需要，并消耗一定积分。
下载此资料的人还喜欢：
技术交流、我要发言！ 发表评论可获取积分！ 请遵守相关规定。
本周热点资料
电子资料热门词
上传者其它资料
网络协议论文下载排行数字签名是什么？ - justjavac(迷渡) - ITeye博客
博客分类：
今天，我读到一篇好文章。
它用图片通俗易懂地解释了，"数字签名"（digital signature）和"数字***"（digital certificate）到底是什么。
我对这些问题的理解，一直是模模糊糊的，很多细节搞不清楚。读完这篇文章后，发现思路一下子就理清了。为了加深记忆，我把文字和图片都翻译出来了。
====================================================
数字签名是什么？
作者：David Youd
翻译：阮一峰
原文网址：
鲍勃有两把钥匙，一把是公钥，另一把是私钥。
鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。
苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。
鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。
鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。
然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。
鲍勃将这个签名，附在信件下面，一起发给苏珊。
苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。
苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。
复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。
后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"***中心"（certificate authority，简称CA），为公钥做认证。***中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字***"（Digital Certificate）。
鲍勃拿到数字***以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字***就行了。
苏珊收信后，用CA的公钥解开数字***，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。
下面，我们看一个应用"数字***"的实例：https协议。这个协议主要用于网页加密。
首先，客户端向服务器发出加密请求。
服务器用自己的私钥加密网页以后，连同本身的数字***，一起发送给客户端。
客户端（浏览器）的"***管理器"，有"受信任的根***颁发机构"列表。客户端会根据这张列表，查看解开数字***的公钥是否在列表之内。
如果数字***记载的网址，与你正在浏览的网址不一致，就说明这张***可能被冒用，浏览器会发出警告。
如果这张数字***不是由受信任的机构颁发的，浏览器会发出另一种警告。
如果数字***是可靠的，客户端就可以使用***中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。
浏览 49722
ijlkdwg 写道真遗憾！老外的那个文章也是错误的。加密的对应过程是解密，签名对应的过程是验证。这俩个是完全不一样的！！！加密（非对称加密）是公钥加密，私钥解密；签名是私钥签名，公钥验证。这俩个东西本来是完全不同体系的，他们需要的key的内容也不一样。只不过，有的key（比如rsa），可以俩边都玩的转。或者说，非对称加密和签名，都有rsa算法，他们可以公用key。另外，ssl握手里面是由client产生一个secret key，做后面的对称加密传输，这个没错。但是，这个是跟客户端有没有***是没关系的！***，是用来验证你的身份的，无论是客户端或者服务器端的。去看看bc的unit tests就知道了。由于A公钥由于对外开放，B可以冒充C向A发送信息！又有什么用呢。对于你这样阅读障碍的人，真的不适合做技术。我都说了，用对方的公钥加密，对方的私钥解密；用自己的私钥签名，公钥来验证。B没有c的私钥，不能搞c的签名，怎么冒充c？
真遗憾！老外的那个文章也是错误的。加密的对应过程是解密，签名对应的过程是验证。这俩个是完全不一样的！！！加密（非对称加密）是公钥加密，私钥解密；签名是私钥签名，公钥验证。这俩个东西本来是完全不同体系的，他们需要的key的内容也不一样。只不过，有的key（比如rsa），可以俩边都玩的转。或者说，非对称加密和签名，都有rsa算法，他们可以公用key。另外，ssl握手里面是由client产生一个secret key，做后面的对称加密传输，这个没错。但是，这个是跟客户端有没有***是没关系的！***，是用来验证你的身份的，无论是客户端或者服务器端的。去看看bc的unit tests就知道了。由于A公钥由于对外开放，B可以冒充C向A发送信息！又有什么用呢。
zxylx 写道那服务器发回给客户端的信息岂不是不安全的。因为很多人都会CA的公钥，被其它人窃取后照样可以解析出来。你说的是16步吧，服务器发送的内容，就是给客户端看到。不存在安全不安全。任何人都可以看到，即使没有密钥。数字签名用到了加密的技术，但是数字签名和加密有本质的区别。数字签名是为了确保信息没有伪造，也就是说，我给你发送了信息，我对信息签名了，然后你就可以确定这个信息确实你我发送的，而不是张三或者李四发送的。信息本身不需要加密，我发送给你一个号码“”，是明文发送到，我对他签名，这样你接收到我的信息，可以确定1、信息是我发送到，2、信息在传送的过程中没有被第三个人修改过。这样签名档目的就达到了。数字签名和咱普通的在合同上签字是一样的。服务器端的CA可以让客户端对服务端身份进行认证，但服务器端和客户端之间的安全通讯还需要有个握手过程，对于一般的客户端没有***的情况，可以由客户端随机产生个安全密钥作为本次会话的对称加密密钥，客户端可以用服务器端的公钥加密发送给服务器端，服务器端用它的私钥解密就得到了这个安全密钥，这样客户端和服务器端之后的通讯就可以用这个安全密钥来加密了。
daojin 写道讲得比较清楚。也就是说这个加密食物链的终点就是***中心。也就是CA。
但是我说的是安全问题：CA的安全问题
1.如果通过CA认证的就被认为是可信任的***。CA又是怎么区分哪个***是可靠和不可靠的呢？它即使是认为可靠了！谁又能保证服务器的数字***不会被窃走呢？发送的过程当中，谁又能保证不被别的所谓的“被信任的***”替换呢？
目前的情况是，一个CA根本无法确定谁是可信任的！！即使确定了，也无法保证就不会出问题，不然黑客就没得混了。
2.所以说，用数字***来加密显然不可靠。不能保证银行账号就是安全的。
所以，要用USB这种移动式***。
CA只是认证的一部分，签名也很重要，联合起来才能认证。
服务器的***被偷了也没用的，因为***是必须绑定域名的，你用钓鱼的办法用不了别人的***。
绝对的安全是不存在的：***被偷+DNS解析被改+钓鱼....肯定可以破解
但你用USB一样可能被偷，密码一样可能泄露.....
你说的没错。CA就像一个仲裁者一样，比如说他给中国银行发***，他也给我的私人网站发***。我的私人网站本身就是一个干坏事的钓鱼网站。电脑中毒，DNS直接重定向到我的私人网站。这我不就得逞了。
讲得比较清楚。也就是说这个加密食物链的终点就是***中心。也就是CA。但是我说的是安全问题：CA的安全问题1.如果通过CA认证的就被认为是可信任的***。CA又是怎么区分哪个***是可靠和不可靠的呢？它即使是认为可靠了！谁又能保证服务器的数字***不会被窃走呢？发送的过程当中，谁又能保证不被别的所谓的“被信任的***”替换呢？目前的情况是，一个CA根本无法确定谁是可信任的！！即使确定了，也无法保证就不会出问题，不然黑客就没得混了。2.所以说，用数字***来加密显然不可靠。不能保证银行账号就是安全的。所以，要用USB这种移动式***。CA只是认证的一部分，签名也很重要，联合起来才能认证。服务器的***被偷了也没用的，因为***是必须绑定域名的，你用钓鱼的办法用不了别人的***。绝对的安全是不存在的：***被偷+DNS解析被改+钓鱼....肯定可以破解但你用USB一样可能被偷，密码一样可能泄露.....
想问你几个问题：1.鲍勃给苏珊写的信是不是帕蒂和道格用鲍勃给的公钥也能打开？2.第11步，“对鲍勃的公钥和一些相关信息一起加密”一些相关信息是指什么？3.第13步，“用CA的公钥解开数字***，就可以拿到鲍勃真实的公钥了”苏珊用的CA的公钥只能打开鲍勃发来的***吗，怎么证明解开***拿到的公钥就是鲍勃的？1.帕蒂和道格都可以打开（如果他们截获了信件），所以他俩可以进行中间人攻击、会话劫持。。所以呢，CA就产生了。
yingwuhahahaha 写道引用苏珊收信后，用CA的公钥解开数字***，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。***里面存了引用鲍勃的信息么?一般解密后的***是什么结构呢?数字***文件格式（cer和pfx），一般cer比较常用，扩展名是.cer。java中的keytool 工具可以管理***这是SSL的数据结构参考：　Certificate***　　--Version 版本　　--Serial Number 序列号　　--Algorithm ID 算法标识　　--Issuer 颁发者　　--Validity 有效期　　&Not Before 有效起始日期　　&Not After 有效终止日期　　--Subject 使用者　　--Subject Public Key Info 使用者公钥信息　　-- Public Key Algorithm 公钥算法　　--Subject Public Key 公钥　　--Issuer Unique Identifier (Optional) 颁发者唯一标识　　--Subject Unique Identifier (Optional) 使用者唯一标识　　--Extensions (Optional) 扩展　　...　　Certificate Signature Algorithm ***签名算法　　Certificate Signature ***签名其实X.509 结构也差不多一样&
引用苏珊收信后，用CA的公钥解开数字***，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。***里面存了引用鲍勃的信息么?一般解密后的***是什么结构呢?数字***文件格式（cer和pfx），一般cer比较常用，扩展名是.cer。java中的keytool 工具可以管理***参考：
justjavac 写道zxylx 写道那服务器发回给客户端的信息岂不是不安全的。因为很多人都会CA的公钥，被其它人窃取后照样可以解析出来。你说的是16步吧，服务器发送的内容，就是给客户端看到。不存在安全不安全。任何人都可以看到，即使没有密钥。数字签名用到了加密的技术，但是数字签名和加密有本质的区别。数字签名是为了确保信息没有伪造，也就是说，我给你发送了信息，我对信息签名了，然后你就可以确定这个信息确实你我发送的，而不是张三或者李四发送的。信息本身不需要加密，我发送给你一个号码“”，是明文发送到，我对他签名，这样你接收到我的信息，可以确定1、信息是我发送到，2、信息在传送的过程中没有被第三个人修改过。这样签名档目的就达到了。数字签名和咱普通的在合同上签字是一样的。我记得HTTPS本身是可以对服务器发来的信息加密的， 也就是不会明文地传送“”。 HTTPS报文中的任何东西都被加密，包括所有报头和荷载。除了可能的CCA（参见限制小节）之外，一个攻击者所能知道的只有在两者之间有一连接这一事实。参考维基百科：PS：一个到某网站的HTTPS连接可被信任，当且仅当：用户相信他们的浏览器正确实现了HTTPS且***了正确的***颁发机构；用户相信***颁发机构仅信任合法的网站；被访问的网站提供了一个有效的***，意即，它是由一个被信任的***颁发机构签发的（大部分浏览器会对无效的***发出警告）；该***正确地验证了被访问的网站（如，访问https://example时收到了给“Example Inc.”而不是其它组织的***）；或者互联网上相关的节点是值得信任的，或者用户相信本协议的加密层（TLS或SSL）不能被窃（和谐）听者破坏。
苏珊收信后，用CA的公钥解开数字***，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。***里面存了引用鲍勃的信息么?一般解密后的***是什么结构呢?
& 上一页 1
浏览: 4462395 次
来自: 天津
浏览量：18047
初步算了一下，目前最最精简的Win98版是5M，他5个小时多敲 ...
。。似乎重点没说NIO啊，前面基础只是铺垫的很好的，可是我要的 ...
spring mvc demo教程源代码下载，地址：http: ...
其实最主要的是能学好《操作系统》、《算法》、《数据结构》这三本 ...