密码相关
- 之前一直混淆加密解密(rsa)何散列碰撞(sha)之间的区别,现在明白了，rsa做的是明文和密文之间的转换,而sha做的是信息验证，即验证发送者所发送的信息有没有被篡改过。由于sha我没有详细看所以就详细描述下rsa。
- nodejs api 描述（rsa相关）
文档
方法:
crypto.privateEncrypt(privateKey, buffer)
描述 :
- key: string A PEM encoded private key.(已被加密的私钥，需要密码进行解密)
- passphrase:string An optional passphrase for the private key.（用以私钥解密的密码，将密码变为明文）
- padding:crypto.constants An optional padding value defined in crypto.constants, which may be: crypto.constants.RSA_NO_PADDING or crypto.constants.RSA_PKCS1_PADDING.(位数填充，其实rsa并不需要填充详见这里Why is padding used for RSA encryption given that it is not a block cipher,其实除了这里的回答还有一点比较好理解，因为rsa本质上就利用了整数会相互同余这这种性质，如果m大于n的话，m可能会整除n，这样永远不会有余数，rsa也就会失效。)
buffer
说明:
这里虽然是原始数据，但是不排除在字符串何原始数据转换的过程中会出现填充。所以尽量保证系统环境的一致。（我会在编码中说明）
Returns: Buffer A new Buffer with the encrypted content.Encrypts buffer with privateKey.
Encrypts buffer with privateKey.
privateKey can be an object or a string. If privateKey is a string, it is treated as the key with no passphrase and will use RSA_PKCS1_PADDING.(注意这段话，所以通常来说如果私钥没做什么特殊处理的话，填充往往是用RSA_PKCS1_PADDING)。所以这里解密方在解密时往往也会加上此参数。顺便吐槽下 nodejs 文档，为什么privatekey 可以是string这种情况要在这么一小段里写出来啊。太反新手了。
因为加密和解密的方式都是对应的，所以加密方式就暂且略过。
另外千万不要被所谓的什么公私钥给骗了，可以看这里,所谓的公钥和私钥都是人们起的高大上的名字，其实加密和解密的流程只需要由n产生的两个钥对即可。根本不分公钥和私钥的。
编码
这又是一个非常头疼的东西,因为世界上的文字那么多,编码用的编码表符号多了英语系国家不愿意(一个'a'占用四个字节好亏啊),符号少了亚洲的国家不愿意，汉字显示不出来(找不到相应的符号)总不能天天看英文吧。一开始还是自己国家用自己的编码系统，同时兼容英语，后来utf(统一编码格式)出现了。这个编码比较厉害的地方在于它是可变长度的。这样的话'a'就可以只占用一个字节了，而汉字也能显示出来。看起来是很好的方案但是这是有代价的。刚才说过utf是可变长度的，所以就必须标注出来当前数据中一个字符占用四个字节还是一个字节。
标注规则:
- 对于UTF-8编码中的任意字节B，如果B的第一位为0，则B独立的表示一个字符(ASCII码)；
- 如果B的第一位为1，第二位为0，则B为一个多字节字符中的一个字节(非ASCII字符)；
- 如果B的前两位为1，第三位为0，则B为两个字节表示的字符中的第一个字节；
- 如果B的前三位为1，第四位为0，则B为三个字节表示的字符中的第一个字节；
- 如果B的前四位为1，第五位为0，则B为四个字节表示的字符中的第一个字节；
因为之前在做涉及到加密解密传输方面，所以吃了不少这样的亏。这里我自己总结摸索出了一个技巧就是将所有的编码加密前先全部转为hex16进制编码再转化成buffer，这样由于16进制编码的一个字符只会占据一个字节。所以大可不必担心在编码和buffer相互转换时由于填充导致的问题，另外还有一个好处，就是在写api文档时demo也比较好写。因为16进制编码转换成可视的字符串时一般也不会做特殊处理,另外就算特殊处理了也没问题，可以将处理后的字符通过查表找到对应字节的值依然可以还原成原始buffer。
rsa原理需要一些数论的知识，我看完后继续写（已经看完一大半了）。
