我们在以下这篇中
就说到了 hash 加密
由于它是一种
单向、不可逆的函数
所以即使我们拿到了加密后的指纹
也很难推算出原文
小帅b记得之前在做电商项目时
有一个用户注册登录的功能
就用到了这种加密方式
一般来说
用户通过用户名密码注册
在数据库是不会存储
用户的明文密码的
需要在代码中给
用户的密码进行加密
也就是说
当用户在注册时提交自己的密码
后端需要将用户传来的密码 + salt 进行加密
salt是一个随机数
将它与用户密码结合起来生成密文
在数据库保存用户的密文和 salt
而不保存用户的明文密码
这样
就只有用户知道自己的密码
在数据库中只存储
加密后的密文和对应的 salt
那么下次用户登录的时候
就将它的密码 + salt 进行 hash
如果结果和数据库存储的密文一致
那么就可以登录了
ok
我们回到上篇文末提到的问题
如果小帅b伪装成你
发布文件给你的朋友
怎么办？
为了让你更加容易理解
我接下来给你讲的东西
我来做个假设吧
假设这个是你：
假设这是你女票：
你写了一封信
想要发给你的女票
但是你怕你被小帅b伪造成是你发出的信
你想要确保让你的女票知道信就是从你这来的
于是你用了数字签名
将你的信先用 hash 生成指纹（digest）
然后在用你的私钥加密生成数字签名（signature）
这个时候
你就将你的数字签名和信一起发给你的女票
当你的女票收到信之后想要确保两件事
这时候你女票拿到了你发来的数字签名
用你的公钥进行解密
接着你的女票又通过信的内容进行 hash
可以通过你的公钥解密又将内容进行 hash 得到的指纹对比相同
说明你女票收到的这封信是由你发出的也没有被篡改过
有一天晚上
小帅b偷偷的换掉了你女票的公钥
也就是说原本她有的是你的公钥
但现在你的公钥被换成我的公钥了
而你的女票用着假公钥还笑嘻嘻
小帅b用自己的私钥生成数字签名
然后给你的女票发了这样的信
这时候你女票还是用上述的操作获得了指纹和验证信的内容
因为她用的是我的公钥
所以她以为你是发的内容感觉万念俱灰
而你却
百口莫辩
后来在你的软磨硬泡之下
你的女票原谅你了
但是你想啊
挖槽不能继续背锅啊
于是你想到了一个办法你去证书中心（CA）
给你的公钥做了一个认证
也就是说证书中心用他们的私钥
给你的公钥相关消息进行加密生成一个证书
那么当你下次再给你女票发信息的时候
就将证书一起携带过去
那么当你女票收到你的信息之后
她就可以通过数字证书拿到你被认证了的公钥
从而确定这就是你发过来的没有被伪造过的内容了
这就是数字签名相关的希望对你有帮助
peace
