请求与响应加解密

代理服务与 Captcha Ruler 中转服务之间的通信使用 AES-128-CBC 加密，每次请求动态生成密钥。

加密方案

• 算法：AES-128-CBC + PKCS7 填充
• 密钥来源：每次请求随机生成 32 字节 token，Base64URL 编码后作为 Authorization header 传递
• 请求和响应使用不同的 key/IV 偏移，防止重放

Token 生成

每次请求生成 32 字节随机数据，Base64URL 编码为约 43 字符的字符串：

Authorization: <token>

该 token 同时用于派生加密密钥和 IV。

请求加密（代理 → 中转服务）

从 token 中派生：

参数	取值
Key	token[0:16]（前 16 字节）
IV	token[len-16:]（末 16 字节）

流程：

1. 序列化请求 JSON
2. AES-CBC 加密 + PKCS7 填充
3. Base64 编码
4. 包装为 {"data": "<base64_encrypted>"}
5. POST 发送，header 携带 Authorization: <token>

响应解密（中转服务 → 代理）

使用相同 token，但偏移 1 字节：

参数	取值
Key	token[1:17]（偏移 1 的 16 字节）
IV	token[len-17:len-1]（偏移 1 的末 16 字节）

流程：

1. 接收响应 {"data": "<base64_encrypted>"}
2. Base64 解码
3. AES-CBC 解密 + 去除 PKCS7 填充
4. 得到明文 JSON 响应

请求头说明

代理转发时需要携带的 header：

Header	说明
Authorization	随机生成的加密 token（非 Bearer Token）
Content-Type	application/json
X-Product-Name	产品标识（由代理根据业务方 token 映射）

注意事项

• 每次请求必须生成新的随机 token，不可复用
• 请求和响应的 key/IV 偏移不同（0/16 vs 1/17），确保双向密钥隔离
• 此加密仅用于代理与中转服务之间的传输层，与配置文件的 AES 加密无关

AI Skill

提供了一份 AI 可加载的 Skill 文件，包含完整的加解密规范和 Go 参考实现，AI 加载后可直接生成任意语言的实现代码：

查看 | 下载