CRC算法及CRC密码之探讨

CRC算法一般作为冗余校验之用，由于它的可逆性的不完整，导致了正规的CRC算法不能称之为CRC密码。

CRC之精华由初值、权、方向及位数组成，对其输入(明文)做CRC正运算得到输出的结果(密文)。
即：密文=CRC正运算(初值,权,方向,位数,明文);
反之，对其输出(密文)做CRC逆运算得到CRC的结果(明文)。
即：明文=CRC逆运算(初值,权,方向,位数,密文);

但要想实现CRC的可逆运算，必须满足：
CRC右移时，CRC权的最高位为1. CRC左移时，CRC权的最低位为1.

CRC种类繁多，经典的CRC皆为一表达式，即可得到一张CRC表。

例如：
CRC8右移=X8+X5+X4+1 即二进制的100110001
权正确选择D8~D1 即10011000放弃最低位D0，即0x8c

CRC8左移=X8+X2+X+1 即二进制的100000111
权正确选择D7~D0 即00000111放弃最高位D8，即0x07

这样处理后与标准CRC取权一致而且通俗一些。这样就可以将CRC算法可逆并升级为CRC密码。

虽然找到了CRC权与CRC算法可逆的关系：
CRC右移时，CRC权的最高位为1. CRC左移时，CRC权的最低位为1.

但是传统的CRC算法是：本次的CRC初值是上次CRC运算的结果即密文。
这是CRC算法不能成为CRC密码的最大败笔所在!!!

因为在CRC运算过程中，权保持不变(查表方便),那么密文串中任意相邻的密文左端即为本次的初值。

那么，根据：明文=CRC逆运算(初值,权,方向,位数,密文)，立刻得出对应的明文。
即相邻的2个密文即可攻破1个明文。只要对CRC初值穷举后即可得到第1个明文。CRC密码即破解。

所以要实现真正的CRC密码，必须去掉CRC算法中本次初值是上次密文的约束，这样才能实现
CRC密码的可靠性。

再次张扬CRC之精华---初值、权、方向及位数.

如果在位数(或分组)一定时，若每次CRC运算都能保证初值、权、方向这3个CRC要素在变化且
不可逆，那么破译者只能是穷举一条路可走~~~

对此我多年来研究了很多方法，简单举例：

我们可将某次CRC运算时的初值和权用上次的明文的扩散如菜农的三角密码与上次的初值和权异或后得到
本次的初值和权。

由于为保证CRC密码的可逆而损失的1位密钥，我们可以用方向补偿。即每次CRC运算的方向(左移、右移)
都在变化。这样想推出某位的明文，在已知密文的条件下，必须知道上次的明文才能得出本次CRC的三要素。

即破解某位密文必须同时知道某位上次的明文和密钥才能破解某位的明文~~~

同时知道了密文和明文还需要破解吗???这就是菜农想达到的目标~~~

先谈到这里~~这几天朋友为我找密码专家教授一起探讨一番，所以先写点东西。
同时也欢迎这里的密码高手给以指点~~~

下面给一链接，它实际是经过大量验证的CRC网上演算器，可以包含任意CRC算法。
HotWC3密码网上在线演算器
注意其中俺用“计算”和“还原”来代替“加密”和“解密”。意味CRC算法不能成为CRC密码.

关于HotWC3密码可参见:http://blog.ednchina.com/hotpower/31641/category.aspx

菜农HotPower@126.com  2009.6.30 于雁塔菜地





如何实现CRC算法的完全可逆

在上贴中，我们可以看到CRC算法的半可逆性，CRC右移时，CRC权的最高位为1. CRC左移时，CRC权的最低位为1.

即左移时，CRC权必须为奇数。同理右移是权也是取范围的一半。

我问过对CRC有所了解的朋友：“CRC运算是否可逆”。朋友回答：“可逆，有专著”。

那是因为标准的CRC表达式都为:CRCN=Xn+....Xm+...1.其中1即为X0.
而且大多的CRC算法都是左移的，且权都为奇数，如CRC16的1021.

如果将CRC算法变成CRC密码，则CRC三要素：初值、权及方向都不再有任何限制。

为满足CRC可逆，就必须限定权为取值范围的一半，这样CRC密钥(CRC三要素)中的权就降低了
加密强度1位。

为了不限制CRC权的取值范围，我们可以修正CRC算法：
正常的CRC运算中，有句异或权的语句，我们只需再加一句即可。
例如CRC8:
左移CRC8:
      CRCVALUE ^= CRCPOLY;
      CRCVALUE  |= 0x01;//强行满足CRC左移时，CRC权的最低位为1.
右移CRC8:
      CRCVALUE ^= CRCPOLY;
      CRCVALUE  |= 0x80;//强行满足CRC右移时，CRC权的最高位为1.
这样处理并未违反CRC算法，而且也未限定CRC权。从而实现了CRC算法的完全可逆。

大家知道算法和密码是有区别的。算法可以可逆和不可逆，但密码一定是可逆(加密和解密)的。

HotWC3密码网上在线演算器



变异CRC运算使之成为真正的CRC密码

