数据安全及各种加密算法对比

平时开发中不仅会遇到各种需要保护用户隐私的情况，而且还有可能需要对公司核心数据进行保护，这时候加密隐私数据就成为了必要。然而市场上存在着各种各样的抓包工具及解密算法，甚至一些公司有专门的逆向部门，这就加大了数据安全的风险，本文将通过以下几个方面对各种加密算法进行分析对比：

  • Base64编码（基础）
  • 单项散列函数 MD5、SHA1、SHA256、SHA512等
  • 消息认证码 HMAC-MD5、HMAC-SHA1
  • 对称加密 DES|3DES|AES（高级加密标准）
  • 非对称加密 RSA
  • 数字签名
  • 证书

通常我们对消息进行加解密有两种处理方式：

  1. 只需要保存一个值，保证该值得机密性，不需要知道原文（用户登录）
  2. 除了保证机密性外还需要对加密后的值进行解密得到原文

Base64编码

由于我们可能对各种各样的数据进行加密，比如：视频、音频、文本文件等，所以加密之前我们需要统一文件类型，然后再进行加密处理。

  • Base64编码
// 要编码的字符串
NSString *str = @"haha";

// 转换成二进制文件
NSData *data = [str dataUsingEncoding:NSUTF8StringEncoding];

// 进行base64编码
NSString *dataStr = [data base64EncodedStringWithOptions:kNilOptions];

NSLog(@"%@", dataStr);
  • Base64解码
// 先对数据进行解码
NSData *encData = [[NSData alloc]initWithBase64EncodedString:dataStr options:kNilOptions];
    
// 将二进制数据转换成字符串
NSString *encStr = [[NSString alloc]initWithData:encData encoding:NSUTF8StringEncoding];
    
NSLog(@"%@", encStr);

接下来分析一下Base64的编码过程，参考维基百科：

image

如果要编码的字节数不能被3整除，最后会多出1个或2个字节，那么可以使用下面的方法进行处理：先使用0字节值在末尾补足，使其能够被3整除，然后再进行Base64的编码。在编码后的Base64文本后加上一个或两个=号，代表补足的字节数。也就是说，当最后剩余两个八位字节（2个byte）时，最后一个6位的Base64字节块有四位是0值，最后附加上两个等号；如果最后剩余一个八位字节（1个byte）时，最后一个6位的base字节块有两位是0值，最后附加一个等号。 参考下表：

image
  • Base64编码原理
  1. 将所有字符串转换成ASCII码
  2. 将ASCII码转换成8位二进制
  3. 将二进制三位归成一组（不足三位在后边补0），再按每组6位，拆成若干组
  4. 统一在6位二进制后不足8位的补0
  5. 将补0后的二进制转换成十进制
  6. 从Base64编码表取出十进制对应的Base64编码

若原数据长度不是3的倍数时且剩下1个输入数据，则在编码结果后加2个=；若剩下2个输入数据，则在编码结果后加1个=

如上面的例子：

原数据为A，数据长度为1，1 % 3 = 1 后面加两个==

原数据为bc，数据长度为2，2 % 3 = 2 后面加一个=

  • Base64编码的特点
  1. 可以将任意的二进制数据进行Base64编码。
  2. 所有的数据都能被编码为并只用65个字符就能表示的文本文件。
  3. 编码后的65个字符包括AZ,az,0~9,+,/,=
  4. 对文件或字符串进行Base64编码后将比原始大小增加33%。
  5. 能够逆运算
  6. 不够安全，但却被很多加密算法作为编码方式

单项散列函数

单向散列函数也称为消息摘要函数、哈希函数或者杂凑函数。
单向散列函数输出的散列值又称为消息摘要或者指纹

特点：

  1. 对任意长度的消息散列得到散列值是定长的
  2. 散列计算速度快，非常高效
  3. 消息不同，则散列值一定不同
  4. 消息相同，则散列值一定相同
  5. 具备单向性，无法逆推计算

经典算法：

  • MD4、MD5、SHA1、SHA256、SHA512等

安全性：

  • md5解密网站：http://www.cmd5.com
  • MD5的强抗碰撞性已经被证实攻破，即对于重要数据不应该再继续使用MD5加密。

疑问一：单项散列函数为什么不可逆？？

