你是不是对MD5算法有误解？

大家常听到“MD5加密”、“对称加密”、“非对称加密”，那么MD5属于哪种加密算法？
面试问这样的问题，准是在给你挖坑。

"MD5加密"纯属口嗨，MD5不是加密算法，是摘要算法。

今天小码甲带大家梳理加密算法、摘要算法的定义和场景：

伸手党先看答案：

加密算法的目的，在于使别人无法成功查看加密的数据，并且在需要的时候还可以对数据进行解密来重新查看数据。

而MD5算法是一种哈希算法，哈希算法的设计目的本身就决定了，它在大多数情况下都是不可逆的，即你通过哈希算法得到的数据，无法经过任何算法还原回去。所以既然不能将数据还原，也就不能称之为解密；既然不能解密，那么哈希的过程自然也就不能称作是[加密]了。

加密算法

加密：是以某种特殊的算法改变原有的信息，使得未授权的用户即使获得已加密的信息，但因不知解密的方法，仍然无法了解信息的内容。

解密：加密的逆过程为解密，即将该加密信息转化为其原来信息的过程。

加密算法分为对称加密和非对称加密，其中对称加密算法的加解密密钥相同，非对称加解密的密钥不同。

HTTPS就同时用到非对称加密和对称加密，在连接建立的阶段，使用非对称加解密(传输密钥)，在通信阶段使用对称密钥加解密数据。

摘要算法，又称哈希算法、散列算法。通过一个函数，将任意长度的内容转换为一个固定长度的数据串。

摘要算法之所以能指出数据是否被篡改，就是因为摘要函数是一个单向函数，计算很容易，但通过摘要(digest) 反推data却非常困难，而且，对于原始数据做一个bit的修改，都会导致计算出的摘要完全不同。

理论上哈希算法都会有哈希冲突：总会有不同的key，通过一个哈希函数，打到一个哈希值上，现在的HMACSHA256的冲突概率极小，sha冲突基本可以忽略。

使用迅雷下载某片的时候，下载站会顺带给你一个MD5校验码；
你找一个MD5校验工具，对下载下来的文件执行MD5算法，将得到的哈希值与下载站附带的MD5值对比，如果值是相同的，说明从该网站下载的文件没有损坏。

延伸聊一个结合了密钥和哈希功能的请求认证方案：
HMAC ( hash-based message authenticated code)

很多第三方平台都采用这种授权认证方案，你回想一下，api平台是不是经常给你一对AppID Serect Key

Client & Server 都知晓一个私钥serect key
客户端每次请求时，会针对(请求数据+ secret key)生成一个hash值
HMAC = hashFunc(secret key + message)
客户端将哈希值做为请求的一部分，一起发送
当服务端收到请求，对( 收到的请求+ 查到的Serectkey')生成哈希，将计算的哈希值与请求中附带的原哈希值对比，如果相同，则认定请求来自受信Client，且请求未被篡改。

为什么会有这样的效果？

首先：Client 和Server的哈希值相同，根据哈希算法的设计初衷，说明请求过程未被篡改；
（还要评估你的高强度哈希函数，忽略可能的哈希冲突）

另一方面也反推 Client 和Server使用了相同的Serect Key , 而Serect Key是私密信息，故此处的Client不可抵赖。

还可以考虑在客户端生成哈希时加入timestamp时间戳（请求还要附带这个时间戳），服务端收到后先对比服务器时间戳与请求时间戳，限制15s内为有效请求，再对（请求信息+ 时间戳+ serectkey)哈希对比，缓解重放攻击。

本文给出的示例： HTTPS、迅雷MD5校验，足够帮助你了解加密算法和摘要算法的设计目的。

以后使用时候也能有的放矢，面试时也不会闹出笑话。

最后给出的WebAPI授权方案HMAC，算是密钥+哈希算法结合的一个应用场景，具备快速、自签名的特点。

原文地址：https://www.cnblogs.com/JulianHuang/p/14858339.html