在前两贴中强调了CRC可逆后并不能成为真正的CRC密码，这主要归咎CRC算法中
本次CRC的初值是上次CRC运算的结果(密文)。
这使我们很容易从2个相邻的CRC密文导出本次的明文。

所以需要将CRC初值和CRC权都“动起来”。为了补偿CRC可逆对CRC权的限定，可以让方向也“动起来”

这样做后，CRC三要素：初值、权和方向就变成了CRC密钥了。
即知道CRC密钥和明文，才能得出与之对应的密文。

为了使每次CRC运算时，CRC三要素都在变化且和密文无任何关系，我们可以将上次的明文发散后得出本次
的CRC三要素，而且要保证发散是不可逆的。

这样解密者就不可能从密文串中推出其他CRC元素。这就牵扯到三角密码的问题。

三角密码在CRC密码中的发散作用

谈到“三角密码”要追述到70年代初我小学快毕业时看了一本前苏联数学家有关直角三角形的论著，
很是头晕~~~

等我上中学后用数学归纳的方法推出很菜而实用的“说法”：
在直角三角形中，已知一整数直角，求另一整数直角边和整数斜边。

即A^2+B^2=C^2  (^表示乘方)

解：

若A为奇数时，A先平方后“砍半”即为B和C.
若A为偶数时，A先“砍半”后“手拉手”即为B和C.

例： 3   3^2=9  9/2=4和5     即3^2+4^2=5^2
       4   4/2=2   2^2=4(3,5)  即4^2+3^2=5^2

以此类推，最后得出了“三角密码表”

为何要用“三角密码表”发散呢？？？这源于密码学中的质数分解。

因为我的出发点在MCU,它的资源较小，分解质数肯定不行，故想到了小时候的“三角密码”。

前面已经反复论述了CRC运算不能成为CRC的因果关系，所以用三角密码来发散上次明文来充当
本次的初值和权是个不错的想法。

这样使解密难度增大，因为三角运算是平方级的运算，显然比一般的“与”“或”“异或”等难度要大。
因为它是特定条件下的三元二次方程。若无“直角三角形”“全为整数边”的特定条件，实为无解。

由于“三角密码表”为无重码进行了变换，且上次明文经三角变换后再与上次的初值和权异或，故它是不可逆的。
即无法从某次的密文中推出其他CRC元素，逼迫解密者只有穷举一条路。而且只能从第1个密文开始穷举。

星期密码对CRC密钥的保护作用

如上所述，CRC三要素实为CRC密钥。严格来讲其密钥长度为CRC位数的1倍。

由于CRC密码可分CRC8,CRC16...CRC64...CRC128,CRC256,则密钥长度16,32...128...256,512位.
故可以视为是一种分组密码。

破解CRC密码的关键是破解CRC三元素即CRC密钥，它的强度与分组的长度即CRC位数有关。

那么如何在MCU这样的小资源系统中得到高可靠的密码系统呢？？？如何降低分组？？？

这样我想到了“星期密码”。那是我自己没事用计算机编程的思维推导出来的~~~竟然和122年前的古人雷同。很是惭愧~~~

由于“星期密码”是不可逆的，唯一的日期对应于唯一的星期，反之无解。

大家可能知道“星期四百年一轮回”，加上“天干地支”“六十年一甲子”，HotWC3就成为了组合密码。
它可以在小分组例CRC8密码上扩充密钥长度为日期密钥长度。甚至更长~~~

HotWC3密码经过星期及天干地支变换得到“天地密钥”，再经过三角变换收敛为CRC密钥，以满足CRC小分组密码。

最后“日期密钥”及“天地密钥”发散后对CRC密码的输入和输出作用最终得到HotWC3密码。这样也破坏了
穷举CRC密钥的企图。

以下是HotWC3初级密码的一个框图（有点过时了~~~）







群魔乱舞的CRC

http://blog.ednchina.com/hotpower/220371/message.aspx

