这篇是加解密的最后一篇，来聊聊加密加盐。翻看最近的区块链钱包项目，发现 web3j 的源码中对数据做了加盐处理，正好分析一下它是如何进行加盐处理的。

目录：

盐 (Salt) 在密码学中，是指通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这种过程称之为 "加盐"。密码不能以明文形式保存到数据库中，否则数据泄露密码就会被知道。而一般的加密方式由于加密规则固定，很容易被破解，安全系数不高。密码加盐的加密方式，能很好的解决这一点。

密码加盐里包含随机值和加密方式。随机值是随机产生的，并且以随机的方式混在原始密码里面，然后按照加密方式生成一串字符串保存在服务器。换言之，这个是单向的，电脑也不知道客户的原始密码，即使知道加密方式，反向推出的加密前的字符串也是真正密码与随机值混合后的结果，从而无法解析用户的真正密码。那么是如何验证密码的呢？当你再次输入密码，会以相同的加盐方式生成字符串，如果和之前的一致，则通过。而其它用户无法获得这种加密方式：即生成哪些随机数，以什么方式混入进去，自然就很安全。

2. 加盐的原理和流程

第一代密码：

存的明文密码，一旦数据库泄漏，密码一览无余。

第二代密码：

不存明文密码，将密码进行摘要再存储 (MD算法，Hash算法)。由于摘要算法是不可逆的  (CRC32 除外)，所以即使拿到了数据库，也破解不了密码。但是如今 MD5 已经能够被破解了，不再足够安全。即使破解不了，黑客拿到数据库后，用常用的密码数据集进行消息摘要做匹配，也可以拿到用户的密码。

第三代密码：

多了一个字段  - salt。用户在输入密码注册后，随机生成一个 salt，一定要是随机生成的。然后按照一定的混淆规则，将 salt 撒入到明文密码中，最后将加盐后的密码做消息摘要，将 salt 和密码的消息摘要传给服务器。服务器如何匹配用户密码是否正确呢？用户用同样的方式对原始密码加盐再生成摘要，发送给服务器，服务器匹配摘要。因为盐是随机生成的，不用每次都生成盐，盐可以存在本地或者服务器，加盐的规则只要不泄漏出去就行，这样的处理比简单的对密码摘要要安全很多。

这时黑客还能破解吗？

由于盐是随机生成的，每个用户的盐都不相同 (也可能会碰撞)，而且对密码加盐的规则只有用户端知道。所以黑客拿到数据库，虽然能看到盐和密码摘要，但是不知道如何将盐混入常用密码集，所以即使知道摘要算法，匹配密码的难度也是非常大的。

3. 加盐 demo

执行输出：

MD5加密 明文：123456 无盐密文：E10ADC3949BA59ABBE56E057F20F883E 加盐密文：1AA9D0E1386C07EE28CE4EFC8A04756A 带盐密文：15AAC9D40E2135863C047E7E208C4E41EF6C88A0247D562A

4. web3j 的加盐处理

调用 web3j 创建轻量级钱包，password 是钱包密码，ecKeyPair 是一个密钥，包含公钥和私钥：

看看 createLight()的实现：

只有在创建的时候才会生成 salt，然后存放在本地。salt 的生成规则如下：

调用安全随机工具随机生成的一个长度为32的字节数组，然后将这个字节数组拼接 '0x' 组合成16进制的字符串。

钱包生成后，当用户想要进行转账，输入密码后，要拿到钱包的私钥，这时对 salt 是如何处理的呢？

传入密码和钱包文件对钱包进行解密，解密的代码如下：

先通过钱包文件获取它的 Crypto，然后通过 Crypto 获取 KdfParams，前面创建钱包时，salt  是存放在 KdfParams 中的。通过KdfParams 就可以获取到这个钱包的 salt 了，然后用用户输入的密码，salt 和一些其他的参数生成最终原始数据的密钥 (derivedKey)，相当于上个例子中的 pswDigest。最后通过 derivedKey 和加密的密文还原出 ECKeyPair (公钥和私钥对)。

好了，加解密篇就讲到这了，下一个系列是设计模式篇。