从 Haskell 到 Go：记一次 RSA 加密协议移植与“字节陷阱”排查实录

1. 背景与目标

本次任务的目标是将一个用 Haskell 编写的加密传输协议（Metro.TP.RSA）移植到 Go 语言中，并封装为标准的 net.Conn 接口，以便替换原有的 XORConn 实现。

该协议不仅仅是简单的加密，还是一个带有状态协商的混合协议，主要包含以下特性：

身份握手：基于 RSA 公私钥交换指纹（SHA256），验证客户端和服务端的合法性。
模式协商：支持三种传输模式：
- Plain (0): 明文直连。
- RSA (1): 全程使用 RSA-OAEP 加密（传统/兼容模式）。
- AES (2): 使用协商出的 Session Key 进行 AES-256-CTR 加密（高性能模式）。

2. 遇到的核心问题

在初步移植完成后，我们遇到了一个非常诡异的现象：

Plain 模式：一切正常，握手成功，数据传输流畅。
AES/RSA 模式：握手看似完成，但随后连接陷入"假死"状态（Hang），无法读取数据。

通常如果是加密算法错误（如 IV 错误、Padding 错误），程序往往会直接报错（Decryption Failed）。这种"卡住"的现象通常意味着协议状态机不同步或**数据分包（Framing）**出了问题。

3. 深度排查：字节级"脑裂"

经过排查，问题的根源隐藏在 Haskell 和 Go 对枚举类型（Enum）默认序列化行为的差异中。

3.1 协议差异分析

Haskell 端 (Data.Binary)：

RSAMode 派生自 Generic。对于这种简单的 Sum Type（枚举），Haskell 的标准二进制库将其编码为 1 个字节的索引值（0, 1, 2）。
Go 端 (旧代码)：

我们在发送模式时，习惯性地使用了 binary.BigEndian.PutUint64，发送了 8 个字节。

3.2 故障重现

当 Go 客户端请求 AES 模式 (2) 时，发生了以下交互：

Go 发送 ：00 00 00 00 00 00 00 02 (8字节)。
Haskell 接收 ：读取 1个字节 ，读到了 00。
Haskell 状态 ：00 对应 Plain 模式。Haskell 认为协商结束，进入明文接收状态。
Go 状态：发送完毕，认为协商成功，进入 AES 模式，开始发送加密后的 Session Key。
结果（脑裂） ：
- Haskell 在等明文应用数据。
- Go 发送了一堆加密的二进制流（Session Key）。
- Haskell 读入这些乱码试图处理，导致逻辑错乱或在等待后续数据包头（Length Header）时无限阻塞。

3.3 为什么 Plain 模式能跑通？

这是一个极具迷惑性的巧合。

当 Go 请求 Plain (0) 时，发送的是 00 00 00 00 00 00 00 00。

Haskell 读取第一个字节 00，解析为 Plain。

虽然 Go 多发了7个字节的 00，但因为后续是明文传输，这几个空字节可能被应用层忽略或恰好未造成严重破坏（视具体应用层协议而定），从而掩盖了 bug。

4. 解决方案与最终实现

4.1 修复序列化

将 Go 代码中的模式发送与接收严格限制为 1 字节：

go 复制代码

// 发送 (Client)
modeByte := []byte{byte(mode)}
c.sendDataOAEP(modeByte)

// 接收 (Server)
modeBytes, _ := c.recvDataOAEP()
mode := int(modeBytes[0])

4.2 完善流式处理

由于 AES-CTR 是流加密，但协议定义了 [Length][IV][Body] 的封包格式，而 net.Conn.Read 是流式的。为了防止 TCP 粘包或断包导致解密失败，我们在 Go 结构体中引入了 bytes.Buffer：

go 复制代码

type RSAConn struct {
    net.Conn
    // ... keys ...
    readBuf bytes.Buffer // 关键：内部缓冲
}

func (c *RSAConn) Read(b []byte) (n int, err error) {
    // 优先从缓冲区吐出已解密数据
    if c.readBuf.Len() > 0 {
        return c.readBuf.Read(b)
    }
    // 缓冲区空，从网络读取完整的一个加密包，解密后填入缓冲区
    // ... recvDataAES logic ...
}

5. 总结与经验

跨语言协议必须精确到字节 ：不要假设 Int 是 4 字节还是 8 字节，也不要依赖语言特定的序列化库（如 Haskell 的 Generic 或 Go 的 gob），除非你完全掌控两端的实现。明确规定 uint8、uint64 (BigEndian) 是最稳妥的。
警惕"部分正常"的 Bug：Plain 模式的正常运行是最大的干扰项，它让我们误以为握手逻辑是完美的，从而将排查方向引向了复杂的加密算法本身，实际上问题只是简单的类型宽度不匹配。
流式接口的适配 ：将基于包（Packet-based）的协议适配到流（Stream-based）接口（如 io.Reader）时，必须实现内部缓冲机制，否则极易出现粘包处理不当的问题。

通过这次修复，我们成功实现了一个兼容 Haskell 后端、支持 RSA 身份验证和 AES 高速加密的 Go 语言传输层模块，为后续的服务端功能扩展（如 CS2 开箱服务）打下了坚实基础。