NamePolynomialRepresentations: normal or reversed (reverse of reciprocal)
CRC-1 x + 1 (most hardware; also known as parity bit) 0x1 or 0x1 (0x1)
CRC-4-ITU x4 + x + 1 (ITU G.704, p. 12) 0x3 or 0xC (0x9)
CRC-5-ITU x5 + x4 + x2 + 1 (ITU G.704, p. 9) 0x15 or 0x15 (0x1A)
CRC-5-USB x5 + x2 + 1 (USB token packets) 0x05 or 0x14 (0x12)
CRC-6-ITU x6 + x + 1 (ITU G.704, p. 3) 0x03 or 0x30 (0x21)
CRC-7 x7 + x3 + 1 (telecom systems, MMC,SD) 0x09 or 0x48 (0x44)
CRC-8-ATM x8 + x2 + x + 1 (ATM HEC) 0x07 or 0xE0 (0x83)
CRC-8-CCITT x8 + x7 + x3 + x2 + 1 (1-Wire bus) 0x8D or 0xB1 (0xC6)
CRC-8-Dallas/Maxim x8 + x5 + x4 + 1 (1-Wire bus) 0x31 or 0x8C (0x98)
CRC-8 x8 + x7 + x6 + x4 + x2 + 1 0xD5 or 0xAB (0xEA [5])
CRC-8-SAE J1850 x8 + x4 + x3 + x2 + 1 0x1D or 0xB8 (0x8E)
CRC-10 x10 + x9 + x5 + x4 + x + 1 0x233 or 0x331 (0x319)
CRC-11 x11 + x9 + x8 + x7 + x2 + 1 (FlexRay) 0x385 or 0x50E (0x5C2)
CRC-12 x12 + x11 + x3 + x2 + x + 1 (telecom systems, [8][9] ) 0x80F or 0xF01 (0xC07)
CRC-15-CAN x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1 0x4599 or 0x4CD1 (0x62CC)
CRC-16-Fletcher Not a CRC; see Fletcher's checksum Used in Adler-32 A & B CRCs
CRC-16-CCITT x16 + x12 + x5 + 1 (G.hn PHY headers, 802.15.4, X.25, V.41, CDMA, Bluetooth, XMODEM, HDLC,PPP, IrDA, BACnet; known as CRC-CCITT, MMC,SD) 0x1021 or 0x8408 (0x8810 [5])
CRC-16-DNP x16 + x13 + x12 + x11 + x10 + x8 + x6 + x5 + x2 + 1 (DNP, IEC 870, M-Bus) 0x3D65 or 0xA6BC (0x9EB2)
CRC-16-IBM x16 + x15 + x2 + 1 (SDLC, USB, many others; also known as CRC-16) 0x8005 or 0xA001 (0xC002)
CRC-24-Radix-64 x24 + x23 + x18 + x17 + x14 + x11 + x10 + x7 + x6 + x5 + x4 + x3 + x + 1 (FlexRay) 0x864CFB or 0xDF3261 (0xC3267D)
CRC-30 x30 + x29 + x21 + x20 + x15 + x13 + x12 + x11 + x8 + x7 + x6 + x2 + x + 1 (CDMA) 0x2030B9C7 or 0x38E74301 (0x30185CE3)
CRC-32-Adler Not a CRC; see Adler-32 See Adler-32
CRC-32-IEEE 802.3 x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 (V.42, MPEG-2, PNG [10], POSIX cksum) 0x04C11DB7 or 0xEDB88320 (0x82608EDB [7])
CRC-32C (Castagnoli) x32 + x28 + x27 + x26 + x25 + x23 + x22 + x20 + x19 + x18 + x14 + x13 + x11 + x10 + x9 + x8 + x6 + 1 (G.hn payload) 0x1EDC6F41 or 0x82F63B78 (0x8F6E37A0 [7])
CRC-32K (Koopman) x32 + x30 + x29 + x28 + x26 + x20 + x19 + x17 + x16 + x15 + x11 + x10 + x7 + x6 + x4 + x2 + x + 1 0x741B8CD7 or 0xEB31D82E (0xBA0DC66B [7])
CRC-64-ISO x64 + x4 + x3 + x + 1 (HDLC — ISO 3309) 0x000000000000001B or 0xD800000000000000 (0x800000000000000D)
CRC-64-ECMA-182 x64 + x62 + x57 + x55 + x54 + x53 + x52 + x47 + x46 + x45 + x40 + x39 + x38 + x37 + x35 + x33 + x32 + x31 + x29 + x27 + x24 + x23 + x22 + x21 + x19 + x17 + x13 + x12 + x10 + x9 + x7 + x4 + x + 1 (as described in ECMA-182 p.51) 0x42F0E1EBA9EA3693 or 0xC96C5795D7870F42 (0xA17870F5D4F51B49)

从以上“众多”的CRC表达式中，实际都对应一张表，以便实现CRC查表法来完成CRC运算。

而实际上每种CRC都有很多“CRC表”。

例如CRC8,根据上面菜农的CRC论述可知，右移CRC8有1/2*65536,左移CRC8也有1/2*65536张“CRC表”。

故CRC8的表即数组需要65536个字节(64*1024).可想CRC64需要多少个表~~~

这在MCU总计64KByte空间是很难实现的，故“群魔乱舞的CRC”是无法查表的~~~

我看过本坛的巨著《加密与解密》关于CRC32的破解方法~~~经典的CRC32实际是一个固定的CRC密码。
它和“群魔乱舞的CRC”是不可攀比的~~~因为“群魔乱舞的CRC”的精华在于“无缝”。

“苍蝇会叮有缝的蛋”，这是无数“正向工作者”犯的最大错误~~~

他们将“缝”(分支语句)留给了“苍蝇”(逆向者)~~~

哈哈~~~俺也是只“苍蝇”~~~但俺希望“天下无贼”~~~

如何使“蛋无缝”以加大逆向难度

大家心里明白，“世上无密”，一切密码都可解之无非是技术和时间问题。
在逆向成本外和保密时间段内，其密码为真密码也~~~

当今“破解”大多为“暴力破解”，更多的是“有缝的蛋”---密码校验处的分支语句。
这种通过调试软件跟踪到密码校验处而改变程序分支走向的所谓逆向估计占很大的比例。

