UDP 是不是不能用 AES 来加密啊？

[tool2dx]

aes 是一种流式加密，加密时需要按照顺序，比如第 1 ，2 ，3 个数据包依次加密。解密也是类推，需要第 1 ，2 ，3 个包依次解密。

然而，UDP 会掉包。也就是解密会遇到 1 ，2 ，4 这种情况。由于第三个包掉了，那么后面数据包全部都无法顺利解密。

那么问题来了，遇到这种情况，应该选什么加密算法？

[TomVista]

我更好奇的是你在哪层网络能够对数据包依次加密

[b821025551b]

首先，aes 是分组加密； tcp 是流式传输；
其次，所有的加密都需要校验，只是 tcp 帮你做了而已；
那么到 udp ，需要自己做校验，比如 crc ，然后自己实现重发机制。

[tool2dx]

@TomVista 就是最普通的 UDP 数据，用 socket api 写的，数据包在网络裸奔太危险，但是暂时没想到很好的加密方式。

也许能用一个随机数做种子，类似 rsa 加密 padding 那种。填充不同，加密后的数据不同。

可惜 RSA 加密太慢了，要不然还挺合适的。UDP 都是固定长度，而且分包都很小。

[tool2dx]

@b821025551b 好的 UDP 协议应该允许一定程度的丢包，现在都是全球互联网，晚高峰跨国发数据丢个包，实在是太正常了。

如果都按照 TCP 的方法，1234 数据包都依次排序，严格校验数据包漏发和错发，那是可以用 AES 的，但就是失去了 UDP 的优势和意义。

[forvvvv123]

@tool2dx OP 看一下 CTR 模式，AES 的话就是 AES-CTR ，每个分组可以并行解密不依赖顺序，适合你的场景。

[tool2dx]

@forvvvv123 感谢，似乎可行，我去研究一下。

AES 有 CBC ，CFB ，GCM ，ECB 各种模式，被绕晕了。

[duanxianze]

我不懂 upd,aes ，但我觉得你都搞加密了，使用 udp 带来的节省似乎不足以抵消你加密造成的消耗，还不如老老实实用类似 https ，wss 之类的现成协议了

[byte10]

楼上说的 AES-CTR 就是流式加密，你说的那个分组加密不行，但是流式加密 也需要知道包的 index 位置，所以丢失了还是不行，头大。对 UDP 不熟悉，如果你加上重传，又把校验加上，还不是又绕回来 tcp 这边了么。

[tool2dx]

@byte10 TCP 丢包惩罚太凶，交通拥堵的时候，就很容易进入不可用状态。虽然开 BBR 能缓解一定效果，但是这是单向的开关，下载快，上传还是很慢。

客户端要开启 BBR ，好像要最新的 WIN11 ，就觉得没太大必要。

国内服务器 TCP 确实够用了，可惜有国外业务，只能硬着头皮上 UDP 了，要不然真的太卡了。

[ryan4290]

QUIC 能尝试一下，解决你的问题吗？

[caola]

@tool2dx 有现成的 QUIC 协议 或 HTTP/3 直接拿来就用，不用自己关心底层是怎么实现的，你就当他是普通的 TCP 就可以了

[w3b5h3ll]

加密不是应用层，更 udp 没关系吧

[ysc3839]

要 UDP+加密的话，为什么不直接用 DTLS ？

[cheng6563]

@byte10 楼上说的 AES-CTR 就是流式加密，你说的那个分组加密不行，但是流式加密 也需要知道包的 index 位置，所以丢失了还是不行，头大。对 UDP 不熟悉，如果你加上重传，又把校验加上，还不是又绕回来 tcp 这边了么。


还是有点不一样，udp 客户端可以手动控制重复发包，比如检测到网络波动就双倍发包

[ho121]

把每个 udp 报文都当作一个新的流不行吗？
就像加密文件一样，每个 udp 包都当作独立的文件。

[slack]

能的，最近在研究 i2p ，里面就是用的 ssu2 。

[minami]

这个倒不用担心，一般人不会直接用 UDP ，都是用 SRTP 或者 QUIC 这些更上层协议，它们都有加密功能

[leloext]

有重传机制就没问题了，如果 udp 真不能用 aes 加密的话，那么 kcptun 也不会存在；想知道底层的话可以看看它的源码。

[mt7620]

github -> kcptun

[leonshaw]

抄 ESP 呗，每个包都是独立解密的，分组是指一个包内部分成 block