tcp 流加密问题

[longkas239]

用 chacha20 加密流，chacha20 在传输开始时初始化，之后不改变加密参数，理论上 tcp 保证了到达顺序，就算 tcp 拆包，客户端持续解包数据应该正常。现在情况是传了 100 多 k 后数据不对了，有可能是哪里问题，在用 rust 的异步调用，有可能与之有关吗

[unnamedhao]

因为 tcp 有粘包,需要拆包

[MatDK]

有没有可能是这样。 例如你用 chacha20 加密了 data1,2,3,4,5，长度都为 64 。
前面的 data1,2,3 是分别以 tcp1,2,3 packet 的形式到达的，当然没有问题
到了 data4,5 可能被合并成了 1 个 tcp packet 4，长度 128，接收方并不知道这是 2 个 64 合并成的（不知道你有没有加控制字节）。
在加密时用了 2 个 64 的 keystream 。但是解密的时候直接用了 1 个 128 的 keystream，数据就不对了。

当然可能是我理解有问题....我没理解你用 chacha20 加密流，是持续的[接受 1 个，加密 1 个，发出 1 个]，还是[接受 1 个 /多个，加密 x 个定长的块，发送 x 个]。

你如果用 tcp 加密的话，升级到 tls 不就行了？把 tls 的 send,recv callback 换成你自己的。tls 会有控制字节告诉接收方到底有多少数据被加密

[GeruzoniAnsasu]

内存对齐、缓冲区分配和覆盖、分片大小的边缘条件、计数器某种溢出……

你应该本地 dump 一份远程 dump 一份然后逐环节核对，100k 也不大，二分几次应该还比较容易找到错误开始的位置

[longkas239]

谢谢楼上兄弟们，我好像有思路了，虽然两端加密参数不动，持续加密解密数据流后两端数据应当是一致的。但是前提是一端发送的所有数据另一端必须全接收到，如果发生丢包，接收端的加密算法的状态就和服务端不一致了，后续解密也就全错。 解决办法是拆成小包加密解密，包不全丢弃，每个新包开始后对两端的加密算法统一

[unnamedhao]

tcp 不会丢包但是会粘包
发送三次[0123][456][789] -> 接收两次[1234][56789]

[unnamedhao]

所以要自己做消息头,例如添加发送消息的长度,自行处理拆包

[byaiu]

为啥要自己重新发明一遍 tls ？

[soki]

tcp 是流，哪来的包，何来粘包一说，那是应用层的事

[labulaka521]

可以给加个 fec 来减少丢包的错误