
1 TOTOP OP 不能采用第三方资源,或者去中心方案。要独立完整可执行。 |
2 Ranying 2023-01-29 17:22:27 +08:00 收件人私钥不能在服务器,不好弄啊 |
3 ThirdFlame 2023-01-29 17:23:09 +08:00 PGP |
4 westoy 2023-01-29 17:24:27 +08:00 单个都能满足, 全部权限就没戏了, 直接告诉对方不行吧, 这种要调整人事权限去适配系统的, 反过来就有问题了 |
5 duke807 2023-01-29 17:25:26 +08:00 via Android |
6 cvooc 2023-01-29 17:28:16 +08:00 本地加密上传, 密码第三方自行通知? |
7 Ranying 2023-01-29 17:28:39 +08:00 1. 服务器生成公私钥,公钥保存,私钥发到收件人本地 2. 用收件人密码加盐去加密私钥,这一步在本地完成,然后向服务器提交加密私钥 3. 收件人登录时取得加密私钥并在本地解密 4. 收件人修改密码时用新密码加密私钥并提交 5. 发件人取得公钥加密消息并发往收件人 |
8 fgwmlhdkkkw 2023-01-29 17:29:26 +08:00 u 盾 |
9 werls 2023-01-29 17:31:25 +08:00 via Android GPG 就行了 给邮箱装一个 |
10 libook 2023-01-29 17:34:58 +08:00 采用非对称加密,每个用户生成独立的公私钥对,公钥存储到服务器上,私钥存储在客户端。 发送密信的时候,按照收件人下载其公钥,把信息在本机加密再发到服务器上,收件人将密文下载到本地,使用私钥解密查看。 如果需要移动使用,比如支持换另一个客户端使用,可以把公钥使用用户的密码在本地加密后,将密文发送到服务器上储存,用户换其他设备的时候会将私钥密文下载到本地,再用用户密码解密使用。 |
11 duke807 2023-01-29 17:37:31 +08:00 via Android |
12 clearc 2023-01-29 17:39:01 +08:00 via iPhone 这个需求如果是理想状态其实挺简单的,描述复杂化了,把它抽象一层,就是“一个端到端的加密系统,且用户私钥不离开本地”。 考虑到实现,本质上就要做一套双层加解密,用于密文的非对称密钥由用户本地生成本地保存,自行上传公钥,服务器做用户识别和绑定。 但是有这么个需求的甲方,做起来肯定不是这么理想…… |
13 GopherDaily 2023-01-29 17:41:10 +08:00 1. 生成公私钥,私钥让用户保存,系统只保存公钥; 2. 发给用户的信息用公钥加密,用户收到后要在客户端输入私钥才能看到 类似于云厂商的 AccessKey ,逆向 |
14 leoleoasd 2023-01-29 17:42:35 +08:00 GPG+硬件密码学工具 本身不就是为了解决这个问题的 |
15 libook 2023-01-29 17:46:39 +08:00 |
16 duke807 2023-01-29 17:48:25 +08:00 via Android @clearc 只要楼主做的产品,客户端能接触到加密前的明文、解密后的明文、甚至是可以扫描本地电脑文件找到密钥,理论上就是不安全的,拥有全部权限的人就可以增加恶意代码查看到历史通讯内容。 |
17 duke807 2023-01-29 17:50:46 +08:00 via Android |
18 meeop 2023-01-29 18:25:25 +08:00 很简单啊,甚至你用 qq 都行 就用非对称加密,收信人持有私钥,发信人用公钥加密数据内容然后发送 这样除了收信人,其他任何人都无法获取信件内容 唯一的风险是客户端有后门可能读取客户端的私钥,但是这一点可以通过代码开源检查发现 另一个风险是因为黑客攻击泄漏私钥,这个可以通过比如专门密钥保管软件硬件处理,不然各种基于非对称加密的服务都没法用了 再保险点,就要求涉密电脑不能上网,不能安装不可信程序等手段进一步约束 |
19 hjtao889 2023-01-29 19:32:14 +08:00 发件人可回看吗 |
20 SenLief 2023-01-29 21:00:52 +08:00 给每个收件人寄一份硬件加密解密设备。 |
22 Zy143L 2023-01-30 02:44:14 +08:00 via Android 上加密狗吧 内置公私钥 服务器信息下发均通过公钥加密 用户使用加密狗私钥解密 |