实际完全可以做到“无缝”或“小缝”~~~

举个很简单的例子：

现在又很多类似“加密狗”的产品，有些就是用CRC算法加密的，如芯片DS1990A,DS1990R,DS2401...等。

它采用右移CRC8，长度为64位。首字节为设备类型，后跟48位全球唯一码，尾字节为前7个字节的CRC8结果。

例如：http://www.hotc51.com/HotPower_CRC.html

其中:初值为0x00,权为0x8c(其他算法先移位故为0x18)
电子标签：0168AE9405000014
               (设备01---芯片DS1990,DS2401,唯一码68AE94050000，CRC8=0x14)

有些应用不了解CRC运算的精华所在，把0168AE9405000014的“字样”留给了“苍蝇”~~~

如果是用“密文”5E63374D84ED1400呢？？？逆向者会感觉如何？？？？这就是“小缝”

如何“无缝”呢？？？至少不能有分支！！！

大家知道CRC有个“特点”，在得到一个CRC结果(密文)时，如果再用此密文当明文做1次CRC运算

时，其结果必为0！！！即CRC运算(多1次)正确时，CRC结果为0.

我们即可用此“0”在很多关键位置和其他数据进行“或”“加”及“异或”等“运算”。

不要提示密码不正确等“暴露自己”的动作，应该“放鬼子进村”---无缝

“敌人”可以实现任何操作，但最关键的输出结果都不对~~~

虽然可以施加“内存断点”来“破缝”，但无穷嵌套和递归的“内存断点”至少难住一般的“逆向工作者”。

密码不能做为花架子任人宰割

在很多的密码应用程序中，密码（注册码之类）常常只用来做程序的通行字。
这就给逆向者留下了破解之笔。

还有在逆向某功能模块时，常使用搜索关键字的手法以迅速接近模块程序。
例如I2C模块，0xa0为写命令，0xa1为读命令。
找到此命令字即可找到模块操作程序。

假若正向者磨烦一些，将密文序列（最好别涉及明文序列）的某处字节经过运算后得出0xa0,0xa1
会如何呢???至少想搜索关键字加快逆向速度的美梦不能快速实现。

最终逆向是结局，我深知此道~~~但这给逆向者带来的“痛苦”是肯定的~~~

这样至少会大大延长密码通行字的“寿命”，避免在程序逆向开始就被击破.

密钥异地保护的安全问题

“逆向工作者”都知道，本地密钥实际就是一组“静态数据”，实际无密而言。
进入了程序的海洋，“逆向者”可以任意遨游~~~

所以就出现了很多的异地密钥系统，如硬件加密狗。
它比本地密钥系统逆向难度要大得多，因为许多系统都是“一密一文”。

当然此类硬件加密狗逆向也很容易~~~

一是破解硬件加密狗，这需要硬件的技术知识，它的难度实际就是破解MCU内部的程序。
它相对PC的难度应该小点，至少正向者有成本的要求及难点。逆向费用也高。

再自然是破解PC软件。这主要要看PC的正向者编程的手法和习惯~~~

这里都是行家，菜农是门外汉不便多言~~~

菜农发此贴不是鼓励逆向者，而是提示正向者的警惕~~~

防人之心不可无，向被逆向者致敬

“不是我们无能，而是敌人太狡猾”~~~世道不公，逆向者永远是理论的胜利者。

菜农认为被逆向者应该感到荣幸~~~因为他的作品太奇妙了~~~

他的被逆向成功，并不是他的错和失误~~~

因为逆向者基本都是正向的高人~~~他---应该不流泪~~~

HotPower的网上CRC演算器(V1.09)

在更新的CRC密码版本中，主要是归顺CRC逆运算的算法和正运算保持相对一致。

例如(源程序在网页文件中)：

/*
右移crc8正算法: CRC8=X8+X5+X4+1

初值:crcvalue = 0x00
权值:crcval   = 0x8C (X8+X5+X4)
明文:crcbyte  = 输入

结果:crcvalue = 输出密文
*/

function crc8r(crcbyte)
{
var i,temp;
  crcbyte &= 0xff;//明文,它在正运算中的作用是提供跳变标志
  for(i = 0; i < 8; i++){
    temp = crcvalue ^ crcbyte;//记忆初值和明文移动终点D0(X0)跳变
    crcvalue >>>= 1;//新D7=0,旧D0被抛弃
    crcbyte >>>= 1;//新D7=0,旧D0被抛弃
    if(temp & 0x01) {//测试移位前的终点D0(X0)跳变
      crcvalue ^= crcval;//0x8C;//CRC=X8+X5+X4 有X8才能形成环移,故右移时,权最高位一定为'1'
//下句隐含告诉CRC逆运算此时做过XOR权的X8运算，同时满足权为任意值时保证CRC可逆,故强行环移
      crcvalue |= 0x80;//权为任意值时，保证CRC权X8=1，减少1位CRC密码强度,以便实现CRC的逆运算
    }
  }
  crcvalue &= 0xff;//输出密文
}

