一、 引言

　　进入数字时代后，我们不得不为电子文档的真实性和原始性的鉴定而苦恼，虽然相应的有了数字签名、身份的安全认证等诸多手段，但对某些特殊行业并不太适合，比如我们在传送电子邮件时希望接收方收到的是从确实是从发送方发出的、并且是发出后未经过任何处理的。这就有两点要求：其一为身份的确认，必须是从发送方发出来的，这方面技术已经比较成熟，可以用数字签名等方式来保证，接收方在验证了数字签名的有效性后即可认为确实是从发送方发来的；第二点要求是该文件在传输过程中不能被经过任何的处理，即该文件的内部结构、内容信息等不能发生任何的改变，

如果发生了变化就应能鉴别出该文件不是最原始的文件，这就需要在发送方独立的根据此文件对该文件的原始性做出判断，数字签名等技术在此就无用武之地了，因为在邮寄中途对文件作改动的破坏者会绕过数字签名，而仅仅对其关心的某段信息进行改动。本文下面就以对BMP位图设置印鉴水印为例对上述问题的解决提供一种思路。

　　 二、 BMP位图的内部结构

　　由于邮件接收方必须根据收到的仅有的一个文件（此处为一幅BMP位图）对其原始性做出判断，那么用来标识该文件的信息只有隐藏在该文件中才能被接收者识别出来，而且该信息不能隐藏到文件的内容信息区中（此处为位图点阵），因为如果这样的话在设置印鉴的同时就已经把原始内容破坏了，文件也就失去了原始性了。因此我们所设置的印鉴水印必须设置到标识文件结构的保留字段中，所以在处理之前有必要对文件的内部结构作些了解。下表就是我们所要研究的对象BMP位图的内部结构：

　　 从上表可以看出，我们设置的印鉴水印只能放在第6--9字节之间的这两段保留字段中。才不会破坏文件的内容和整体结构。

　　 三、用CRC校验码作为印鉴的可靠性能

　　 在网络通讯中经常会用到CRC循环冗余校验码，并广泛的应用于报文的检错。在网络中对报文检错的工作环境同本文的有些类似：都是接收方根据发送方发来的数据来判断这段数据到底是不是同发送方发送时的内容一模一样。我们不妨把发送方发送出来的BMP位图当作一个大报文，对其加上CRC校验，把通常放在帧尾的CRC校验码放到BMP位图的保留字段中，这样接收方只须象网络中的检验报文一样看看校验码的正确与否即可断定出该位图是否被作过处理。

　　 CRC校验码是基于将位串看作是系数为0或1的多项式，一个k位的数据流可以看作是关于x的从k-1阶到0阶的k次多项式的系数序列。采用此编码，发送方和接收方必须事先商定一个生成多项式G(x)，其高位和低位必须是1。要计算m位的帧M(x)的校验和，基本思想是将校验和加在帧的末尾，使这个带校验和的帧的多项式能被G(x)除尽。当接收方收到加有校验和的帧时，用G(x)去除它，如果有余数，则CRC校验错误，只有没有余数的校验才是正确的。具体计算校验和的算法如下：

　　 1． 设G(x)为r阶，在帧末尾附加r个0，将帧扩展到m+r位长。

　　 2． 按模2除法用对应于G(x)的位串去除对应于扩展后的M(x)的位串。

　　 3． 按模2减法从对应于扩展后的M(x)的位串中减去余数，其结果就是要传送的带校验和的帧T(x)了。

　　 我们在使用之前有必要对该校验方法的可靠性能做一下分析，如果内容数据做了改动，正确的T(x)位串变成了T(x)+E(x)。在E(x)中每一位都对应着要转换的一位。如果E(x)中有k个1位，那么就会发生k个单个错误。一旦接收方用G(x)去除，即计算[T(x)+E(x)]/G(x),而T(x)/G(x)=0,所以其结果为E(x)/G(x)。除了是G(x)整倍数的多项式差错检测不到以外，其他错误都可以捕获到。如果E(x)中发生单个位（I 位）错误，若G(x)包括至少I项，就永远也除不尽E(x)，换句话说，所有单个位错误都可以被检测出来。另外，如果集中差错长度为r+1时，而且当集中差错和G(x)一样时，被G(x)除的余数也可能为0。根据集中差错的定义第一位和最后一位必须是1，因此，集中差错是否同G(x)一样取决于其余的r-1位。如果所有的0、1排列情况出现概率均等，那么图片被更改而没有被检出的概率就是1/2^(r-1)。按照现在流行的四种已成为国际标准的多项式：V.41的CRC-CCITT、ANSI的CRC-16以及CRC-12和CRC-32，他们的r值分别为16、16、12、32，漏检的概率在0.00000000002~0.000244之间，这样的概率还是令人满意的。

　　 经过以上的分析，采用CRC循环冗余校验码作为检测BMP位图是否被改动的印鉴水印是可靠、合理的。接下来就通过一段Microsoft Visual C++ 6.0的程序片段来完成对此算法的具体实现。
四、示例程序的设计实现

　　首先我们把本文中最关键的用于产生CRC校验和（余数）的函数CheckOut()的实现部分主要代码做了介绍，其中为了减少运算量、方便编程、将烦琐的多项式长除取余的过程按照前面讲述的CRC算法的运算过程和原理将其预先设定在一个256字节长的数组表CheckTable中，实际运算时只须按索引对其查表即可：

BYTE CCRCDlg::CheckOut(BYTE *byteData, UINT nCount)
{
　 ……
　 static BYTE CheckTable[256]=
　 {
　　 0x00,0x07,0x0e,0x09,0x1c,0x1b,0x12,0x15,0x38,0x3f,
　　 0x36,0x31,0x24,0x23,0x2a,0x2d,0x70,0x77,0x7e,0x79,
　　 0x6c,0x6b,0x62,0x65,0x48,0x4f,0x46,0x41,0x54,0x53,
　　 0x5a,0x5d,0xe0,0xe7,0xee,0xe9,0xfc,0xfb,0xf2,0xf5,
　　 0xd8,0xdf,0xd6,0xd1,0xc4,0xc3,0xca,0xcd,0x90,0x97,
　　 0x9e,0x99,0x8c,0x8b,0x82,0x85,0xa8,0xaf,0xa6,0xa1,
　　 0xb4,0xb3,0xba,0xbd,0xc7,0xc0,0xc9,0xce,0xdb,0xdc,
　　 0xd5,0xd2,0xff,0xf8,0xf1,0xf6,0xe3,0xe4,0xed,0xea,
　　 0xb7,0xb0,0xb9,0xbe,0xab,0xac,0xa5,0xa2,0x8f,0x88,
　　 0x81,0x86