MD5的坑

2017-03-24  本文已影响0人  Hflydragon
   MD5 这种加密算法应该属于每天都要被用到的东西,然而,iOS 只提供了这个方法给我们使用。

extern unsigned char *CC_MD5(const void *data, CC_LONG len, unsigned char *md)

   于是,在这个方法下面 我发现了各种坑 
    先开看看 NSString 的 MD5 Category:

import "NSString+Md5.h"

import <CommonCrypto/CommonCrypto.h>

@implementation NSString (Md5)

@end

   对于 NSData 的一个 Category:

import "NSData+Md5.h"

import <CommonCrypto/CommonCrypto.h>

@implementation NSData (Md5)

@end

   粗略一看 也许这2个 Category 只是 NSString 和 NSData 的区别,本质区别并不大。但是 。。你注意到了吗?对于 NSString 在使用 CC_MD5 函数的时候,传入的参数是 strlen(str),对于 NSData 传入的参数是 self.length,一个使用了 C 的方法,一个使用了 Objective-C 的方法。这是一个大坑。。如果稍不注意就会挂。。而且。。根本查不到问题的所在。。 Why? 
   让我们先看看 NSString,由于 CC_MD5 是一个 C 的函数,但是 在使用 NSString 的时候,NSString 的 length 函数对字符转义进行过了处理,对于普通的字符并没有太大的区别,但是 遇到中文的时候就要跪了,让我们看看下面的例子
NSString *test = @"我";
NSLog(@"%lu",(unsigned long)test.length);

const char *cTest = [test UTF8String];
NSLog(@"%lu",strlen(cTest));

   前者输出了 1 后者输出了 3, 这其实是很正常的现象,因为一个中文占了3个字节,苹果对 length 进行了处理,所以,在使用 length 的时候,你获取到的汉字的长度是1,让我们在看看这个例子:
NSLog(@"%c",[test characterAtIndex:0]);
NSLog(@"%@",[test substringWithRange:NSMakeRange(0, 1)]);

   相信很多人也都踩过这个坑 苹果文档中还特意声明 Use with rangeOfComposedCharacterSequencesForRange: to avoid breaking up composed characters , 使用这个方法可以避免字符串被中间切断,也就是在上面两个NSLog中,前者输入了乱码,后者输出了汉字“我”. 
   好了,这个坑的解释基本就到这里了,在使用 NSString 的时候,因为 CC_MD5 是一个C函数,而 NSString 提供的 length 函数被处理过后,汉字或者一些其他鬼字符的长度和 strlen 计算出来的不一样了,于是导致了这样一个大坑。 
   接下来,我们看看 NSData,在 NSData 中,我们计算 CC_MD5 的时候,传入的长度是 self.length,而不再是 strlen() 计算出来的, 让我们看看下面的例子:
NSString *test = @"aaa\0bbb";
NSLog(@"%lu",(unsigned long)test.length);

const char *cTest = [test UTF8String];
NSLog(@"%lu",strlen(cTest));

   前者输出了7 后者只输出了3,原因是 char 的数组在遇到'\0'的时候,认为这个字符串已经结束了,因此 将不在对 bbb 做处理了,而用 strlen 计算出来的长度只有3了。到这里 你甚至可能会和我一样疑惑,按照这样的说法,上述用 NSString 传入计算 MD5 的长度正确吗?我只能说 幸运的是在正常的 NSString 中 我们不会出现'\0'这样的变态字符,除非是你自己刻意去拼出一个这样的字符. 
   接下来该回到 NSData 了,会用 NSData 去计算 MD5 通常是通过文件或者音频、图片等转化过来的,因此,在 data 中什么都有可能出现,如果我没有记错的话,字符'\0'被转化成二进制应该是 0000 00000之类的东西,这时候,如果你的 NSData 是通过压缩或者其他方式得到的,就很有可能出现一个这样的二进制 .....0000......(意思就是 二进制的一串中包含了一些特殊的字符,相当于转化成String被识别成了'\0'),于是 这时候,你再用strlen计算,就只会计算.....0000这么多了,后面的就完全忽略了,于是 这样一个潜在的bug就出现了。 举个例子来说:我们分别利用 NSString 和将 String 转化为 NSData 的字符串@“aaa”去计算各自的 MD5

NSString *test = @"aaa";
NSLog(@"%@",[test md5StringStr]);
NSData *data = [test dataUsingEncoding:NSUTF8StringEncoding];
NSLog(@"%@",[data md5String]);

   计算出来的结果一样 都是 47bce5c74f589f4867dbd57e9ca9f808 
   但是 当我们把字符串改成@"aaa\0bbb" ('\0')起到了决定性的因素
NSString *test = @"aaa\0bbb";
NSLog(@"%@",[test md5StringStr]);
NSData *data = [test dataUsingEncoding:NSUTF8StringEncoding];
NSLog(@"%@",[data md5String]);

   在看看结果 NSString 算出来的是 47bce5c74f589f4867dbd57e9ca9f808(和上面的一样), 但是 NSData 算出来的是 ea21d344ad21e7cc63e5d4480f76dc83,这时候 你看出区别了把,两个不同的字符串,用NSString 那个 Category 方法算出来的结果是一样的,但是 用N SData 那个 Category 算出来却有了明显的区别,到底哪个正确,你应该可以自己判断了把。 
   在正常的情况下,我们习惯于去写 NSString 那个 Category 的 MD5,因为在正常的情况下,用它计算出来的结果都是正确的,但是 如果你自己去拼接一种带有'\0'的特殊字符串,那么这样计算出来的 MD5 结果就出现了问题;另外,由于 NSData 通常是由你的图片或者音频等转化过来的,所以 你使用NSData计算MD5带入的二进制很有可能直接包含了'\0'等变态字符,这时候,使用NSData的length方法可以有效的避免这个问题。 
   所以,在我看来最安全的 MD5 计算方法应该是将 NSString 转化为 NSData,然后通过 NSData 去计算,代码如下(还是2个 Category): 

//NSData 的 MD5 方法不变

import "NSData+Md5.h"

import <CommonCrypto/CommonCrypto.h>

@implementation NSData (Md5)

@end

//NSString 的 MD5 转化为 NSData,通过 NSData 的 MD5 计算返回结果

import "NSString+Md5.h"

import "NSData+Md5.h"

@implementation NSString (Md5)

@end

上一篇下一篇

猜你喜欢

热点阅读