/*
右移crc8逆算法: CRC8=X8+X5+X4+1

初值:crcvalue = 0x00
权值:crcval   = 0x8C (X8+X5+X4)
密文:crcbyte  = 输入

结果:crcvalue = 输出明文
*/

function discrc8r(crcbyte)
{
var i,temp;
  crcbyte &= 0xff;//密文,它在逆运算中的作用是提供跳变标志
  for(i = 0; i < 8; i++){
    temp = crcvalue ^ crcbyte;//记忆初值和密文移动终点D7(X8)跳变
    if(crcvalue & 0x80){//CRC正运算时隐含告诉过需要X8权的XOR运算
      crcvalue ^= crcval;//0x8C;//CRC=X8+X5+X4 D7(X8)的XOR被下句移位破坏
    }
    crcvalue <<= 1;//与正运算移位相反才能还原
    crcbyte <<= 1;//与正运算移位相反才能还原
    if(temp & 0x80) crcvalue ^= 0x01;//补全被移位破坏的D7(X8)的XOR
  }
  crcvalue &= 0xff;//输出明文
}

HotPower的网上HotWC3/CRC演算器(V1.09)

HotWC3密码依据的理论和构思及实现

HotWC3密码属于传统密码体系中的序列密码(分组为1位或1字节)，核心采用流加密法。
密文流由明文流和密钥流作用(移位+异或)后得出，反之亦然。

在密码学中，当满足一定条件下，流加密法是一种不可破解的加密方法。
如果密钥流完全随机且与明文流等长，那么它是不可破解的，即只能穷举解密。
香农早已证明，在这种条件下，流加密法对密文攻击法是绝对安全的。

传统的流加密都会用线性反馈移位寄存器LFSR来产生伪随机密钥流，其特征多项式
尽量满足LFSR的最大周期。核心算法就是简单的移位+异或。

传统的CRC运算可以理解为密钥流就是密文流的流加密法的CRC加密算法。
它的密钥流实际由CRC初值(运动中的密文流)和权(特征多项式)组成。
由于它的密钥流就是密文流，任意相邻的2个密文皆可还原1个明文，故不能成密码。

要将CRC运算转换为CRC密码，应该遵守流加密法的准则，尽量保证密钥流伪随机。
故CRC的三要素(初值、权和方向)都应该在流加密过程中随机产生并成为CRC密码的
伪随机密钥流.

为了达到CRC密钥中初值和权的随机,采用了带有“陷门”的三元二次方程达到迅速扩散
和不可逆以实现密钥流的伪随机之目的。即采用了三角密码实现扩散。
三角密码的“陷门”出自命题:
在直角三角形中，三个直角边都为整数，已知一个直角边求解另一直角边和斜边。
即: A^2+B^2=C^2 其中:^表示平方，A,B,C皆为整数

CRC密钥流由密钥流种子(星期密钥)与明文流等叠加以实现“一文一密”。
HotWC3为了对付明文攻击法，即已知部分或全部明文(流)及密文流破解CRC密钥。
采用日期密钥(用户密钥)来生成CRC的密钥流种子即星期密钥。
故在HotWC3密码体系中,CRC密钥实际是日期密钥(用户密钥)的子密钥。
其中1字节的星期密钥实际是排在明文流前的“假明文”，它由日期密钥生成。
由于HotWC3密码属于序列密码，故明文攻击法的开始必须解决“假明文”的问题。
由于星期算法的不可逆性，攻击者无法从“假明文”推导出日期密钥(用户密钥)。

用户密钥长度小于等于明文流的长度。它不但作用于CRC伪随机密钥流而且也作用
于明文流和密文流中。它的目的就是伪随机与明文流等长以达到不可破解的目的。

写累了~~~给教授看菜农实在写不好~~~种菜和动笔俺还是觉得前者容易
俺知道HotWC3不会比RC4、A5差到那里去，感觉大家总是觉得“洋太阳”还是风光些~~~

孤独~~~

菜农对于CRC划归单向散列函数的疑惑

先引用有关的基本概念：

　　1、散列（HASH）函数

　　散列（HASH）函数H也称哈希函数或杂凑函数等，是典型的多到一的函数，其输入为一可变长x（可以足够的长），输出一固定长的串h（一般为128位、160位，比输入的串短），该串h被称为输入x的Hash值（或称消息摘要Message Digest、指纹、密码校验和或消息完整性校验），计作h=H（x）。为防止传输和存储的消息被有意或无意地篡改，采用散列函数对消息进行运算生成消息摘要，附在消息之后发出或与信息一起存储，它在报文防伪中具有重要应用。

　　消息摘要采用一种单向散列算法将一个消息进行换算。在消息摘要算法中，文件数据作为单向散列运算的输入，这个输入通过HASH函数产生一个散列值。如果改动了文件，散列值就会相应地改变，接收者即能检测到这种改动过的痕迹。从理论上来讲，攻击者不可能制造一个替用的消息来产生一个完全相同的消息摘要。Hash函数可用于数字签名、消息的完整性检测、消息的起源认证检测等。

　　散列函数是安全的是指它具有：