原来好多同学知识知道md5加密是不可逆的，却不知道是为什么，其实散列函数可以将任意长度的输入经过变化得到不同的输出，如果存在两个不同的输入得到了相同的散列值，我们称之为这是一个碰撞，因为使用的hash算法，在计算过程中原文的部分信息是丢失了的，一个MD5理论上可以对应多个原文，因为MD5是有限多个，而原文是无限多个的。

网上看到一个形象的例子：2 + 5 = 7，但是根据 7 的结果，却并不能推算出是由 2 + 5计算得来的

疑问二：为什么有些网站可以解密MD5后的数据？？

MD5解密网站，并不是对加密后的数据进行解密，而是数据库中存在大量的加密后的数据，对用户输入的数据进行匹配（也叫暴力碰撞），匹配到与之对应的数据就会输出，并没有对应的解密算法。

MD5改进

由以上信息可以知道，MD5加密后的数据也并不是特别安全的，其实并没有绝对的安全策略，我们可以对MD5进行改进，加大破解的难度，典型的加大解密难度的方式有一下几种：

  1. 加盐（Salt）：在明文的固定位置插入随机串，然后再进行MD5
  2. 先加密，后乱序：先对明文进行MD5，然后对加密得到的MD5串的字符进行乱序
  3. 先乱序，后加密：先对明文字符串进行乱序处理，然后对得到的串进行加密
  4. 先乱序，再加盐，再MD5等
  5. HMac消息认证码

也可以进行多次的md5运算，总之就是要加大破解的难度。

Hmac消息认证码（对MD5的改进）

原理：

  1. 消息的发送者和接收者有一个共享密钥
  2. 发送者使用共享密钥对消息加密计算得到MAC值（消息认证码）
  3. 消息接收者使用共享密钥对消息加密计算得到MAC值
  4. 比较两个MAC值是否一致

使用：

  1. 客户端需要在发送的时候把（消息）+（消息·HMAC）一起发送给服务器
  2. 服务器接收到数据后，对拿到的消息用共享的KEY进行HMAC，比较是否一致，如果一致则信任
image

对称加密算法

对称加密的特点：

  • 加密/解密使用相同的密钥
  • 是可逆的

经典算法：

  • DES 数据加密标准
  • 3DES 使用3个密钥，对消息进行（密钥1·加密）+（密钥2·解密）+（密钥3·加密）
  • AES 高级加密标准

密码算法可以分为分组密码和流密码两种：

  • 分组密码：每次只能处理特定长度的一zu数据的一类密码算法。一个分组的比特数量就称之为分组长度。
  • 流密码：对数据流进行连续处理的一类算法。流密码中一般以1比特、8比特或者是32比特等作为单位俩进行加密和解密。

分组模式：主要有两种

  • ECB模式(又称电子密码本模式)
    • 使用ECB模式加密的时候，相同的明文分组会被转换为相同的密文分组。
    • 类似于一个巨大的明文分组 -> 密文分组的对照表。
image

某一块分组被修改，不影响后面的加密结果

  • CBC模式(又称电子密码链条)

    • 在CBC模式中，首先将明文分组与前一个密文分组进行XOR(异或)运算，然后再进行加密。
    • 每一个分组的加密结果依赖需要与前一个进行异或运算，由于第一个分组没有前一个分组，所以需要提供一个初始向量iv
    image

某一块分组被修改，影响后面的加密结果

代码演示两种分组模式

  • AES - ECB模式

加密：

    /**
     *  加密字符串并返回base64编码字符串
     *
     *  @param string    要加密的字符串
     *  @param keyString 加密密钥
     *  @param iv        初始化向量(8个字节)
     *
     *  @return 返回加密后的base64编码字符串
     */
    NSLog(@"%@", [[EncryptionTools sharedEncryptionTools] encryptString:@"haha" keyString:@"abc" iv:nil]);
    
    // 输出 MIoAu+xUEpQZSUmkZUW6JQ==

解密：

NSLog(@"%@", [[EncryptionTools sharedEncryptionTools] decryptString:@"MIoAu+xUEpQZSUmkZUW6JQ==" keyString:@"abc" iv:nil]);
    
// 输出 haha
  • AES - CBC模式

加密：

uint8_t iv[8] = {1,2,3,4,5,6,7,8};

NSData *data = [[NSData alloc] initWithBytes:iv length:sizeof(iv)];

NSLog(@"%@", [[EncryptionTools sharedEncryptionTools] encryptString:@"haha" keyString:@"abc" iv:data]);
    
