我們在以下這篇中
就說到了 hash 加密
由於它是一種
單向、不可逆的函數
所以即使我們拿到了加密後的指紋
也很難推算出原文
小帥b記得之前在做電商項目時
有一個用戶註冊登錄的功能
就用到了這種加密方式
一般來說
用戶通過用戶名密碼註冊
在數據庫是不會存儲
用戶的明文密碼的
需要在代碼中給
用戶的密碼進行加密
也就是說
當用戶在註冊時提交自己的密碼
後端需要將用戶傳來的密碼 + salt 進行加密
salt是一個隨機數
將它與用戶密碼結合起來生成密文
在數據庫保存用戶的密文和 salt
而不保存用戶的明文密碼
這樣
就只有用戶知道自己的密碼
在數據庫中只存儲
加密後的密文和對應的 salt
那麼下次用戶登錄的時候
就將它的密碼 + salt 進行 hash
如果結果和數據庫存儲的密文一致
那麼就可以登錄了
ok
我們回到上篇文末提到的問題
如果小帥b僞裝成你
發佈文件給你的朋友
怎麼辦？
爲了讓你更加容易理解
我接下來給你講的東西
我來做個假設吧
假設這個是你：
假設這是你女票：
你寫了一封信
想要發給你的女票
但是你怕你被小帥b僞造成是你發出的信
你想要確保讓你的女票知道信就是從你這來的
於是你用了數字簽名
將你的信先用 hash 生成指紋（digest）
然後在用你的私鑰加密生成數字簽名（signature）
這個時候
你就將你的數字簽名和信一起發給你的女票
當你的女票收到信之後想要確保兩件事
這時候你女票拿到了你發來的數字簽名
用你的公鑰進行解密
接着你的女票又通過信的內容進行 hash
可以通過你的公鑰解密又將內容進行 hash 得到的指紋對比相同
說明你女票收到的這封信是由你發出的也沒有被篡改過
有一天晚上
小帥b偷偷的換掉了你女票的公鑰
也就是說原本她有的是你的公鑰
但現在你的公鑰被換成我的公鑰了
而你的女票用着假公鑰還笑嘻嘻
小帥b用自己的私鑰生成數字簽名
然後給你的女票發了這樣的信
這時候你女票還是用上述的操作獲得了指紋和驗證信的內容
因爲她用的是我的公鑰
所以她以爲你是發的內容感覺萬念俱灰
而你卻
百口莫辯
後來在你的軟磨硬泡之下
你的女票原諒你了
但是你想啊
挖槽不能繼續背鍋啊
於是你想到了一個辦法你去證書中心（CA）
給你的公鑰做了一個認證
也就是說證書中心用他們的私鑰
給你的公鑰相關消息進行加密生成一個證書
那麼當你下次再給你女票發信息的時候
就將證書一起攜帶過去
那麼當你女票收到你的信息之後
她就可以通過數字證書拿到你被認證了的公鑰
從而確定這就是你發過來的沒有被僞造過的內容了
這就是數字簽名相關的希望對你有幫助
peace
更多相關
