算法简介
非对称加密（如：RSA）
- 公钥加密数据用私钥解密
- 私钥加密数据用公钥解密
- 密钥不需要传递
- 数学运算效率低，适合加密小字符串
对称加密（如：AES）
- 加密和解密的密钥是相同的
- 效率高
苹果的钥匙串访问
HSAH
- 算法是公开的
- 相同数据运算得到的结果是一样的
- 不同的数据运算，如MD5的导的结果是32个字符串长度的字符串
为什么是32位：MD5运算后得到的是128位的二进制字符串，32位是二进制的十六进制表现形式
散列碰撞：极小概率发生重合 - 无法逆运算
- 如指纹识别技术
只能加密不能解密，严格意义上不算加密
加密算法应用-注册/登录
方式
- 直接将密码明文，传递给服务端。
密码容易被拦截窃取（×）
- 将密码通过密钥加密，传递给服务端。
密钥及数据一旦泄露，用户的密码也将随之被泄露（×）
- 将密码通过HASH运算之后，传递给服务端。
即使数据被泄露，被窃取的是hash之后的字符串，且不可逆，用户的明文密码也不会被泄露（√）
规则：客户端及服务不能保存用户明文密码
如何使用HASH算法进行一次安全的注册登录
- 注册时客户端将用户的密码进行hash运算传递给服务端进行保存，登录时再以同样的的方式传递给服务端由服务端进行验证。
思考：由于相同数据对应的hash运算结果是一样的且不可逆，如果以hash运算结果为key去保存对应的数据，那么我们也可能通过hash运算结果得到原始数据
如：CMD5就保存了一些hash数据
- 加盐
客户端先将一个字符串（盐）拼接到用户的明文密码中再进行hash运算传递给服务端。如用户明文密码是12345后面拼接@##￥%得到12345@##￥%再进行md5加密后得到54efcc63b50c2cd13fcb65f857de7d65再将hash运算后的结果当做密码传递给服务端。
思考：但是需要保证Android、iOS、web等客户端的
盐是一致的且保存在了客户端，存在一些将盐泄漏的隐患，且盐不能更换。
- HMAC
以oc代码为例，通过传入一个key对数据进行加密得到一个hash运算结果
/**
* 计算HMAC MD5散列结果
*
* 终端测试命令：
* @code
* echo -n "string" | openssl dgst -md5 -hmac "key"
* @endcode
*
* @return 32个字符的HMAC MD5散列字符串
*/
- (NSString *)hmacMD5StringWithKey:(NSString *)key {
const char *keyData = key.UTF8String;
const char *strData = self.UTF8String;
uint8_t buffer[CC_MD5_DIGEST_LENGTH];
CCHmac(kCCHmacAlgMD5, keyData, strlen(keyData), strData, strlen(strData), buffer);
return [self stringFromBytes:buffer length:CC_MD5_DIGEST_LENGTH];
}
- (NSString *)hmacSHA1StringWithKey:(NSString *)key;
- (NSString *)hmacSHA256StringWithKey:(NSString *)key;
- (NSString *)hmacSHA512StringWithKey:(NSString *)key;
由服务端生成key，发送给客户端，客户端再通过key对密码进行加密发送给服务端，即使key被泄露服务端也可以通过更换key进行补救。
衍生业务
- 服务端可以通过定时更换key来保证安全性（如某些网站过段时间会让用户再次登录）
- 设备认证：客户端可以通过查看本地是否保存key，来判断当前设备是否是可信任的设备，如果不是需要用户手动认证。只有认证设备服务端才会将key发送给客户端。（iOS端可以将key保存到钥匙串中）
思考：前面的加密流程看似很安全了，但是如果黑客通过WiFi等工具窃取了客户端发送给服务端的加密密码，再通过加密密码直接模拟一次用户登录，那么我们前面无论做了什么方式的加密也将无济于事。
我们也可以制定自己的规则，如：对key进行rsa加密
- 时间戳
- 客户端在登录时将（
HMAC密码+当前时间戳）进行一次hash运算生成密码，再发送给服务端。 - 由于在注册时服务端已经保存了用户的HMAC密码，服务端再以同样的方式对
HMAC密码进行加密，再将结果与客户端发送过来的密码进行对比。 - 如果不一致，服务端可将时间戳向前调一分钟再进行加密对比。
这样及时被黑客窃取到了加密密码，也是当时时间戳下的密码，最多1分59秒后，这个加密密码也将失效，除非黑客能在1分59秒内窃取到密码，并且向前调一分钟的规则是由服务端决定的，服务端也可将时长调更短。
时间戳是由用服务端发送给客户端，防止客户端本地时间被更改
加密算法应用-拓展
AES+RSA
- 如果直接用对称加密对数据进行加密，客户端和服务端需要统一密钥并保存到本地，由于加密和解密的密钥是相同的一旦一端被泄露数据将存在隐患。
- 如果直接通过网络发送密钥，依然存在被截获的风险。
- 如果使用RSA对数据进行加密，由于数据量庞大效率将会降低。
- 由于密钥只是一个简单的数据，所以可以使用RSA对AES的密钥进行加密，然后传输。
和https的网络安全协议类似
RSA+HASH（数字签名）
如：客户端生成了一个订单信息要发送给服务端进行验证和扣款。
- 客户端将订单信息通过hash算法进行加密，然后又将得到的hash值通过rsa进行加密，最后连同原始数据一起发送给服务端。
- 服务端收到订单信息后，为了验证订单信息是否被篡改，先将加密后的数据通过rsa进行解密得到hash值，同时将原始数据用客户端同样的hash算法进行加密，再将得到的hash值与解密后的hash值进行比较，如果相等则订单数据未被篡改。
订单数据属于庞大数据不能直接使用rsa。
由于hash算法是公开的，如果只用hash加密，被黑客拦截到数据后黑客也可能会将篡改后的订单信息使用同样的hash算法进行加密。
引申
逆向：有时客户端的原始数据是可以通过逆向汇编等操作调试出来的
