哈希、对称_非对称加密、数字签名，一次性讲清

不管是做用户密码存储、文件完整性校验、接口幂等设计还是HTTPS通信、支付回调验签、敏感信息加密总会绕不开哈希、加密、签名这些概念。本文就把这些东西一次性理清楚分清楚每个技术的核心作用、主流算法以及适用场景。单向哈希摘要算法不管你输入多长的内容它都能生成固定长度的哈希摘要字符串相同的输入永远会得到完全相同的输出最关键的是它单向不可逆也就是说你没法从生成的哈希摘要反推出原来的原始数据。理论上它存在哈希碰撞的概率也就是两个不同的输入生成了相同的哈希值但在正常的生产环境里这个概率可以完全忽略不计。主流算法不安全已淘汰MD5、SHA-1已经被证实存在高效哈希碰撞的手段安全场景绝对不能用生产环境推荐SHA-256、SHA-512、bcrypt、Argon2、国密SM3业务场景举例1. 用户密码存储如果用 SHA-256 这类普通哈希算法需要先生成全局唯一的随机盐值salt把【用户密码 salt】拼接后做哈希运算最终把哈希值盐值一起存入数据库如果用 bcrypt/Argon2 这类慢哈希算法不用自己手动生成盐算法会内置随机盐并且自动把盐嵌入到最终的哈希结果里直接传入用户密码生成哈希值最终只需要把这一个哈希值存入数据库就行。登录校验的逻辑也很简单用户提交账号密码后后端根据账号从数据库取出对应的哈希值SHA系列还要单独取出盐值用相同的算法对用户输入的密码做哈希比对两个哈希值是否一致一致就校验通过。2. 文件完整性校验比如我们把后端服务打包成JAR包发布时会提前计算JAR包的SHA-256哈希值和安装包一起发布到服务器服务器下载完成后会重新计算自身磁盘上该文件的哈希值和发布时给出的官方哈希值比对一致就说明文件在传输过程中没有被篡改、没有丢失内容。3. 接口请求幂等性保证比如用户下单接口我们可以把用户ID、商品ID、订单号、请求时间戳等核心参数按固定规则排序拼接后做SHA-256哈希生成唯一的幂等号存入Redis并设置过期时间当同一个重复请求第二次进来时计算出的哈希值已经存在于Redis中直接拒绝请求保证接口幂等性。小贴士MD5、SHA-1已经被破解存在明确的哈希碰撞风险生产环境禁止用于密码存储等安全相关场景。密码存储优先用bcrypt、Argon2这类慢哈希算法别直接用SHA-256。对称加密哈希是不可逆的只做摘要不做解密而加密的核心是可逆有加密就一定有对应的解密。对称加密指的是加密和解密用的是完全同一个密钥。它的运算速度特别快非常适合给大数据量的内容做加密唯一的痛点就是密钥的安全分发与保管。因为一旦这个密钥泄露了你所有加密的数据都能被直接破解。主流算法不安全已淘汰DES、3DES生产环境推荐AES-128/AES-256、国密SM4业务场景举例我们每天都在用的HTTPS通信逻辑就是【非对称加密协商密钥对称加密传输内容】的组合。浏览器和服务器在HTTPS握手阶段会通过非对称加密协商出一个临时的AES会话密钥握手完成后后续所有的请求、响应数据都用这个AES密钥做加密传输。这样的话既解决了密钥分发的安全问题又利用对称加密速度快的优势保证了大数据量传输的性能。非对称加密非对称加密就是为了解决对称加密的密钥分发痛点诞生的。它的特点是加密和解密用的不是同一个密钥而是一对数学上强关联的密钥对一个叫公钥一个叫私钥。公钥可以完全公开给所有人哪怕全网都知道也没有任何泄露风险私钥必须由持有者自己严格保密绝对不能泄露给任何人。这里有两个不能搞反的规则用公钥加密的内容只有对应的私钥能解密用私钥加密的内容只有对应的公钥能解密这也是后面数字签名的核心原理。需要注意的是非对称加密的运算速度很慢只适合给小数据量的内容做加密绝对不适合用来加密大数据量的内容。主流算法生产环境推荐RSA-2048、ECC椭圆曲线算法、国密SM2业务场景举例金融、支付场景中用户身份证号、银行卡号、支付密码等核心敏感信息的传输必须用非对称加密。比如用户在平台绑定银行卡前端页面会用平台提前公开的RSA公钥对银行卡号、身份证号做加密后再传给后端后端用自己保管的私钥解密出明文做合规校验和存储。哪怕请求被中间人截获没有对应的私钥也绝对无法解密出用户的敏感信息从根源上避免信息泄露。数字签名与验签数字签名与验签是基于【非对称加密单向哈希】实现的它的目标不是数据保密而是以下两个身份认证证明这个数据的发送方是真的防篡改证明这个数据在传输过程中没有被修改过。很多人会把加密和签名的逻辑搞反这里再梳理一遍普通加密是【公钥加密、私钥解密】目标是数据保密不让第三方看到内容数字签名是【私钥加密、公钥解密】目标是身份认证防篡改核心逻辑和我们平时做密码校验的哈希比对完全是一回事发送方先给要发送的原始数据算一个唯一的哈希摘要用自己持有的私钥给这个摘要加密加密后的结果就是【数字签名】和原始数据一起发给接收方接收方拿到数据和签名后先用发送方公开的公钥解密签名还原出发送方当初生成的原始哈希摘要——这个摘要就是绝对可信的【基准哈希】只有持有私钥的官方能生成伪造不了最后我们将收到的原始数据用和发送方完全相同的算法重新算一遍哈希摘要比对两个摘要是否完全一致。只要一致就同时验证了两件事第一这个数据一定是持有私钥的官方发送的不是伪造的第二数据在传输过程中没有被篡改过。画个图加深理解业务场景举例电商系统里微信/支付宝的支付结果回调必须做验签就是为了防止恶意伪造支付成功的回调。用户支付完成后支付平台会给我们的后端发送支付结果回调回调参数里包含订单号、支付金额、支付状态等核心信息同时支付平台会用自己的私钥对回调参数做签名和参数一起发给我们后端收到回调后必须先按规范流程做验签验签通过才会认为这个回调是支付平台官方发出的再去修改订单的支付状态。哪怕攻击者伪造了支付成功的回调请求没有支付平台的私钥就绝对无法生成合法的签名验签会直接失败从根源上避免了恶意伪造支付成功的风险。