　　一致性：相同的输入产生相同的输出。

　　随机性：消息摘要外观是随机的，以防被猜出源消息。

　　唯一性：几乎不可能找到两个消息产生相同的消息摘要。

　　单向性：即如果给出输出，则很难确定出输入消息。

　　Hash函数H一般满足以下几个基本要求：

　　（1）输入x可以为任意长度；输出数据串长度固定；

　　（2）正向计算容易，即给定任何x，容易算出H（x）；反向计算困难，即给出一Hash值h，很难找出一特定输入x，使h=H（x）；

　　（3）抗冲突性（抗碰撞性），包括两个含义，一是给出一消息x，找出一消息y使H（x）=H（y）是计算上不可行的（弱抗冲突），二是找出任意两条消息x、y，使H（x）=H（y）也是计算上不可行的（强抗冲突）。

　　2、私钥加密

　　私钥加密又称为对称加密，因为同一密钥既用于加密又用于解密。私钥加密算法非常快（与公钥算法相比），特别适用于对较大的数据流执行加密转换。

　　3、公钥加密（PKCS）和数字签名

　　公钥加密使用一个必须对未经授权的用户保密的私钥和一个可以对任何人公开的公钥。用公钥加密的数据只能用私钥解密，而用私钥签名的数据只能用公钥验证。公钥可以被任何人使用；该密钥用于加密要发送到私钥持有者的数据。两个密钥对于通信会话都是唯一的。公钥加密算法也称为不对称算法，原因是需要用一个密钥加密数据而需要用另一个密钥来解密数据。

　　数据加密/编码算法列表

　　常见用于保证安全的加密或编码算法如下：

　　1、常用密钥算法

　　密钥算法用来对敏感数据、摘要、签名等信息进行加密，常用的密钥算法包括：

　　DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合；

　　3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高；

　　RC2和 RC4：用变长密钥对大量数据进行加密，比 DES 快；

　　IDEA（International Data Encryption Algorithm）国际数据加密算法，使用 128 位密钥提供非常强的安全性；

　　RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件快的长度也是可变的；

　　DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）；

　　AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高，目前 AES 标准的一个实现是 Rijndael 算法；

　　BLOWFISH，它使用变长的密钥，长度可达448位，运行速度很快；

　　其它算法，如ElGamal、Deffie-Hellman、新型椭圆曲线算法ECC等。

　　2、单向散列算法

　　单向散列函数一般用于产生消息摘要，密钥加密等，常见的有：

　　MD5（Message Digest Algorithm 5）：是RSA数据安全公司开发的一种单向散列算法，MD5被广泛使用，可以用来把不同长度的数据块进行暗码运算成一个128位的数值；

　　SHA（Secure Hash Algorithm）这是一种较新的散列算法，可以对任意长度的数据运算生成一个160位的数值；

　　MAC（Message Authentication Code）：消息认证代码，是一种使用密钥的单向函数，可以用它们在系统上或用户之间认证文件或消息。HMAC（用于消息认证的密钥散列法）就是这种函数的一个例子。

　　CRC（Cyclic Redundancy Check）：循环冗余校验码，CRC校验由于实现简单，检错能力强，被广泛使用在各种数据校验应用中。占用系统资源少，用软硬件均能实现，是进行数据传输差错检测地一种很好的手段（CRC 并不是严格意义上的散列算法，但它的作用与散列算法大致相同，所以归于此类）。

菜农长期疑惑CRC的可逆问题，也有过在网上的探讨。

“单向性：即如果给出输出，则很难确定出输入消息。”

菜农10年前已证实过CRC的半可逆性，因为菜农不是数学家，写不出什么论点和论据~~~

所以俺认为CRC应该是陷门单向散列函数。

俺真想找个数学家或密码学家探讨一番，以消除俺多年的疑惑。

为什么CRC归属单向散列函数还能实现加密和解密？？？

由于CRC有个“陷门”：“CRC右移时，CRC权的最高位为1. CRC左移时，CRC权的最低位为1.”

那么我们就可以利用这个“陷门”，在加密和解密函数中，XOR运算后再去掉此“陷门”。

从程序和实践中看，实际是加密函数中有此“陷门”。

如程序：
/*
右移crc8正算法: CRC8=X8+X5+X4+1

初值:crcvalue = 0x00
权值:crcval   = 0x8C (X8+X5+X4)
明文:crcbyte  = 输入

结果:crcvalue = 输出密文
*/

function crc8r(crcbyte)
{
var i,temp;
  crcbyte &= 0xff;//明文,它在正运算中的作用是提供跳变标志
  for(i = 0; i < 8; i++){
    temp = crcvalue ^ crcbyte;//记忆初值和明文移动终点D0(X0)跳变
    crcvalue >>>= 1;//新D7=0,旧D0被抛弃
    crcbyte >>>= 1;//新D7=0,旧D0被抛弃
    if(temp & 0x01) {//测试移位前的终点D0(X0)跳变
      crcvalue ^= crcval;//0x8C;//CRC=X8+X5+X4 有X8才能形成环移,故右移时,权最高位一定为'1'
//下句隐含告诉CRC逆运算此时做过XOR权的X8运算，同时满足权为任意值时保证CRC可逆,故强行环移
      crcvalue |= 0x80;//权为任意值时，保证CRC权X8=1，减少1位CRC密码强度,以便实现CRC的逆运算
    }
  }
  crcvalue &= 0xff;//输出密文
}

