# Koa_encrypt **Repository Path**: powerZhou/Koa_encrypt ## Basic Information - **Project Name**: Koa_encrypt - **Description**: 非对称加解密测试 - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2019-01-08 - **Last Updated**: 2020-12-19 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # Koa_encrypt #### 介绍 非对称加解密测试 基本知识： 对称加密： 对称加密算法是应用较早的加密算法，技术成熟。主要就是对密钥的一个维护，发送方把数据和密钥通过一定的加密算法处理后，发送给接收方，接受方接到之后在使用相同密钥及算法的逆算法对密文进行解密。这就是一般的对称加密算法过程。 常见的对称加密算法有AES、DES，3DES，TDEA，Blowfish，RC5，IDEA等，建议用AES,速度快，安全性也可以。 对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。缺点主要就是密钥需要双方都有，如果密钥被窃取，那么加密就会比第三方破解，特别是游戏中，密钥如果存放在客户端中，容易被破解反编译到。 我们可以采取登陆消息和逻辑消息采用不同的密钥，登陆验证通过之后，服务器为每个用户分配不同的密钥，然后把逻辑密钥传送给客户端，以此保证密钥的不确定性，从而增加游戏的安全。 缺点：加密和解密用的是同一个密钥，只要有一方密钥丢失，就可以轻松解密 非对称加密： 非对称加密算法使用两把完全不同但又是完全匹配的一对钥匙—公钥和私钥。在使用不对称加密算法加密文件时，只有使用匹配的一对公钥和私钥，才能完成对明文的加密和解密过程。这对于对称加密算法来说，又安全了一步，也是目前https常用的加密方式。 用私钥加密，用配对的公钥解密，公钥和私钥在不同的两个人手上，缺少任意一个，都无法完成整个加解密过程。 公钥可以分配和暴露给所有想要访问的请求者，但密钥一定牢牢的掌握在服务器这边，如此对通信来说，安全性有保证。常用的加密算法，RSA,DSA,ECC。 非对称加密算法，优点就是安全，但缺点就是不够快，比较耗费cpu，如果在游戏中每一次消息都有其加密，对cpu的损耗还是挺高的，所以游戏中一般不用这种加密方式，当然了也看游戏类型，如果对这方面的性能要求不高，安全性要求有很高，采用业务科厚非（那个游戏这么傻啊）。 用法： a.生成一对公钥私钥 b.公钥加密 -> 对应私钥解密 c.私钥加密 -> 对应公钥解密 非对称加密的常见应用方式 a.公钥加密，发给私钥拥有者，私钥解密获得明文。其它人用公钥解不开 b.私钥加密（签名） 公钥的传输（混合加密） a.使用对称加密算法发布公钥 b.使用对称加密算法解密公钥，再使用公钥加密明文，发给私钥拥有者 hash加密 hash加密，就是常见的使用MD5、SHA1等单向HASH算法保护密码，使用这些算法后，无法通过计算还原出原始密码，而且实现比较简单也高效，因此很多互联网公司都采用这种方式保存用户密码。 但安全性越来越担忧了，因为随着彩虹表技术的兴起，可以建立彩虹表进行查表破解，目前这种方式已经很不安全了。 4.hash 加盐加密 hash加密既然容易被彩虹表破解，那么可以采用加盐、多次HASH等扩展，这样可以在一定程度上增加破解难度。常见的方式也是发送方和接受方，维护一个盐池，加密和解密的时候加上这一段盐池来进行hash。 不过这种算法又回到了对称加密中对密钥的保护问题了，如果盐池泄露，别人依然会破解。 怎么办？有人又想出了，让盐池随机的方式，比如PBKDF2算法，原理大致相当于在HASH算法基础上增加随机盐，并进行多次HASH运算，随机盐使得彩虹表的建表难度大幅增加，而多次HASH也使得建表和破解的难度都大幅增加。 一次密码验证过程进行1000次HASH运算，对服务器来说可能只需要1ms，但对于破解者来说计算成本增加了1000倍，而至少8字节随机盐，更是把建表难度提升了N个数量级，使得大批量的破解密码几乎不可行，该算法也是美国国家标准与技术研究院推荐使用的算法。 除了对数据进行加解密外，很多时候我们还需要判断数据是否完整，确认数据在传输过程中没有被篡改。 这里常规的做法就是使用数字签名。 没错，https就是这种场景的一个常见应用。 在准备做游戏数据加密的时候偶然看到一篇博文，详细介绍了虽然非对称加密强度虽高但是消耗性能也高，这就使得游戏采取这样的加密会出现问题。 然后查了代替方案，发现ECC能有效替代RSA,所以准备尝试使用ECC来代替RSA 常见的非对称加密算法如下： RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的； DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）； ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学。 ECC 和 RSA 相比，在许多方面都有对绝对的优势，主要体现在以下方面： 抗攻击性强 CPU 占用少 内容使用少 网络消耗低 加密速度快 ECC的性能还是远低于对称加密，所以最后决定账户形同采用非对称加密，而游戏通信加密协议采用对称加密+pbkdf2算法。 最后再提一嘴 Diffie-Hellman。 DH协议是一个密钥交换协议，可以让双方在不泄露密钥的情况下协商出一个密钥。 目前DH最重要的应用场景之一，就是在HTTPS的握手阶段，客户端、服务端利用DH算法交换对称密钥。 又被坑了，本想逻辑理清楚了，准备实施，结果刚用就发现 crypto.publicEncrypt 只能加密64个字节，这尼玛有个毛用？ 找了半天没有找到增加加密数据大小的方法，然后只能用node-rsa又重新写了测试，准备重新封装