2.6 数字签名
在文件上手写签名长期以来被用作作者身份的证明，或至少同意文件的内容。签名为什么会如此引人注目呢？[1392]
（1）签名是可信的。签名使文件的接收者相信签名者是慎重地在文件上签字的。
（2）签名不可伪造。签名证明是签字者而不是其他人慎重地在文件上签字。
（3）签名不可重用。签名是文件的一部分，不法之徒不可能将签名移到不同的文件上。
（4）签名的文件是不可改变的。在文件签名后，文件不能改变。
（1）签名是不可抵赖的。签名和文件是物理的东西。签名者事后不能声称他没有签过名。
在现实生活中，关于签名的这些陈述没有一个是完全真实的。签名能够被伪造，签名能够从文章中盗用移到另一篇文章中，文件在签名后能够被改变。然而，我们之所以愿意与这些问题纠缠在一起，因为欺骗是困难的，并且还要冒被发现的危险。
我们或许愿在计算机上做这种事情，但还存在一些问题。首先计算机文件易于复制。即使某人的签名难以伪造（例如，手写签名的图形），但是从一个文件到另一个文件剪裁和粘贴有效的签名都是很容易的。这种签名并没有什么意义；其次文件在签名后也易于修改，并且不会留下任何修改的痕迹HHHH一一H一一一砖瓦。
使用对称密码系统和仲裁者的文件签名
Alice想对数字消息签名，并送给Bob。在Trent和对称密码系统的帮助下，她能做到。
Trent是一个有权的、值得依赖的仲裁者。他能同时与Alice和Bob（也可以是其他想对数据文件签名的任何人）通信。他和Alice共享秘密密钥KA，和Bob共享另一个不同的秘密密钥KB。这些密钥在协议开始前就早已建好，并且为了多次签名可多次重复使用。
（1）Alice用KA加密她准备发送给Bob的信息，并把它传送给Trent。
（2）Trent用KA解密信息。
（3）Trent把这个解密信息和他收到Alice信息的声明，一起用KB加密。
（4）Trent把加密的信息包传给Bob。
（5）Bob用KB解密信息包，他就能读Alice所发的信息和Trent的证书，证明信息来自Alice。
Trent怎么知道信息是从Alice而不是从其他人冒名顶替者那里来的呢？从信息的加密推断出来。由于只有他和Alice共享他们两人的秘密密钥，所以只有Alice能用这个密钥加密信息。
这和文件签名一样好吗？让我们看看我们需要的特点：
（1）这个签名是可信的，Trent是可信的仲裁者，并且知道消息是从Alice那里来的，Trent的证书对Bob起着证明的作用。
（2）这个签名是不可伪造的。只有Alice（和Trent，但每个人都相信他）知道KA，因此只有Alice才能把用KA加密的信息传给Trent。如果有人冒充Alice，Trent在第（2）步马上就会察觉，并且不会去证明它的可靠性。
（3）这个签名是不能重新使用的。如果Bob想把Trent的证书附到另一个信息上，Alice可能就会大叫受骗了。仲裁者（可能是Trent或者可存取同一信息的完全不同的仲裁者）就会要求Bob同时提供信息和Alice加密后的信息，然后仲裁者就用KA加密信息，他 马上就会发现它与Bob提供的加密信息不相同。很显然，Bob由于不知道KA，他不可能提供加密信息使它与用KA加密的信息相符。
（4）签名文件是不能改变的。Bob想在接收后改变文件，Trent就可用刚才描述的同样办法证明Bob的愚蠢行为。
（5）签名是不能抵赖的，即使Alice以后声称她没有发信息给Bob，Trent的证书会说明不是这样。记住：Trent是每个人都信任的，他说的都是正确的。
如果Bob想把Alice签名的文件给Carol阅读，他不能把自己的秘密密钥交给她，他还得通过Trent：
（1）Bob把信息和Trent关于信息是来自Alice的声明用KB加密，然后送回给Trent。
（2）Trent用KB解密信息包。
（3）Trent检查他的数据库，并确认原始信息是从Alice那里来的。
（4）Trent用他和Carol共享的密钥KC重新加密信息包，把它送给Carol。
（5）Carol 用KC解密信息包，她就能阅读信息和Trent证实信息来自Alice的证书。
这些协议是可行的，但对Trent来说是非常耗时的。他不得不整天加密、解密信息，在彼此想发送签名文件的每一对人之间充当中间人。他必须备有数据库信息（虽然可以通过把发送者加密的信息的拷贝发送给接收者来避免）。在任何通信系统中，即使他是毫无思想的软件程序，他都是通信瓶颈。
更困难的是产生和保持像Trent那样的网络用户都信任的人。Trent必须是完善无缺的，即使他在100万次签名中只犯了一个错误，也将不会有人再信任他。Trent必须是完全安全的，如果他的秘密密钥数据库泄漏了，或有人能修改他的程序代码，所有人的签名可能是完全无用的。一些声称是数年前签名的假文件便可能出现，这将引起混乱，政府可能倒台，混乱状态可能盛行。理论上这种协议或许是可行的，但实际上不能很好运转。
数字签名树
Ralph Merkle提出了一个基于秘密密钥密码的数字签名方案，该方案利用树型结构产生无限多的一次签名[1067，1068]。这个方案的基本思想是在某些公开文档中放入树的根文件，从而鉴别它。根节点对一个信息签名，并鉴别树中的子节点，这些节点的每一个都对信息签名，并对它的子节点鉴别，一直延续下去。
使用公钥密码对文件签名
有几种公钥算法能用作数字签名。在一些算法中，例如RSA（见119.3节），公钥或者私钥都可用作加密。用你的私钥加密文件，你就拥有安全的数字签名。在其它情况下，如DSA（见20.1节），算法便区分开来了¾¾数字签名算法不能用于加密。这种思想首先由Diffie和Hellman[496]提出，并且在其他文章中得到进一步的发展[1282，1382，1024，1283，426]。 文献[1099]对这个领域作了很好的综述。
基本协议是简单的：
（1）Alice用她的私钥对文件加密，从而对文件签名。
（2）Alice将签名的文件传给Bob。
（3）Bob用Alice的公钥解密文件，从而验证签名。
这个协议比以前的算法更好。不需要Trent去签名和验证。他只需要证明Alice的公钥的确是她的）。甚至协议的双方不需要Trent来解决争端；如果Bob不能完成第（3）步，那么他知道签名是无效的。
这个协议也满足我们期待的特征：
（1）签名是可信的。当Bob用Alice的公钥验证信息时，他知道是由Alice签名的。
（2）签名是不可伪造的。只有Alice知道她的私钥。
（3）签名是不可重用的。签名是文件的函数，并且不可能转换成另外的文件。
（4）被签名的文件是不可改变的。如果文件有任何改变，文件就不可能用Alice的公钥验证。
（5）签名是不可抵赖的。Bob不用Alice的帮助就能验证Alice的签名。
文件签名和时间标记
实际上，Bob在某些情况下可以欺骗Alice。他可能把签名和文件一起重用。如果Alice在合同上签名，这种重用不会有什么问题（同一个合同的另一个拷贝是什么？）。但如果Alice在一张数字支票上签名，那样做就令人兴奋了。
假若Alice交给Bob＄100的签名数字支票，Bob把支票拿到银行去验证签名，然后把钱从Alice的帐户上转到自己的帐上。Bob是一个无耻之徒，他保存了数字支票的副本。过了一星期，他又把数字支票拿到银行（或可能是另一个银行），银行验证数字支票并把钱转到他的帐上。只要Alice不去对支票本清帐，Bob就可以一直干下去。
因此，数字签名经常包括时间标记。对日期和时间的签名附在信息中，并跟信息中的其他部分一起签名。银行将时间标记存贮在数据库中。现在，当Bob第二次想支取Alice的支票时，银行就要检查时间标记是否和数据库中的一样。由于银行已经从Alice的支票上支付了这一时间标记的支票，于是就叫警察。这样一来Bob就要在Leavenworth监狱中度过15个春秋去研读密码协议的书籍了。
用公钥密码和单向Hash函数对文件签名
在实际的实现过程中，采用公钥密码算法对长文件签名效率太低。为了节约时间，数字签名协议经常和单向Hash函数一起使用。Alice并不对整个文件签名，只对文件的Hash值签名。在这个协议中，单向Hash函数和数字签名算法是事先就协商好了的。
（1）Alice产生文件的单向Hash值。
（2）Alice用她的私钥对Hash加密，凭此表示对文件签名。
（3）Alice将文件和Hash签名送给Bob。
（4）Bob用Alice发送的文件产生文件的单向Hash值，然后用数字签名算法对hash值运算，同时用Alice的公钥对签名的Hash解密。如果签名的hash值与自己产生的Hash值匹配，签名就是有效的。
计算速度大大地提高了，并且两个不同的文件有相同的160比特Hash值的概率为1/2160。因此，使用Hash函数的签名和文件签名一样安全。如果使用非单向Hash函数，可能很容易产生多个文件使它们的hash值相同，这样对一特定的文件签名就可复制用于对大量的文件签名。
这个协议还有其它好处。首先，签名和文件可以分开保存。其次，接收者对文件和签名的存贮量要求大大降低了。档案系统可用这类协议来验证文件的存在而不需保存它们的内容。中央数据库只存贮各个文件的Hash值，根本不需要看文件。用户将文件的Hash值传给数据库，然后数据库对提交的文件加上时间标记并保存。如果以后有人对某文件的存在发生争执，数据库可通过找到文件的Hash 值来解决争端。这里可能牵连到大量的隐秘：Alice可能有某文件的版权，但仍保持文件的秘密。只有当她想证明她的版权时，她才不得不把文件公开（参看4.1节）.