// 输出 E/wWqUTiw/E+1DThAzV39A==

解密：

NSLog(@"%@", [[EncryptionTools sharedEncryptionTools] decryptString:@"E/wWqUTiw/E+1DThAzV39A==" keyString:@"abc" iv:data]);
    
// 输出 haha

对称加密存在的问题？？

很明显，对称加密主要取决于秘钥的安全性，数据传输的过程中，如果秘钥被别人破解的话，以后的加解密就将失去意义

image

其实有点儿类似于我们平常看的谍战类的电视剧，地下党将情报发送给后方，通常需要一个中间人将密码本传输给后方，如果中间人被抓交出密码本，那么将来所有的情报都将失去意义，由此可见情报工作多么的重要！！！

对称密码体制中只有一种密钥，并且是非公开的，如果要解密就得让对方知道密钥。所以保证其安全性就是保证密钥的安全，而非对称密钥体制有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了

非对称加密

鉴于对称加密存在的风险，非对称加密应运而生

特点：

  • 使用公钥加密，使用私钥解密
  • 公钥是公开的，私钥保密
  • 加密处理安全，但是性能极差

非对称密码体制的特点：算法强度复杂、安全性依赖于算法与密钥，但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快

经典算法：

  • RSA
RSA算法原理
* 求N，准备两个质数p和q,N = p x q
* 求L,L是p-1和q-1的最小公倍数。L = lcm（p-1,q-1）
* 求E，E和L的最大公约数为1（E和L互质）
* 求D，E x D mode L = 1
RSA加密实践
* p = 17,q = 19 =>N = 323
* lcm（p-1,q-1）=>lcm（16，18）=>L= 144
* gcd（E,L）=1 =>E=5
* E乘以几可以mode L =1? D=29可以满足
* 得到公钥为：E=5,N=323
* 得到私钥为：D=29,N=323
* 加密 明文的E次方 mod N = 123的5次方 mod 323 = 225（密文）
* 解密 密文的D次方 mod N = 225的29次方 mod 323 = 123（明文）
openssl生成密钥命令
  • 生成强度是 512 的 RSA 私钥：$ openssl genrsa -out private.pem 512
  • 以明文输出私钥内容：$ openssl rsa -in private.pem -text -out private.txt
  • 校验私钥文件：$ openssl rsa -in private.pem -check
  • 从私钥中提取公钥：$ openssl rsa -in private.pem -out public.pem -outform PEM -pubout
  • 以明文输出公钥内容：$ openssl rsa -in public.pem -out public.txt -pubin -pubout -text
  • 使用公钥加密小文件：$ openssl rsautl -encrypt -pubin -inkey public.pem -in msg.txt -out msg.bin
  • 使用私钥解密小文件：$ openssl rsautl -decrypt -inkey private.pem -in msg.bin -out a.txt
  • 将私钥转换成 DER 格式：$ openssl rsa -in private.pem -out private.der -outform der
  • 将公钥转换成 DER 格式：$ openssl rsa -in public.pem -out public.der -pubin -outform der
非对称加密存在的安全问题

原理上看非对称加密非常安全，客户端用公钥进行加密，服务端用私钥进行解密，数据传输的只是公钥，原则上看，就算公钥被人截获，也没有什么用，因为公钥只是用来加密的，那还存在什么问题呢？？那就是经典的中间人攻击

image

废了半天劲画的图，太low了，我还是自己总结一遍吧！！！

中间人攻击详细步骤：

  1. 客户端向服务器请求公钥信息
  2. 服务端返回给客户端公钥被中间人截获
  3. 中间人将截获的公钥存起来
  4. 中间人自己伪造一套自己的公钥和私钥
  5. 中间人将自己伪造的公钥发送给客户端
  6. 客户端将重要信息利用伪造的公钥进行加密
  7. 中间人获取到自己公钥加密的重要信息
  8. 中间人利用自己的私钥对重要信息进行解密
  9. 中间人篡改重要信息（将给客户端转账改为向自己转账）
  10. 中间人将篡改后的重要信息利用原来截获的公钥进行加密，发送给服务器
  11. 服务器收到错误的重要信息（给中间人转账）

疑问一：为什么会造成中间人攻击？？

造成中间人攻击的直接原因就是客户端没办法判断公钥信息的正确性。