/*
右移crc8逆算法: CRC8=X8+X5+X4+1

初值:crcvalue = 0x00
权值:crcval   = 0x8C (X8+X5+X4)
密文:crcbyte  = 输入

结果:crcvalue = 输出明文
*/

function discrc8r(crcbyte)
{
var i,temp;
  crcbyte &= 0xff;//密文,它在逆运算中的作用是提供跳变标志
  for(i = 0; i < 8; i++){
    temp = crcvalue ^ crcbyte;//记忆初值和密文移动终点D7(X8)跳变
    if(crcvalue & 0x80){//CRC正运算时隐含告诉过需要X8权的XOR运算
      crcvalue ^= crcval;//0x8C;//CRC=X8+X5+X4 D7(X8)的XOR被下句移位破坏
    }
    crcvalue <<= 1;//与正运算移位相反才能还原
    crcbyte <<= 1;//与正运算移位相反才能还原
    if(temp & 0x80) crcvalue ^= 0x01;//补全被移位破坏的D7(X8)的XOR
  }
  crcvalue &= 0xff;//输出明文
}

注意权本身不变，这样做不改变经典CRC运算的同时也可使解密难度加倍~~~

这样解密者猜不出权值，真的权值若再对密文流及密钥流施加作用后，将逼迫解密者解出真的权值。

探讨对HotWC3攻击问题

根据密码分析者掌握明、密文的程度密码分析可分类为：
1、唯密文攻击：仅根据密文进行的密码攻击；
2、已知明文攻击：根据一些相应的明、密文对进行的密码攻击。
3、选择明文攻击：可以选择一些明文，并获取相应的密文，这是密码分析者最理想的情形。例如，在公钥体制中。
4、选择密文攻击：密码分析者能选择不同的被加密的密文，并可得到对应的解密的明文，密码分析者的任务是推出密钥。
5、选择密钥攻击 ：这种攻击并不表示密码分析者能够选择密钥，它只表示密码分析者具有不同密钥之间关系的有关知识。
6、软磨硬泡攻击 ：密码分析者威胁、勒索，或者折磨某人，直到他给出密钥为止。

由于HotWC3主算法采用CRC算法，在不知道CRC密钥(初值、权及方向)，则CRC是散列的，即多对一单向不可逆的。

所以以上有关涉及密文攻击都是梦想。由于算法公开，故可已知明文或选择明文攻击。
HotWC3的CRC密码算法采用一次CRC运算且一次一密，故基于明文的攻击不如直接攻击密钥。

再HotWC3实际为两层密钥，CRC密码的CRC密钥是HotWC3主密钥的子密钥，故选择密钥的攻击只能转而攻击
主密钥。这样的设计使破译者只能“基于密钥攻击”，即必须知道HotWC3的主密钥才能破解HotWC3密码。

如果这样的思路能实现及证明，那么HotWC3密码就达到了它当初设计的目的:基于密钥攻击的不可破解的密码。

一次CRC运算及一次一密的原因所在

本贴以CRC运算实例详细说明：

已知: CRC8右移标准算法，初值：00,权：8c,明文流：BBF4FD0A,密文流：12345678

解密者采用已知密文12345678攻击，假定：
假设：CRC8右移算法，初值12, 权：8c(标准CRC8)
         密文流：345678（12已做初值），解密CRC8右移得到明文：F4FD0A

可以看到明文流F4FD0A只差第1个明文BB.
用12对CRC密钥内的初值穷举256次即可得到明文BB.这里由于初值恒为0，故1次即可破解CRC8

故HotWC3的设计绝不次于任何密码的设计。
同理，任取密文流中相邻的2个密文即可破解1个明文，例：

取密文5678,将56做CRC初值，78为密文，权不变为8C,得到明文0A.

故连续多字节标准的CRC运算不能作为CRC密码算法。这在以上各贴中已反复论述。

所以我们需要保持CRC运算的“三密钥”(初值、权及方向)的特点及优势，舍去连续运算。

在完成1次CRC运算后立即替换CRC密钥(初值、权及方向)，做到“一次一密”。

使基于明文或密文攻击的设想都破灭~~~

CRC内部复杂的移位和异或运算如同DES等分组置换一样散列，根本无法从明文和密文中推出密钥。

而且和分组密码中的N轮置换一样，CRC密码每位就需要一次“置换”(移位和异或)。

若CRC密码的内核采用CRC64，密钥长度可达128位，试想若采用CRC256后该是什么“等级”？？？

类同MD5等密码都有几组函数，CRC密钥中的“方向”就是一个每字节(8位)就随机变换移动方向的“函数”。

故HotWC3密码的设计绝不次于出自“名门”任何密码~~~

由于HotWC3出身低微，故菜农戏称"厕所密码"~~~即WC3密码~~~

