SHA1和MD5算法详解和源码
目录- 吐槽一下
- SHA1和MD5的算法说明
- 上源码
先吹一下牛,这个估计是带中文注释写的最清楚的MD5和SHA1源码。呵呵。
1 吐槽一下
最近在整理一些代码,发现自己的库里面缺少一些HASH的的代码,于是决定移植一套代码进来,本来认为是个极其轻松的事情,结果却搞的小小蛋痛了一把。很多开源代码都有一点凌乱。
移植过程代码主要参考过rhash这个库,好处是后面发现,其实辛亏参考的是这套库。后面发现其他库,在某些环节陷得更深,这套库在某些程度重构过。当然此库的小bug也不算少,比如冗余代码,某些地方字节序处理错误等。
本来以为拖几个代码进来,迅速搞掂的一件事情,结果发现,很多地方看不懂,不明究理,我稀里糊涂的看了1天多,同时参考了4-5个库的代码(其实有点越参考越糊涂),最后决定看懂算法再动手。
我个人总结这些代码这样难以看懂的原因大致如下:
大体大家当年可以参考的代码有几套,(可以看出流派差别),RSA的代码, openssl的代码等,这些代码当年估计估计来自很多数学家,数学家很多时候写的代码不具备可读性,比如大部分算法里面前面BLOCK先调用xxx_update函数,后面调用最后几个BLOCK处理的xxx_final函数,,但xxx_final函数里面又调用xxx_update函数,所以upadate函数就有处理2种情况的代码,让整体代码思路乖乖的,可能数学家他们太聪明了,思维可以多路径化。而目前的代码多是在这些基础上改进的。很多动手改的人也没有真正理解问题,就动了手,结果很多代码反而让我这种吹毛求疵的疑惑。比如早期机器的字节序估计都是一种(BE),而后面的改进过程,字节序的问题慢慢浮现,而很多改动并不完全理解原理和初衷,结果代码就改的的有点乱了。
另外,很多书和说明,对于MD5,SHA1算法的说明都很含混,比如《应用密码学》里面对于SHA1的每次处理的块BLOCK只有一句话描述,和MD5一样,但实际呢?SHA1算法里面的数据都是用BE编码的(最后一个长度也要求用BE格式), 而MD5算法内部数据是LE,这些含混的说明也造成了理解的痛苦。
最后在rhash和维基的帮助下,完成了代码。厚着面皮说我的代码实现敢说是目前MD5,SHA1算法中写的最清晰的一套之一,至少我看懂了MD5,SHA1的BLOCK数据处理部分了,才动的手。
2 SHA1和MD5的算法说明
SHA1和MD5的算法都是从MD4算法改进而来的2种算法,基本思路都是将信息分成N个分组,每组64个字节,每个分组都进行摘要运算。当一个分组的摘要运算完毕后,将上一个分组的结果也用于下一个分组的运算。
信息的长度(注意是bit位长度,不是字节长度)用64位表示,也要参加信息摘要运算,而且是放在最后一个分组的末尾,所以长度信息要占据8个字节。
如果信息数据最后一个分组长度小于64个字节,在后面添加0x80标志结束,如果此时数据+结束标志已经<=56个字节,还可以放入长度数据,就在结束标志到第56个字节补0,然后放入长度,如果此时信息数据+结束标志已经大于56字节,那么这个分组后面补0,进行一次摘要运算,然后再建立一个分组,前面全部补0,最后16个字节放长度,再进行一次摘要。
需要注意的地方如下。
MD5最后生成的摘要信息是16个字节,SHA1是20个字节。
MD5和SHA1的分组信息运算,分组里面的的数据都会被视为16个DWORD,而MD5算法认为这些DWORD的字节序列是LITTLE-ENDIAN,而SHA1的算法认为DWORD是BIG-ENDIAN的。所以在不同字节序的主机上要进行转换。
放入最后一个分组的长度信息,是原始数据长度,而且是BIT位长度,其是一个uint64_t,而MD5算法要求放入的长度是LITTLE-ENDIAN的,而SHA1算法则要求这个长度是BIG-ENDIAN的。不同的平台要进行转换。
当然生成的结果,MD5也要求是LITTLE-ENDIAN,SHA1也要求结果是BIG-ENDIAN的,不同的平台还是要进行转换。
我们贴几个摘要处理过程的分组信息,帮助大家理解。如果要处理的数据是3个字节字符串”abc”,其在MD5的算法中,只需要一个分组参加,数据是16进制,如下:
61 62 63 80 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 18 00 00 00 00 00 00 00
而SHA1算法中,也只有一个分组,如下,大家注意长度位置上的差别。十六进制的18标识24个bit3个字节。
61 62 63 80 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18
如果要处理的数据是80个字节的"12345678901234567890123456789012345678901234567890123456789012345678901234567890",其在MD5的算易做图被分成2个分组,
第一个分组如下,
31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36
37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32
33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38
39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34
第二个分组如下
35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30
80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 80 02 00 00 00 00 00 00
3 上源码
好了,不罗嗦了,直接上代码,保证清晰可读,注释量足!
为了大家方便,我把代码放入一个文件,在VS2012编译测试通过。
- #include <stdio.h>
- #include <stdint.h>
- #include <string.h>
- #include <assert.h>
- //字节序的小头和大头的问题
- #define ZEN_LITTLE_ENDIAN 0x0123
- #define ZEN_BIG_ENDIAN 0x3210
- //目前所有的代码都是为了小头党服务的,不知道有生之年这套代码是否还会为大头党服务一次?
- #ifndef ZEN_BYTES_ORDER
- #define ZEN_BYTES_ORDER ZEN_LITTLE_ENDIAN
- #endif
- #ifndef ZEN_SWAP_UINT16
- #define ZEN_SWAP_UINT16(x) ((((x) & 0xff00) >> 8) | (((x) & 0x00ff) << 8))
- #endif
- #ifndef ZEN_SWAP_UINT32
- #define ZEN_SWAP_UINT32(x) ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >> 8) | \
- (((x) & 0x0000ff00) << 8) | (((x) & 0x000000ff) << 24))
- #endif
- #ifndef ZEN_SWAP_UINT64
- #define ZEN_SWAP_UINT64(x) ((((x) & 0xff00000000000000) >> 56) | (((x) & 0x00ff000000000000) >> 40) | \
- (((x) & 0x0000ff0000000000) >> 24) | (((x) & 0x000000ff00000000) >> 8) | \
- (((x) & 0x00000000ff000000) << 8 ) | (((x) & 0x0000000000ff0000) << 24) | \
- (((x) & 0x00000
补充:综合编程 , 安全编程 ,