实现:
```
算法:RSA
填充:RSA_PKCS1_PADDING
密钥格式:符合PKCS#1规范,密钥对采用PEM形式
```
生成密钥对:
```
1. https://www.cnblogs.com/hongdada/p/8295526.html
2. https://www.jianshu.com/p/9da812e0b8d0
3. 通过执行shell脚本generate_rsa_keys.sh生成pkcs1密钥对及对应的pkcs8密钥对,自主选择某种格式私钥
```
选择密钥对:
```
经过go、php、py三个例子,建议私钥使用pkcs1格式、公钥使用pkcs8格式
```
不同规范PEM格式如下:
```
RSA Public/Private Key (PKCS#1)
# 公钥
-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----
# 私钥
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
```
Public/Private Key (PKCS#8)
```
# 公钥
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
# 私钥
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
```
没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
为了安全性起见,客户要求客户端必须将数据加密后才能传给服务端。 起先,准备使用非对称加密(RSA)方式,但是发现它对原始文本长度有限制。 而对称加密(AES)没有长度限制,但是使用固定密钥存在暴露的风险。 有没有两全其美的办法呢? 思路 密钥肯定每个用户不同,而要验证用户则必须登录。 因此,唯一可以安全获取密钥的时机,只能是在登录时。 而为了保证用户名密码传输安全,可以使用RSA公钥加密后传输,所有客户端使用同一公钥也没问题。 登录成功后,服务端将生成token和AES密钥返回给客户端。但是,返回的AES密钥是经过加密的,而加密密钥则是“用户名+密码”。 这样保证了,只有刚才成功登录的客户端才能解密出AES密钥。 以后的传输,全部使用AES加密,服务端可以根据token从缓存获取AES密钥解密。
资源推荐
资源详情
资源评论












收起资源包目录





















































共 41 条
- 1
资源评论


野生的狒狒
- 粉丝: 86
- 资源: 1067
上传资源 快速赚钱
我的内容管理 展开
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助


安全验证
文档复制为VIP权益,开通VIP直接复制