HotWC3在(无线)通讯领域的应用

HotWC3密码的归类应该属于流加密法，即使内核采用CRC64甚至更大的CRC算法。
所以它同时兼容了分组密码的特性。

由于是流加密，故在发送方发送完数据(密文流)后，接收方接收到一字节(密文)后就会立即得到明文流。
这在通讯特别是无线及单总线上将不会产生延迟，它和RC4及A5都是一样的。

它不需要分组及块传送，更不会产生接收方必须接收一完整块后才能解密的延迟，因为HotWC3是位译码。

多年前我就将其用于实践，而且实现了“零耗时”及收发双方都无延迟。

http://www.google.cn/search?hl=zh-CN&q=%E5%8D%95%E6%80%BB%E7%BA%BF+hotpower

专利、共享及探讨

菜农一生清贫~~~不图什么名利~~~喜好灌水，所以谷歌百度不少~~~

逆向是俺的乐趣~~~研究是俺的享乐。至于结果和过程俺从不在乎~~~

至于专利俺不想这个虚的玩意~~~

早有著名大通讯公司说可将HotWC3申报专利，但无菜农什么事~~~菜农答应了

可姑娘说要把俺送进“养老院”~~~俺也“冒死发布”~~~

主要是想找个真正的密码高手给指点一番~~~

俺知道很难~~~因为俺是一个50岁的中国农民~~~教授都要讲“洋文”~~~中国菜不吃香~~~

同事先是说他的同学是搞密码的，而且王晓云是他的“师姐”，当时俺很兴奋~~~

后来说是搞编码的，而且很厉害~~~

让俺写些资料~~~晕！！！农民那会搞写作呀~~~种菜才是俺的特长。

我近年来也找过数学家，但都说对密码研究一般~~~是在遗憾...

为了更好地探讨和研究密码，俺决定找个好网站~~~就找到了此坛~~~

可惜~~~留给菜农的还是遗憾和“自言自语”~~~

菜农对密界矛盾争锋的看法

有很多密码被宣称被“破解”，但有几个密码被“破解”后被勒令不准再使用？？？

谁能举几个实例？？？哪怕只有1个.

菜农心中被“破解”的定义为：从密文或明文中用数学表达式或方法推出其密钥。而且无一例外。

所谓“破解”只是几个“弱密钥”或“弱散列值”，这只是破解者运气好些~~~

虽然俺不是密码工作者，但也敢“站在密码创造者”这个“高度”来看问题：

假若自己的密码可以“从密文或明文中用数学表达式或方法推出其密钥”，那麽“扩散”和“混乱”

当初在设计中就没想到过~~~

如同22楼CRC运算不能成为CRC密码的破解例子~~~

看看HotPower星期冗余三角HotWC3密码网上在线演算器(V1.09)内的“运算”和“还原”的字样，

就会明白密码不是可逆就能搞的~~~它必须得先通过自己的逆向~~~

创造密码难，破解密码更难。有矛必有盾，有盾必有矛。矛盾永远对立而不分。

CRC运算结果0在加密和解密及校验的实际意义

还用HotPower星期冗余三角HotWC3密码网上在线演算器(V1.09)默认的右移CRC8举例：

初值00 权8C 明文(输入)0168AE9405000014 点击“计算”后 CRC结果为0

但大多人可能不关心密文(输出)5E63374D84ED1400，作为一般校验可以不追究。

将明文去掉最后那个字节14即明文为0168AE94050000，点击“计算”后 CRC结果为14

这说明明文在初值00权8C时，明文0168AE94050000的CRC8右移的校验和为14

再将此校验和14加入明文0168AE94050000尾即0168AE9405000014，则校验和为0

这是因为在CRC算法中，当初值等于明文时，不管权为何值，CRC运算结果都将为0！！！

加密者可以用此0与解密者进行对决~~~实现“无缝隙校验”

因为0168AE94050000的校验和为14，0168AE9405000014的校验和为0

14这个“关键词”很容易暴露给逆向者，用分支语句来判断0168AE94050000的校验和=14

意味着加密者“自掘坟墓”~~~解密者一个“jmp”即可把加密者“打入18层地狱”~~~

故应该充分利用CRC运算法则：初值=明文时结果恒为0.

将此0在程序中关键处群魔乱舞地进行“+”，“-”，“XOR”,“OR”等不影响运算结果的操作！！！

虽然最终逃脱不了被内存断点跟踪的命运，但逆向者破解后也要累的“进医院”~~~

关于HotWC3的未来和展望

这次菜农再次论战CRC，而且找到了自认为比较专业的论坛，虽然还是失望，但还是在耐心等待...

10多年都等过来了，还企望再快几天？？？

本网页已拷贝给有关专家和学者，菜农在等待着“审判”~~~

为等待此“审判”，菜农又花了几天耐心论证，并查阅了大量有关密码学的资料，并仔细地研究了

攻击HotWC3的各种方法~~~

期待之中~~~

就此结贴。

菜农HotPower@126.com  2009.7.4 于西安大雁塔村队部

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！