疑问二：怎么解决中间人攻击？？

需要对公钥进行数字签名。就像古代书信传递，家人之所以知道这封信是你写的，是因为信上有你的签名、印章等证明你身份的信息。

数字签名需要严格验证发送发的身份信息！！！

数字证书

数字证书包含：

  • 公钥
  • 认证机构的数字签名（权威机构CA）

数字证书可以自己生成，也可以从权威机构购买，但是注意，自己生成的证书，只能自己认可，别人都不认可.

权威机构签名的证书：
以GitHub官网为例，Chrome浏览器打开网址，地址栏有一个小绿锁，点击，内容如下：

权威机构认证的证书：

image

可以看到连接是安全的，点击证书可以看到详细信息


image

这是由权威机构认证的证书，但是是需要花钱的，一年至少得一两千，所以也有些公司用自己签名的证书，自己签名的证书不被信任，可能会提示用户有风险，比如原来的12306网站，现在大多数网站也都采用了CA签名数字证书进行签名，自己做签名的也不好找了！！！12306都改成CA认证的了。。。

自己生成一个证书

  • 生成私钥
openssl genrsa -out private.pem 1024
  • 创建证书请求
openssl req -new -key private.pem -out rsacert.csr
  • 生成证书并签名，有效期10年
openssl x509 -req -days 3650 -in rsacert.csr -signkey private.pem -out rsacert.crt
  • 将 PEM 格式文件转换成 DER 格式
openssl x509 -outform der -in rsacert.crt -out rsacert.der
  • 导出P12文件
openssl pkcs12 -export -out p.p12 -inkey private.pem -in rsacert.crt
image

注意：

  • 在iOS开发中，不能直接使用 PEM 格式的证书，因为其内部进行了Base64编码，应该使用的是DER的证书，是二进制格式的
  • OpenSSL默认生成的都是PEM格式的证书

代码演示：

// p12 是私钥
    // .der 是公钥
    // 非对称加密，使用公钥加密，私钥解密
    
    // 加载公钥
    [[RSACryptor sharedRSACryptor] loadPublicKey:[[NSBundle mainBundle] pathForResource:@"rsacert.der" ofType:nil]];
    
    // 对数据加密
    NSData *data = [[RSACryptor sharedRSACryptor] encryptData:[@"hahaha" dataUsingEncoding:NSUTF8StringEncoding]];
    
    // 对加密得到的密文进行base64编码打印
    NSLog(@"%@", [data base64EncodedStringWithOptions:kNilOptions]);
    
    // 输出结果：PflhCgTVNegcQXrb39RJOoxCRRIHuZ3LN0/hoxTDFBbC+8yKjp0m+/hxVUWBVsTo28WnNFCAFfrQ2of5SkqttD51a5eLb21R7bQSQRxg/gVZ5hePcE3vh7Slfcxm2qJM+J8hRWDP/MF4BiDLXI9ZqTpLCSS5mjJtmUBf2wNvI1Y=
    
    // 私钥解密
    
    // 加载私钥
    [[RSACryptor sharedRSACryptor] loadPrivateKey:[[NSBundle mainBundle] pathForResource:@"p.p12" ofType:nil] password:@"123456"];

    // 解密
    NSData *decryDeta = [[RSACryptor sharedRSACryptor] decryptData:data];
    
    NSLog(@"%@", [[NSString alloc] initWithData:decryDeta encoding:NSUTF8StringEncoding]);
    
    // 输出：hahaha

代码地址

总结

至此数据安全和加解密相关结算完毕，写博客的过程，也是学习的过程，断断续续的写了三四天，总算写完了，同时也对原来一些模糊的概念有了更清晰的认识，写的这篇文章看了文顶顶老师的视频，受益匪浅，十分感谢，最近学习发现，学的越多，感觉会的越少，时间十分的不够用。同时渴望遇到一些希望进步、不甘平凡的同行！！！共勉！！！

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 206,214评论 6赞 481
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 88,307评论 2赞 382
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 152,543评论 0赞 341
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 55,221评论 1赞 279
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 64,224评论 5赞 371
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,007评论 1赞 284
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,313评论 3赞 399
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,956评论 0赞 259
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 43,441评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,925评论 2赞 323
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,018评论 1赞 333
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,685评论 4赞 322
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,234评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,240评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,464评论 1赞 261
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,467评论 2赞 352
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,762评论 2赞 345