多节点间加密通信的安全问题

[raw0xff]

多节点间通信，节点每 2 秒会收到 10<n<100 条加密数据，每 2 秒要发送 n<10 条，每条数据<1kb 。 节点有自己的公私钥，ECC 算法，接收时用本地私钥解密收到的数据，发送时用接收方公钥加密。

请问这种场景选用 ECC 公钥加密私钥解密方式是否合理？会有哪些问题？大佬有什么建议？

我不太懂私钥安全性是否会有磨损，每天百万次解密运算是否可以长期使用？

另一个话题，私钥在本地如何安全存储？

[patrickyoung]

TLS 1.3 +MQTT 就是你要的

[swulling]

100 QPS 还没有到担心性能的地步，除非你的设备是非常慢的嵌入式设备。

此外用 mTLS 就完了，何必自己造轮子。

[swulling]

最后一点，除非用可信硬件，否则不要杞人忧天的考虑本地设备被人拿了 root 怎么办，因为本身就是凉拌。

用 mTLS 可以定期轮换证书，可以主动撤销证书就完了。

[baobao1270]

@raw0xff
不是叫你换 x25519 ，只是叫你换一个 ECDH 算法——x25519 只是目前最火的。ECDH 和 TLS 没有关系，ECDH 是算法，TLS 是实现。但是建议你使用 TLS ，因为自己去实现密码学相关的东西很容易出错。现阶段没有必要考虑 PQC 。

@GeekGao
1. 性能问题：说到底还是 trade-off 。ECDHE 主要还是为了 PFS ，个人认为物联网设备建立连接并不是一个非常频繁、需要并发的场景，即使建立连接慢一点其实也无所谓，同时由于 ECDHE 参数在 TCP 连接建立前就算好了所以也不会给服务器造成负担。个人觉得用这个换 PFS 是值得的。
2. TLS 中随机数本来就是明文传输的，至于为什么去看 ECDHE 的原理。「同一个用户对两个不同的消息签名时，采用了相同的随机数」，不可能，至于为什么去看 AEAD 的原理。
3. 「使用 X25519 算法的设备可能与使用其他加密算法的设备不兼容」——首先，如果你的设备和软件都是新的，那么完全可以直接上 X25519 。其次，X25519 只是 TLS 选用 ECDHE/DHE 算法之一，你也可以选择其他的 ECDHE/DHE 算法。遵循标准 TLS 1.3 协议的客户端和服务器，应该支持 TLS 1.3 所规定的大部分算法。最后，我也没有说「一定要用 X25519 」，如果 OP 选择了一个成熟的 TLS 库方案，那么自然说是库支持什么就用什么，只需要排除不安全的 chiper 即可。
4. ECDH 是密钥交换算法，AES 是块加密算法，是不同的领域：ECDH 只能用来协商密钥，而 AES 只能用来对称加密，必需两个结合在一起才能组成完整的加密通信协议。感觉你 #18 写的东西没有逻辑。

[Explr]

可以了解一下 Signal 算法

[GeekGao]

@baobao1270 关于 4 ，你去了解下 Bluetooth 4.2 (LE Secure Connection) 就知道我的逻辑了。

[hxndg]

命题本身就不是很清楚，你要做的是分布式环境下的保密还是认证？
如果只是加密分布式的环境用 secure scuttbutt 啥的协议通信。就可以了

现代通信网络，做认证必然引入第三方。
本地的安全存储看你的需要的程度，可以拆分为内存可信，系统可信，等级别。这个不说清楚细节没法给回复的，即使是使用 kms 也有认证的问题。当时做协议和 kms 的时候都有非常实际的问题

而且怎么回复里面还有胡说八道的？恢复私钥？？

[GeekGao]

@hxndg “胡说八道的？恢复私钥？？”
你自己研究吧 https://www.instructables.com/Understanding-how-ECDSA-protects-your-data/#step14

[hxndg]

@GeekGao

不好意思，我理解错了，你的意思是说，完全自己实现的交换模式，ecdsa 传输的所有信息都泄露，用户可以完全拿到包括签名结果，要签名的内容之类的东西是吧。就你的情况而言，确实。

我理解的是，就 tls1.3 而言，本身的报文加密，攻击者不会拿到明文的通信内容，所以不可能泄露。

[mightybruce]

@baobao1270
赞同你写的，这上面很多人都在凭空想象，不去多看看基本密码学和网络安全协议设计的书 或 RFC 标准。

