点击直接运行: 112位HotWC3/CRC通用网上演算器V3.01

由于菜农在看雪论坛被群殴，无奈用程序验证菜农“补零”之说。

本来就是一个编程最基础的小问题，菜农编了一辈子程序，

逆向了一辈子，这样的问题根本不需要耗费俺的脑浆。

菜农被群殴之处：http://bbs.pediy.com/showthread.php?t=93968

菜农不想再多解释什么，和给定程序完全一样的结果，只是编程手法

不同，俺考虑的是通用和加密及解密等。

贴图为证：

下面出自：http://bbs.pediy.com/showthread.php?t=94282

菜农支持“非分组CRC32 ”并非主张应用此校验方法。所以升级只有此项。
 
CRC32就是分组32位的CRC冗余校验算法。
 
所谓“5位”不管是汇编和C都是要保证运算结果即表达式左值与右值的数据类型一致。
故小端时，程序内部在高24位补0（不是字符‘0’即0x30）.
反之在大端，程序内部在低24位补0（不是字符‘0’即0x30）.
 
内部补0程序将按给定的位数做CRC运算，由于不是分组位数的整数倍，程序强行终止。
对于循环不查表的将在第40次循环时结束，查表程序将在5次查表后退出。

外部人为补0（不是字符‘0’即0x30）后结果和内部补0是不同的，这样因为外部
补0凑齐了两组即64位，即64次环移和40次环移的结果肯定不同。
 
此时得到的校验和实际是另一个“满组”的明文对应的校验和。实际可认为“发生碰撞”
 
如：ascii="12345",hex=0x31,0x32,0x33,0x34,0x35
这需要2个32位数据变量即空间。
 
小端数据表示为0x34333231,0x00000035
大端数据表示为0x31323334,0x35000000(后补0)
大端数据表示为0x31323334,0x00000035(前补0)，演算器遵守此规则。
 
由于http://www.hotc51.com/HotPower_HotWC3.html是按分组大端设计的，
故：
选择CRC右移32，初值=00000000，权值=EDB88320(自动选出)
入值=FFFFFFFF(输入的XOR值)，出值=FFFFFFFF(输出的XOR值)。
输入明文=3433323135，点击“计算”
得到密文=641C1F5C340AC5E3
取出校验和(最后一组密文的取反结果)=~340AC5E3=CBF53A1C

可以看到输入和输出不等长，即
输入明文=3433323135
输出密文=641C1F5C340AC5E3  CRC64=CBF53A1C
 
此时点击“还原”，会发现：
输入明文=343332312D0B3C26
输出密文=641C1F5C340AC5E3   CRC64=CBF53A1C
 
即分组不全的3433323135可以用分组齐全的343332312D0B3C26替代。
 
这种分组不全的CRC校验方式很容易造成碰撞，故建议不要采用。
 
在一般CRC校验中，会利用CRC对角矩阵行列相等即主对角线为0
即加发一组最后的明文。来提高校验的真实性，虽然它也跑不过
“人为碰撞”之手。
 
例如(本坛vista下不能贴图)：
输入明文=343332312D0B3C26340AC5E3
输出密文=641C1F5C340AC5E300000000   CRC64=FFFFFFFF
 
这只能保护后2组数据的完整，依然可碰撞第1组：
输入明文=FFFFFFFF4917237A340AC5E3
输出密文=00000000340AC5E300000000   CRC64=FFFFFFFF
 
输入明文=248EF9BE4917237B340AC5E3
输出密文=00000001340AC5E300000000   CRC64=FFFFFFFF
 
输入明文=926CF53C49172378340AC5E3
输出密文=00000002340AC5E300000000   CRC64=FFFFFFFF
 
输入明文=6DD90A9DB6E8DC85340AC5E3
输出密文=FFFFFFFF340AC5E300000000   CRC64=FFFFFFFF
 
我们可以制造2^32次个这样的碰撞，而非数学家的X.XXX%次的概率。
 
所以菜农搞的是“人为碰撞”，而非本坛软件的“真碰撞”。 

总之“CRC碰撞”对菜农来说，“只是敲还原键而已，没什么高深的理论”。

专栏文章内容及配图由作者撰写发布，仅供工程师学习之用，如有侵权或者其他违规问题，请联系本站处理。 联系我们