你怕是對MD5算法有誤解
本文轉(zhuǎn)載自微信公眾號「精益碼農(nóng)」，作者有態(tài)度的馬甲。轉(zhuǎn)載本文請聯(lián)系精益碼農(nóng)公眾號。
"MD5加密"純屬口嗨，MD5不是加密算法，是摘要算法。
今天小碼甲帶大家梳理加密算法、摘要算法的定義和場景：
伸手黨先看答案：
加密算法的目的，在于使別人無法成功查看加密的數(shù)據(jù)，并且在需要的時(shí)候還可以對數(shù)據(jù)進(jìn)行解密來重新查看數(shù)據(jù)。
而MD5算法是一種哈希算法，哈希算法的設(shè)計(jì)目的本身就決定了，它在大多數(shù)情況下都是不可逆的，即你通過哈希算法得到的數(shù)據(jù)，無法經(jīng)過任何算法還原回去。所以既然不能將數(shù)據(jù)還原，也就不能稱之為解密;既然不能解密，那么哈希的過程自然也就不能稱作是[加密]了。
加密算法
加密：是以某種特殊的算法改變原有的信息，使得未授權(quán)的用戶即使獲得已加密的信息，但因不知解密的方法，仍然無法了解信息的內(nèi)容。
解密：加密的逆過程為解密，即將該加密信息轉(zhuǎn)化為其原來信息的過程。
加密算法分為對稱加密和非對稱加密，其中對稱加密算法的加解密密鑰相同，非對稱加解密的密鑰不同。
HTTPS就同時(shí)用到非對稱加密和對稱加密，在連接建立階段，使用非對稱加解密(保護(hù)密鑰不被查看)， 在通信階段使用對稱密鑰加解密數(shù)據(jù)。
摘要算法
摘要算法，又稱哈希算法、散列算法。通過一個(gè)函數(shù)，將任意長度的內(nèi)容轉(zhuǎn)換為一個(gè)固定長度的數(shù)據(jù)串。
摘要算法之所以能指出數(shù)據(jù)是否被篡改，就是因?yàn)檎瘮?shù)是一個(gè)單向函數(shù)，計(jì)算很容易，但通過摘要(digest) 反推data卻非常困難，而且，對于原始數(shù)據(jù)做一個(gè)bit的修改，都會導(dǎo)致計(jì)算出的摘要完全不同。
使用迅雷下載某片的時(shí)候，下載站會順帶給你一個(gè)MD5校驗(yàn)碼;
你找一個(gè)MD5校驗(yàn)工具，對下載下來的文件執(zhí)行MD5算法，將得到的哈希值與下載站附帶的MD5值對比，如果值是相同的，說明從該網(wǎng)站下載的文件沒有損壞。
HMAC
延伸聊一個(gè)結(jié)合了密鑰和哈希功能的請求認(rèn)證方案：
HMAC ( hash-based message authenticated code)
很多第三方平臺都采用這種授權(quán)認(rèn)證方案，你回想一下，api平臺是不是經(jīng)常給你一對AppID Serect Key
1.Client & Server 都知曉一個(gè)私鑰serect key
2.客戶端每次請求時(shí)，會針對(請求數(shù)據(jù)+ secret key)生成一個(gè)hash值
HMAC = hashFunc(secret key + message)
3.客戶端將哈希值做為請求的一部分，一起發(fā)送
4.當(dāng)服務(wù)端收到請求， 對( 收到的請求+ 查到的Serectkey')生成哈希，將計(jì)算的哈希值與請求中附帶的原哈希值對比，如果相同，則認(rèn)定請求來自受信Client，且請求未被篡改。
為什么會有這樣的效果?
首先：Client 和Server的哈希值相同，根據(jù)哈希算法的設(shè)計(jì)初衷，說明請求過程未被篡改;
另一方面也反推 Client 和Server使用的是同一個(gè)Serect Key , 而Serect Key是私密信息，故此處的Client發(fā)送請求不可抵賴。
還可以考慮在客戶端生成哈希時(shí)加入timestamp時(shí)間戳(請求也要附帶這個(gè)時(shí)間戳)，服務(wù)端收到后，先對比服務(wù)器時(shí)間戳與請求時(shí)間戳，限制15s內(nèi)為有效請求，服務(wù)端再對(請求消息+ serect key+ timestamp)生成哈希，對比哈希，避免重放攻擊。
總結(jié)
本文給出的示例：HTTPS、迅雷MD5校驗(yàn)，足夠幫助你了解加密算法和摘要算法的設(shè)計(jì)目的。
?加密算法的目的是：防止信息被偷看?摘要算法的目的是：防止信息被篡改
以后使用時(shí)候也能有的放矢，面試時(shí)也不會鬧出笑話。
最后給出的WebAPI授權(quán)方案HMAC，算是密鑰+哈希算法結(jié)合的一個(gè)應(yīng)用場景， 具備快速、自簽名的特點(diǎn)。
