$$ 01 $$

　　自从添加了‘循环冗余校验’后，牛郎织女信件内容的准确度极大提高。

　　但是最近，牛郎突然发现，信件中部分句子，还是有不少7次都没有正确传输的。

　　“难道是我对传输稳定性的预估有误？”牛郎暗自想，“但是这不可能啊。”

　　忽然，牛郎灵机一动：“不会是有人像篡改内容，但是尚不知校验规则，正在探索尝试吧？”

　　“这就危险了，‘循环冗余校验’难度不大，破解只是时间问题。”

　　“既然如此，还需要一种识别数据篡改的方式。”

　　·

　　接下来的几天，牛郎没有与织女联系。

　　牛郎心里清楚，每次联系都是给对方试探的机会，自己没有想好新的校验规则之前，需要尽量减少与织女的沟通。

　　“其实，也不是很难，只要找到一种方式，让全文所有内容参与计算，得出一个校验值就好了。”牛郎自言自语。

　　“但是，全文内容太多了，如果还是之前的笔画方式的话，恐怕误差会比较大。”

　　“同时，还要考虑安全性，算法总是会暴露的，如何在王母知道了算法的情况下，也尽量保证数据安全。”

　　·

　　看来，需要考虑的事情不少，牛郎想各个击破。

　　“首先，是算法上的问题。本质上还是笔画，只是按原来‘循环冗余校验’的方式，王母想要伪造太简单。”

　　“只要替换一句笔画相同的句子，就可以绕过校验了。这很危险，必须让每个字的笔画都参与运算，都会影响结果。”

　　·

　　“如果两句话字数、每个字的笔画数都一样，但是却要表达不同的意思，这很难。这就是新的校验法的核心思想。”

　　·

　　----

　　$$ 02 $$

　　那么问题来了，具体应该怎么办呢？

　　牛郎想，不如先从简单地方式来思考，先把每个字的笔画，都写出来。

　　原本是一封全是文字的信件，每个文字对应的位置替换为笔画数，瞬间变成了一张数字表。

　　“这个数字表看起来很条理，不如把每一列都加起来试试。只是每一句话有长有短，最后的结果取决于最长的一句，这样不太好。”

　　·

　　牛郎重新思考了一下，信件中，最长的句子是80字，以后可能会有更长的句子，这样会失控的。

　　牛郎拿起一张新的纸，按照每行32个字的规则，将整篇信件抄写了一遍。

　　“现在好了，句子再长，由于32个字就会换行，再也不会出现校验值过长的问题了。”

　　·

　　牛郎重新在每个字的位置标好笔画数目，标点符号作为一个字，但笔画记为0画。

　　如此按照列加起来，牛郎得到了32个非常大的数字。

　　“从一定程度上讲，这32个数字，确实可以校验一篇内容的完整性。但这样，还是有点冗长了。”

　　这时候，牛郎又想起了那个魔数7，“不如把每个数字再除以7，取余数，这样就是32个一位数了，应该就方便多了。”

　　·

　　牛郎写下来这32个数字，还是感觉缺少了点什么。总感觉，好像是过于死板了，缺少一种灵动感。

　　突然，牛郎一拍脑门，“明白了！数字还是看起来太乱了，32位数字更是让人一眼就看晕了。”

　　“这样的话，我用12的余数，用12地支表示结果，每8个一组，应该会好很多了。”

　　于是，牛郎重新计算校验值，然后在下方写下了：

　　“子丑寅卯……”

　　·

　　----

　　$$ 03 $$

　　牛郎看着一列一列计算出来的校验值，如此大量的文字，竟然最后的结果只有这么一串文字。

　　取个什么名字好呢？将信件分散为笔画，然后按列来计算，不如就叫做“散列算法”吧。

　　防止篡改的方法确定了，那么，如何避免计算出来的校验值被修改呢？

　　牛郎想了想，既然如此，就把这个校验值放在信件的第一行吧。

　　先发出去校验值，即使被拦截，由于对方不知道信件的整体内容，也是无法进行修改的。

　　·

　　牛郎赶紧给织女写了一封信，描述了这个方法，并约定以后的通信，都用这种方式进行校验。

　　牛郎很开心，自己终于解决了一个大问题。

　　第二天，牛郎收到了织女的回信，内容很简单：“通篇伪造怎么办？”

　　·

　　牛郎一时语塞，想想也是，自己解决了局部篡改问题，只修改部分内容可以被快速发现。

　　但是，王母知道了该机制后，确实无法改一部分，但他们直接把一整篇全伪造，我这还真没办法。

　　甚至，说的极端一点，现在我看到这封信，还真不能肯定，到底是织女写的还是王母写的。

　　这个问题，确实是有点尴尬的。

　　·

　　“看来，需要混入一些只有我和织女才知道的东西，才能保证对方身份的安全性。”牛郎想。

　　“比如，将我和织女初次见面的时间算进去？”

　　接着，牛郎又否定了自己的想法：“现在仅仅基于笔画，方法过于简单，多次通信后，王母可能反推出这个时间。”

　　“看来，要想办法强化这个算法的不可逆性质了。”

　　·

　　----

　　$$ 04 $$

　　牛郎来到桌前，在纸上写出32位的校验值，然后又按照“年月日”的格式，写出了8位时间。

　　也就是说，牛郎需要将原始校验值与见面日期结合，生成一个安全的校验值，同时还要保证，见面日期不可被反推出来。

　　“要保证见面日期的安全性，这还真是有点难度的。”牛郎自言自语道，“因为安全校验值是明文传输的，而原始校验值则可以通过内容计算出来。”

　　·

　　牛郎想着想着，突然手中的笔不小心掉了下来，刚好涂掉了原始校验值的最后两位。

　　牛郎捡起笔，放到桌上，看着纸上留下的痕迹，灵机一动：

　　“对了，只要减少见面日期影响的位数，就很难反推了。如果见面日志只影响这最后两位，神仙也不能能基于它推出原来8位的日期。”

　　·

　　牛郎再次拿起笔，在纸上记下了处理思路：“取原始校验值的最后两位，与见面日期拼成10位，与剩余的30位原始校验值计算出2位尾数，拼回去作为安全校验值。”

　　那么问题来了，具体要怎么算呢？这没什么难点，在没有前人铺垫的情况下，我说啥不就是啥么？

　　牛郎重新看了一眼信件，将被涂掉的最后两位重新写到纸上。

　　“午戌。午是第7位，戌是第11位。那第二行，从第5位开始写这10位，第三行，从第11位开始写这10位内容。”

　　牛郎写好后，将这三列再次按列加起来，得到30位内容。

　　·

　　现在，要想办法将这30位变成2位数，并且要尽量有选择地丢弃一些信息，避免数据被反推。

　　牛郎很随性地想了一个办法：“第一位，将3的倍数位的内容加起来，取除以7的余数。”

　　“第二位，将4的倍数位的内容，加起来，也取7的余数。这样，由于筛选，见面日期总是部分参与运算，从而保证安全性。”

　　牛郎算出了结果，第一位是2，第二位是4，牛郎就在原始校验值的30位后面，补充上了这两位：“2对应‘乙’，4对应‘丁’，这就完整了。”