[huangzhiyia]

@raw0xff https://www.emqx.io/zh docker 私有部署在你 api 服务器上就行了

[gjquoiai]

密码学第一定律，不要自行发明密码学设施；
另外提醒一下使用椭圆曲线算法加密/解密要用 ECIES ；
椭圆曲线算法目前唯一的问题是常用的几条曲线参数没人知道是怎么来的；
最后就是，为啥不用 tls 。。

[raw0xff]

@baobao1270 我是在用 ecc 公钥加密私钥解密时发现使用姿势不对，看到了 ecdh ，curve25519 也有现成的库，但是我还没有实践。有个不明白的点是，基于连接的对象是固定的，各方公钥是已知的且公开的，那么传输中有必要使用 tls 吗？


@gjquoiai 在用 ecies

[baobao1270]

@GeekGao @hxndg 看来我们遇到了一点自然语言表述不清的缺陷。我说的「随机数」是 TLS 1.3 ClientHello 中的随机数，它是用来参与后期 KDF 的，会明文发送，自然不可能用来恢复私钥。你说的「随机数」是用来生成 ECDHE Key Pair 的随机数，这个自然是需要保密、并且保证抗时序攻击的。
此外，我看了 BLE 的标准，其实和 TLS 是一样的——先用 ECDH 交换密钥，然后用 KDF 生成对称加密密钥，最后用对称加密算法 (RC4/AES) 进行加密通信。所以不可能只依赖 DH/ECDH ，也不可能只依赖对称加密，必需两者结合使用。

@gjquoiai 不一定要用 ECIES 吧，其实说到底还是一套 DH + Symmetric Crypto + AD 的 Hybrid Encryption 方案，TLS 、BLE 、ECH 都是自己实现组合而不是依赖 ECIES ，ECIES 只是一个通用的、被证明没有太大安全漏洞方案吧。

[baobao1270]

@raw0xff #33 TLS 主要是实现 Forward Security ，也就是假如有一个中间人捕获了你的通信，虽然无法解密但是依然保存通信的内容。万一有一天你的私钥泄漏了，如果没有 FS ，那么中间人就能解密你的所有通信；如果用了 FS ，那么就只能解密未来的通信（如果你没有更换私钥），无法解密过去的通信。

TLS 实现 FS 的方式就是 ECDH ，如果你能使用「正确的方式」进行 ECDH 的话，那么自然不需要使用 TLS——但是鉴于大多数人实现密码学的方式都容易犯错，因此「建议」使用 TLS 。

[hxndg]

@baobao1270
我不觉得有继续争论或者解释的必要，
你和我说的都是机制，无论是 tls 还是 hpke （我建议你可以更公开的解释下这个东西，我搜了一下，google 的第一个结果还是我很早写的一篇笔记，我觉得看不懂的人还是看不懂）
而 @GeekGao 说的是具体的里面的算法，针对算法的特定实现做出质疑。
这两个事情并不是直接关联，说到底每个人都看到了一个方面，争论有什么意义呢？

[raw0xff]

@baobao1270 你们神仙尽管打架，不妨碍我问小白问题。

我用 wss 通信还要再加一层 tls 吗？
“ DH + Symmetric Crypto + AD 的 Hybrid Encryption 方案” 中 AD 是指？
我用的 ecies 库也说自己未经安全审查，正在找标准库组合。

[julyclyde]

@baobao1270 并不是“已经是错的了”而是“从来都是错的”
那些所谓科普大部分都是半桶水水平的人写的

非对称加密应该是从来没有使用在大流量数据交换中，而一直都只是用作交换对称密钥的时候保障对称密钥的安全性

[GeekGao]

@baobao1270
@hxndg

😂 我想了一下，觉得解决这个理解问题的最好办法是给 OP 提供一种现实使用的方法而非任何理论性的甚至优劣解释。
干脆，OP 参考 shadowsocks 的加解密过程算了，不用争论了，我觉得满足之前你们所述的算法特征了吧。
关于 shadowsocks 的加密原理，自行 Google 。

[raw0xff]

@GeekGao 别啊大佬，你们据理力争的时候我都在拿本子边查边记呢


@julyclyde 所以 ecc 只用来签名验证是高效的？公私钥加解密功能只有三方库有，标准库只有签名验证没有加解密，不知道什么原因