# 数据加密传输
**Repository Path**: jf_linux/RSA_AES
## Basic Information
- **Project Name**: 数据加密传输
- **Description**: [客户端 VUE + 后端 PHP]
- **Primary Language**: PHP
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 3
- **Created**: 2022-08-05
- **Last Updated**: 2022-08-05
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
**数据加密传输 ———— RSA（非对称加密） + AES（对称加密）**
[客户端 VUE + 后端 PHP]
**说明**
我们先了解下为什么我们需要在传输的过程中对我们的数据进行加密？
在 web 传输中，我们传输的方式有两种 http 或 https
http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl 加密传输协议。
使用 http 传输的话中间人只要使用抓包的方式就可以获取到我们的数据，这样很容易造成数据泄露。
HTTPS 加密就是为了让客户端与服务器传输过程进行数据加密，不被中间劫持。
**HTTPS 加密传输**
我们可以发现即使我们使用了 HTTPS 发送数据的时候，我们仍然可以看到我们的明文数据。因为我们发送数据是在应用层，所以数据还没有被加密
。这样的话密码不是会被本地恶意软件截获么?只能说的确存在这样的可能。一般在大型的银行或者电商平台我们可以看到。都是要求用户必须安装数字证书、安全控件或者使用提供的安全虚拟键盘才可以进行下一步操作。
**使用 HTTPS 数据就安全了？**
HTTPS 在 HTTP 安全性上确实提高了很多，在数据传输的过程中即使被抓包，也很难破解出数据内容。但是单使用 HTTPS 传输就安全了吗？只能说也不一定安全。查看了挺多资料看到很多人的观点都不一样。有人说现在 HTTPS 也可以通过抓包方式破解用户数据，也有人说再过几年 HTTPS 普遍使用之后，他的安全性也不能满足不了了。所以说每种产品加密都不同，如果有其它应用可以加密，那多一个可能是更好的，具体还是需要看各人需求。
**使用 HTTPS 的问题**
HTTPS 是通过 RSA 非对称加密的,RSA 非对称加密是安全性较高的加密方式，但是他的缺点也比较严重。就是在加密数据越大的情况下他的性能开销以及耗时会更长;HTTPS 需要申请加密协议，增加了运营成本; 总的来说还是需要根据自己的项目需求来定义，按照谷歌现在大力推进 HTTPS 的普遍使用的情况看，HTTPS 是网络的发展趋势，早晚都要做的；谷歌也宣布从 9 月开始，Chrome 将停止在地址栏中标记 HTTPS 页面为"安全"站点。
好了介绍完了，废话不多说上图
1.用户在初始化的时候会生成随机加密秘钥;
2.用户利用生成的加密秘钥进行 AES 加密（也可以使用 AES256 加密，目前好像没有破解的方法）
3.利用客户端的公钥对加密秘钥进行 RSA 加密（因为 RSA 在加密和解密性能上都远不如 AES，所以让 RSA 加密的数据越小越好）
###这里有个问题，AES256 加密目前好像没有方式破解并且 AES 性能优过 RSA，直接用 AES 加密不就好？
###其实这两种并没有冲突，如果单纯使用 AES 加密,那客户端如何把秘钥传递给后台呢?如果秘钥不是随机的而是固定的,那谁都可以解任何人的密文了
4.后台在接收到客户端提交的数据后，进行解密处理，先使用私钥解密获取到AES加密秘钥，再使用AES加密秘钥对密文解密
5.解密后后台将生成token，并使用Redis将秘钥、用户信息、token 绑定在一起
###Redis、Memcached 、File Cache ....都行，开行就好。记得设置失效时间！
6.将所有数据（包含token）一起使用AES加密传递给后台，返回码和返回提示信息可以不加密，看个人需求
###虽然RSA可以公钥加密和私钥加密，但是如果后台使用私钥加密，那所有有公钥的人都可以破解了。所以不可以也不需要这样操作，因为客户端已经有自己唯一的随机秘钥了，我们只要按照用户登陆时提交过来的秘钥加密返回就可以了。
7.用户登陆成功后，后面的数据传递都不需要再传递秘钥了