本文目录一览：
- 1、如何使用CryptoJS的AES方法进行加密和解密
- 2、CryptoJS的AES方法密钥安全问题
- 3、为什么 CryptoJS DES 加密的结果和 Java DES 不一样
- 4、最简人机交互-加解密
如何使用CryptoJS的AES方法进行加密和解密
首先准备一份明文和秘钥：
var plaintText = 'aaaaaaaaaaaaaaaa'; // 明文
var keyStr = 'bbbbbbbbbbbbbbbb'; // 一般key为一个字符串
参看官网文档，AES方法是支持AES-128、AES-192和AES-256的，加密过程中使用哪种加密方式取决于传入key的类型，否则就会按照AES-256的方式加密。
CryptoJS supports AES-128, AES-192, and AES-256. It will pick the variant by the size of the key you pass in. If you use a passphrase, then it will generate a 256-bit key.
由于Java就是按照128bit给的，但是由于是一个字符串，需要先在前端将其转为128bit的才行。
最开始以为使用CryptoJS.enc.Hex.parse就可以正确地将其转为128bit的key。但是不然...
经过多次尝试，需要使用CryptoJS.enc.Utf8.parse方法才可以将key转为128bit的。好吧，既然说了是多次尝试，那么就不知道原因了，后期再对其进行更深入的研究。
// 字符串类型的key用之前需要用uft8先parse一下才能用
var key = CryptoJS.enc.Utf8.parse(keyStr);
由于后端使用的是PKCS5Padding，但是在使用CryptoJS的时候发现根本没有这个偏移，查询后发现PKCS5Padding和PKCS7Padding是一样的东东，使用时默认就是按照PKCS7Padding进行偏移的。
// 加密
var encryptedData = CryptoJS.AES.encrypt(plaintText, key, {
mode: CryptoJS.mode.ECB,
padding: CryptoJS.pad.Pkcs7
});
由于CryptoJS生成的密文是一个对象，如果直接将其转为字符串是一个Base64编码过的，在encryptedData.ciphertext上的属性转为字符串才是后端需要的格式。
var encryptedBase64Str = encryptedData.toString();
// 输出：'RJcecVhTqCHHnlibzTypzuDvG8kjWC+ot8JuxWVdLgY='
console.log(encryptedBase64Str);
// 需要读取encryptedData上的ciphertext.toString()才能拿到跟Java一样的密文
var encryptedStr = encryptedData.ciphertext.toString();
// 输出：'44971e715853a821c79e589bcd3ca9cee0ef1bc923582fa8b7c26ec5655d2e06'
console.log(encryptedStr);
由于加密后的密文为128位的字符串，那么解密时，需要将其转为Base64编码的格式。
那么就需要先使用方法CryptoJS.enc.Hex.parse转为十六进制，再使用CryptoJS.enc.Base64.stringify将其变为Base64编码的字符串，此时才可以传入CryptoJS.AES.decrypt方法中对其进行解密。
// 拿到字符串类型的密文需要先将其用Hex方法parse一下
var encryptedHexStr = CryptoJS.enc.Hex.parse(encryptedStr);
// 将密文转为Base64的字符串
// 只有Base64类型的字符串密文才能对其进行解密
var encryptedBase64Str = CryptoJS.enc.Base64.stringify(encryptedHexStr);
使用转为Base64编码后的字符串即可传入CryptoJS.AES.decrypt方法中进行解密操作。
// 解密
var decryptedData = CryptoJS.AES.decrypt(encryptedBase64Str, key, {
mode: CryptoJS.mode.ECB,
padding: CryptoJS.pad.Pkcs7
});
经过CryptoJS解密后，依然是一个对象，将其变成明文就需要按照Utf8格式转为字符串。
// 解密后，需要按照Utf8的方式将明文转位字符串
var decryptedStr = decryptedData.toString(CryptoJS.enc.Utf8);
console.log(decryptedStr); // 'aaaaaaaaaaaaaaaa'
CryptoJS的AES方法密钥安全问题
如果你的填充模式不是PKCS5Padding肯定就解密不了了
CryptoJS.aes.encrypt(srcs, key, { iv: iv,mode:CryptoJS.mode.cbc.padding:CryptoJS.pad.NoPadding});
CryptoJS可以用的填充模式：
Pkcs7 (the default)
Iso97971
AnsiX923
Iso10126
ZeroPadding
为什么 CryptoJS DES 加密的结果和 Java DES 不一样
最近需要对数据进行加密/解密, 因此选用了CryptoJS库, 对数据做DES算法的加密/解密
首选查看官方示例, 将密文进行Base64编码, 掉进一个大坑
script src="htt p:/ /crypto-js.googlecod e.c om/svn/tags/3.1.2/build/rollups/tripledes.js"/script
script
var encrypted = CryptoJS.DES.encrypt("Message", "Secret Passphrase");
// ciphertext changed every time you run it
// 加密的结果不应该每次都是一样的吗?
console.log(encrypted.toString(), encrypted.ciphertext.toString(CryptoJS.enc.Base64));
var decrypted = CryptoJS.DES.decrypt(encrypted, "Secret Passphrase");
console.log(decrypted.toString(CryptoJS.enc.Utf8));
/script
对这些加密算法不了解, 只能求助Google
des encrypion: js encrypted value does not match the java encrypted value
In cryptoJS you have to convert the key to hex and useit as word just like above (otherwise it will be considered as passphrase)
For the key, when you pass a string, it's treated as a passphrase and used to derive an actual key and IV. Or you can pass a WordArray that represents the actual key.
原来是我指定key的方式不对, 直接将字符串做为参数, 想当然的以为这就是key, 其实不然, CryptoJS会根据这个字符串算出真正的key和IV(各种新鲜名词不解释, 问我也没用, 我也不懂 -_-")
那么我们只需要将key和iv对应的字符串转成CryptoJS的WordArray类型, 在DES加密时做为参数传入即可, 这样对Message这个字符串加密, 每次得到的密文都是YOa3le0I+dI=
var keyHex = CryptoJS.enc.Utf8.parse('abcd1234');
var ivHex = CryptoJS.enc.Utf8.parse('inputvec');
var encrypted = CryptoJS.DES.encrypt('Message', keyHex, { iv: ivHex });
这样是不是就万事OK了? 哪有, 谁知道这坑是一个接一个啊.
我们再试试Java这边的DES加密是不是和这个结果一样, 具体实现请参考Simple Java Class to DES Encrypt Strings
果真掉坑里了, Java通过DES加密Message这个字符串得到的结果是8dKft9vkZ4I=和CryptoJS算出来的不一样啊...亲
继续求助Google
C# and Java DES Encryption value are not identical
SunJCE provider uses ECB as the default mode, and PKCS5Padding as the default padding scheme for DES.(JCA Doc)
This means that in the case of the SunJCE provider,
Cipher c1 = Cipher.getInstance("DES/ECB/PKCS5Padding");
and
Cipher c1 = Cipher.getInstance("DES");
are equivalent statements.
原来是CryptoJS进行DES加密时, 默认的模式和padding方式和Java默认的不一样造成的, 必须使用ECB mode和PKCS5Padding, 但是CryptoJS中只有Pkcs7, 不管了, 试试看...
script src="htt p:/ /crypto-js.googleco de.c om/svn/tags/3.1.2/build/rollups/tripledes.js"/script
script src="ht tp:/ /crypto-js.googleco de.c om/svn/tags/3.1.2/build/components/mode-ecb.js"/script
script
var keyHex = CryptoJS.enc.Utf8.parse('abcd1234');
var encrypted = CryptoJS.DES.encrypt('Message', keyHex, {
mode: CryptoJS.mode.ECB,
padding: CryptoJS.pad.Pkcs7
});
console.log(encrypted.toString(), encrypted.ciphertext.toString(CryptoJS.enc.Base64));
/script
咦...使用Pkcs7能得到和Java DES一样的结果了, 哇塞...好神奇
那我们试试统一Java也改成Cipher.getInstance("DES/ECB/PKCS7Padding")试试, 结果得到一个大大的错误
Error:java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS7Padding
没办法, 继续Google
java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/ECB/PKCS7PADDING
I will point out that PKCS#5 and PKCS#7 actually specify exactly the same type of padding (they are the same!), but it's called #5 when used in this context. :)
这位大侠给出的解释是: PKCS#5和PKCS#7是一样的padding方式, 对加密算法一知半解, 我也只能暂且认可这个解释了.
忙完了DES的加密, 接下来就是使用CryptoJS来解密了. 我们需要直接解密DES加密后的base64密文字符串. CryptoJS好像没有提供直接解密DES密文字符串的方法啊, 他的整个加密/解密过程都是内部自己在玩, 解密时需要用到加密的结果对象, 这不是坑我吗?
只好研究下CryptoJS DES加密后返回的对象, 发现有一个属性ciphertext, 就是密文的WordArray, 那么解密的时候, 我们是不是只要提供这个就行了呢?
var keyHex = CryptoJS.enc.Utf8.parse('abcd1234');
// direct decrypt ciphertext
var decrypted = CryptoJS.DES.decrypt({
ciphertext: CryptoJS.enc.Base64.parse('8dKft9vkZ4I=')
}, keyHex, {
mode: CryptoJS.mode.ECB,
padding: CryptoJS.pad.Pkcs7
});
console.log(decrypted.toString(CryptoJS.enc.Utf8));
果不其然, 到此为止, 问题全部解决, 豁然开朗...
完整代码请参考CryptoJS-DES.html
Use CryptoJS encrypt message by DES and direct decrypt ciphertext, compatible with Java Cipher.getInstance("DES")
最简人机交互-加解密
上学时递小纸条，尤其是需要中间人传递时，是不是使用过一套约定的符号代替普通的文字？特别有必要！
图
广义来讲，保护信息的各种方式都属于加密范畴，而保护的形式、角度、等级和目标是多种多样的。
电视剧里，经常有材料被情敌偷偷修改然后蒙冤的场景。何解？
策略：让内容中每一个字节都参与一项运算得出一个结果记录下来，如果计算结果变了，说明内容被修改过。
这里运算得出的结果叫做摘要，这个算法叫消息摘要算法，也叫单向散列函数。算法的科学性很重要，常见的算法有：MD5、SHA1、SHA256、SHA512、HmacMD5、HmacSHA1、HmacSHA256 等。
这个，只能说难免会被别人看到。
策略：使用密钥变换内容，让别人看到也不知道为何物，通过密钥才可还原内容。
这种通过相同的密钥来加密和解密的算法，叫对称加密算法。常见算法DES、3DES（TripleDES）和AES（Advanced Encryption Standard）等。AES 根据密钥长度不同又分为AES-128 AES-192 AES-256 对应16 24 32 字节。
这些算法，通常是按块来进行加密的，如 16 个字节为一块。当最后一块不够 16 个字节时，通常是采用补齐的策略，补齐的方式也有不同讲究。
策略一，数据长度不对齐时使用0填充，否则不填充，但补的0解密后无法区分是补的还是原本就有的，只适合以\0结尾的字符串加密，此谓之 ZeroPadding。
策略二，补充的字节值设定为补充的数量，如要补充5个字节，则这5个字节的值都为 5，这样根据最后一个字节可得到填充数据的长度，在解密后可以准确删除填充的数据。但如果刚好整块无需补充，为了仍然满足最后一个字节表示填充的数据长度，填充一整块，值为块长度。此种方式有 PKCS7Padding，它假设数据长度需要填充n(n0)个字节才对齐，那么填充n个字节，每个字节都是n；如果数据本身就已经对齐了，则填充一块长度为块大小的数据，每个字节都是块大小。PKCS5Padding，PKCS7Padding的子集，块大小固定为8字节。
分块加密时，每块采用完成相同的加密过程，则可以并行加密再拼接，但当内容中有多块相同的内容时加密结果会一样，而这种重复会为破解提供线索，于是多种加密模式被提出。以下是两种最常见的模式。
Electronic Code Book(ECB)
电子密码本模式
最基本的加密模式，也就是通常理解的加密，相同的明文将永远加密成相同的密文，无初始向量，容易受到密码本重放攻击，一般情况下很少用。
Cipher Block Chaining(CBC)
密码分组链接模式
明文被加密前要与前面的密文进行异或运算后再加密，因此只要选择不同的初始向量，相同的密文加密后会形成不同的密文，这是目前应用最广泛的模式。CBC加密后的密文是上下文相关的，但明文的错误不会传递到后续分组，但如果一个分组丢失，后面的分组将全部作废(同步错误)。
对称加密中，接收方需要知道密钥，这个密钥本身的保密就成为了问题。密钥泄漏，意味着正确解密的消息也变得不可靠，也许是伪造的。
策略：公开密钥，即发给我的消息，使用公开密钥加密，我收到之后只可用我的私有密钥解密。
此谓之非对称加密算法，一种强大的密钥保密方法。这离不开理论上的研究成果。
非对称加密算法需要两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。
为了验证是不是对的人，可以要求发送放对内容提取摘要，并使用其私钥加密，将结果附在后边作为签名一并发送。这样，就可以使用发送放的公钥来解密这个签名并验证其一致性，如果一致说明是对的人发过来的。此过程谓之签名验签。
使用最广泛的是RSA算法。
很多常见的加密算法在 CryptoJS 中有实现，首先，在控制台引入扩展脚本。
加密结果 U2FsdGVkX1/Ry7m4YU7aTXizLMAGhn2EwZf555rz8neh6FP6/4p9CUaZpnBxvOKT
解密过程
加密的内容为16进制数据时，可以利用以下方式将16进制字符串转换成字节数组。
计算结果 c6a13b37878f5b826f4f8162a1c8d879
CryptoJS 当前尚未支持 RSA，可以引入以下 JS 扩展。
使用公钥加密
OVNmfqDMAxHoiMbNHNQ4Olrb0BHGLHEPXM0EAJ/hTwEJsz+igrLIPnrqf1ABmWnoj6cOOcGNroYLa2xZ9/TkaF5UKG+H+RrjpbHHQVe3mWWlDsX9bZ/m8lP3izntwKHdklH+2vfeOlSJ3+PK3O6ILWvaVM4PVCzVo9lPiN7NkIE=
使用私钥解密
反过来使用私钥加密公钥解密也是可以的，只是一般的工具方法，只会提供私密生成签名，公钥验证签名，但这足够了。
更详细用法，请参考
直接来看看二战期间的故事，以下内容引用自
