V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
tool2dx
V2EX  ›  问与答

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

  •  
  •   tool2dx · 30 天前 · 1888 次点击

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

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

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

    26 条回复    2024-06-16 05:58:11 +08:00
    TomVista
        1
    TomVista  
       30 天前
    我更好奇的是你在哪层网络能够对数据包依次加密
    b821025551b
        2
    b821025551b  
       30 天前
    首先,aes 是分组加密; tcp 是流式传输;
    其次,所有的加密都需要校验,只是 tcp 帮你做了而已;
    那么到 udp ,需要自己做校验,比如 crc ,然后自己实现重发机制。
    tool2dx
        3
    tool2dx  
    OP
       30 天前
    @TomVista 就是最普通的 UDP 数据,用 socket api 写的,数据包在网络裸奔太危险,但是暂时没想到很好的加密方式。

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

    可惜 RSA 加密太慢了,要不然还挺合适的。UDP 都是固定长度,而且分包都很小。
    tool2dx
        4
    tool2dx  
    OP
       30 天前
    @b821025551b 好的 UDP 协议应该允许一定程度的丢包,现在都是全球互联网,晚高峰跨国发数据丢个包,实在是太正常了。

    如果都按照 TCP 的方法,1234 数据包都依次排序,严格校验数据包漏发和错发,那是可以用 AES 的,但就是失去了 UDP 的优势和意义。
    forvvvv123
        5
    forvvvv123  
       30 天前   ❤️ 2
    @tool2dx OP 看一下 CTR 模式,AES 的话就是 AES-CTR ,每个分组可以并行解密不依赖顺序,适合你的场景。
    tool2dx
        6
    tool2dx  
    OP
       30 天前
    @forvvvv123 感谢,似乎可行,我去研究一下。

    AES 有 CBC ,CFB ,GCM ,ECB 各种模式,被绕晕了。
    duanxianze
        7
    duanxianze  
       30 天前   ❤️ 1
    我不懂 upd,aes ,但我觉得你都搞加密了,使用 udp 带来的节省似乎不足以抵消你加密造成的消耗,还不如老老实实用类似 https ,wss 之类的现成协议了
    byte10
        8
    byte10  
       30 天前
    楼上说的 AES-CTR 就是流式加密,你说的那个分组加密不行,但是流式加密 也需要知道包的 index 位置,所以丢失了还是不行,头大。对 UDP 不熟悉,如果你加上重传,又把校验加上,还不是又绕回来 tcp 这边了么。
    tool2dx
        9
    tool2dx  
    OP
       30 天前
    @byte10 TCP 丢包惩罚太凶,交通拥堵的时候,就很容易进入不可用状态。虽然开 BBR 能缓解一定效果,但是这是单向的开关,下载快,上传还是很慢。

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

    国内服务器 TCP 确实够用了,可惜有国外业务,只能硬着头皮上 UDP 了,要不然真的太卡了。
    ryan4290
        10
    ryan4290  
       30 天前
    QUIC 能尝试一下,解决你的问题吗?
    caola
        11
    caola  
       30 天前   ❤️ 1
    @tool2dx 有现成的 QUIC 协议 或 HTTP/3 直接拿来就用,不用自己关心底层是怎么实现的,你就当他是普通的 TCP 就可以了
    w3b5h3ll
        12
    w3b5h3ll  
       30 天前
    加密不是应用层,更 udp 没关系吧
    ysc3839
        13
    ysc3839  
       30 天前 via Android
    要 UDP+加密的话,为什么不直接用 DTLS ?
    cheng6563
        14
    cheng6563  
       30 天前
    @byte10 楼上说的 AES-CTR 就是流式加密,你说的那个分组加密不行,但是流式加密 也需要知道包的 index 位置,所以丢失了还是不行,头大。对 UDP 不熟悉,如果你加上重传,又把校验加上,还不是又绕回来 tcp 这边了么。


    还是有点不一样,udp 客户端可以手动控制重复发包,比如检测到网络波动就双倍发包
    ho121
        15
    ho121  
       30 天前 via Android
    把每个 udp 报文都当作一个新的流不行吗?
    就像加密文件一样,每个 udp 包都当作独立的文件。
    slack
        16
    slack  
       30 天前 via Android
    能的,最近在研究 i2p ,里面就是用的 ssu2 。
    minami
        17
    minami  
       30 天前
    这个倒不用担心,一般人不会直接用 UDP ,都是用 SRTP 或者 QUIC 这些更上层协议,它们都有加密功能
    leloext
        18
    leloext  
       30 天前
    有重传机制就没问题了,如果 udp 真不能用 aes 加密的话,那么 kcptun 也不会存在;想知道底层的话可以看看它的源码。
    mt7620
        19
    mt7620  
       30 天前
    github -> kcptun
    leonshaw
        20
    leonshaw  
       30 天前 via Android
    抄 ESP 呗,每个包都是独立解密的,分组是指一个包内部分成 block
    0o0O0o0O0o
        21
    0o0O0o0O0o  
       30 天前
    先挑一个基于 UDP 的可靠传输协议
    flynaj
        22
    flynaj  
       30 天前 via Android
    楼主是想发明一个 QUIC ,建议你先看看 quic 的代码。
    sduoduo233
        23
    sduoduo233  
       29 天前 via Android
    udp 可以 AES
    shadowsocks 的 udp 就是 AES GCM AEAD 的
    jheroy
        24
    jheroy  
       29 天前 via Android   ❤️ 1
    楼主这是把加密算法和加密模式弄混了,首先 ECB 模式是肯定可以用的,不过相同明文的会得到相同密文对抗分析较弱,然后就是 CTR ,只依赖包的序号,丢包也无所谓丢的宝内容虽然没了但是丢的哪些序号的包是知道的(自己维护顺序)
    GrayXu
        25
    GrayXu  
       29 天前
    中间加一层 kcp/quic?
    panda1001
        26
    panda1001  
       28 天前 via Android
    ss 就是干这个的,参考其实现,其中的流加密算法都适用。

    https://github.com/shadowsocks/shadowsocks-libev/blob/master/src/udprelay.c#L1310

    流加密基于字节的,包在字节之上,ss 只考虑加解密(传输层),无法解密的包一样扔掉,掉包是上层程序(应用层)考虑的事情

    https://github.com/shadowsocks/shadowsocks-libev/blob/master/src/udprelay.c#L872
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   933 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 19:33 · PVG 03:33 · LAX 12:33 · JFK 15:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.