如何安全管理 OpenFlux 共享密钥：传输、存储与轮换实战指南
OpenFlux 是一款网络栈研究工具，通过可插拔的传输层构建 TCP 隧道。当启用传输加密时，客户端与出口节点共用的**共享密钥（shared secret）**就是整条隧道的安全命门——密钥如何传递、放在哪里、什么时候换，直接决定了隧道是否真正私密。本文面向新手，讲清 OpenFlux 密钥的完整生命周期管理。
OpenFlux 中的共享密钥是什么？
OpenFlux 的加密层是可选的：不配置密钥时隧道不加密；一旦通过--encryption-key-file参数指定密钥文件，所有流量就会被端到端加密，传输通道（如 Yandex Docs 游标消息）上只能看到密文。
密钥在启动时从文件一次性读入并做TrimSpace处理，源码见 main.go 的参数定义和 main.go 的加载逻辑。注意两点：
- 两端必须使用完全相同的密钥（含结尾空格都要一致），否则直接解密失败；
- context 参数（通常是文档 URL）只是公开的 KDF 盐，不提供任何保密性，真正的安全只来自密钥本身，它必须通过"带外"（out of band）渠道双方共享，见 transport/encrypted.go 的注释说明。
密钥的三道技术防线
了解 OpenFlux 密钥是如何被使用的，才能理解管理它的重点：
- scrypt 密钥派生：明文密钥不会直接当加密密钥用，而是经 scrypt（N=32768, r=8, p=1）慢哈希派生出 32 字节主密钥，盐由
SHA256("OpenFlux encrypted transport v1" + context)生成，见 transport/encrypted.go。 - 双向独立密钥：client→exit 与 exit→client 两个方向用 HMAC-SHA256 分别派生各自的 AES-256-GCM 密钥，单向流量泄露不会拖累另一个方向，见 transport/encrypted.go。
- 防重放窗口：每个加密包都带随机 nonce，接收端维护一个上限 4096 条的 nonce 去重窗口，抓包重放会被直接丢弃，见 transport/encrypted.go。单元测试覆盖了"错误密钥、篡改包、重放包"三种攻击场景，见 transport/encrypted_test.go。
对管理者的启示：密钥一旦泄露，以上防线全部失效——GCM 还能检测篡改，但无法阻止持有密钥的人直接解密。所以密钥管理才是根本。
共享密钥的传输建议
⚠️ 核心原则：永远不要通过隧道本身传输密钥（用 OpenFlux 通道发新密钥是典型的"鸡生蛋"问题），也不要复用文档 URL 所在的聊天群。
推荐的带外传输方式，按安全性排序：
| 方式 | 适用场景 | 提示 |
|---|---|---|
| 加密即时通讯（端到端加密会话） | 与可信伙伴临时共享 | 用完可让对方删除会话 |
| 面对面 / 语音通话 | 最可靠 | 念完即止，不留文字记录 |
| 加密压缩包邮件 | 需留档的场景 | 密码与密钥分两条渠道发送 |
| 口令管理器共享（1Password、Bitwarden） | 多人长期协作 | 优先于明文剪贴板 |
密钥本身建议生成方式：随机字符串（≥16 字符，OpenFlux 的硬性下限，见 transport/encrypted.go）。可以用操作系统 CSPRNG 生成，例如openssl rand -base64 32，不要自己拼单词。
密钥存储最佳实践
密钥以纯文本文件形式存在磁盘上（--encryption-key-file指向它），因此它本质上是一个"静态秘密"，按机密文件管理：
- 文件权限：
chmod 600，属主设为运行隧道的用户；出口节点 VPS 上尤其重要，因为那里往往以 root 运行，见 main.go 中的读取流程。 - 不要提交到代码仓库：
.gitignore中显式排除密钥文件，命名避免key.txt这类会被备份脚本"顺走"的名字。 - Docker 部署时：用挂载卷或密钥管理方案注入文件，避免把密钥写进镜像层或 compose 文件明文里；参考 docker/entrypoint.sh 与 docker-compose.yml 的环境变量映射方式，密钥文件走独立通道。
- 客户端侧：桌面客户端从文件读取；移动端（iOS 客户端界面见 ContentView.swift）连接参数建议存系统钥匙串而非明文配置。
- 备份：密钥丢失 = 隧道永久失效且无法恢复。把密钥存入密码管理器"安全笔记"或加密备份，比散落在 VPS 某个角落更安全。
密钥轮换：什么时候换、怎么换
OpenFlux 没有内置轮换协议——密钥只在进程启动时读取一次，因此轮换 = 双方同时重启并指向新密钥文件。建议策略：
定期轮换：共享密钥给多方使用或存放环境变化时，按固定周期（如每 1–3 个月）更换；
事件驱动轮换：以下情况立即换钥——密钥文件权限被放宽、VPS 被入侵、参与共享的人员变动、怀疑密钥出现在聊天记录/备份中；
轮换操作步骤：
- 用带外渠道分发新密钥文件，两端确认就位（
chmod 600+ 属主正确）； - 先重启客户端，再重启出口节点（或约定同一时刻）；
- 观察日志确认出现
Transport encryption: AES-256-GCM enabled（见 main.go），验证隧道连通后，再安全删除旧密钥文件； - 若旧密钥已暴露，直接丢弃，不必"过渡期双钥"——两端密钥不一致时新包会被静默丢弃（见 transport/encrypted.go），不会造成数据错乱。
- 用带外渠道分发新密钥文件，两端确认就位（
轮换 ≠ 换 context：context（文档 URL）是公开的，换文档链接不会增加安全性，只影响 KDF 盐。
常见安全陷阱清单
- ❌ 把密钥写在 shell 命令行参数里并留在历史中——用文件 +
chmod 600； - ❌ 两端密钥有细微差别（多一个换行/空格）导致隧道静默不通——文件加载会 trim，但手动粘贴容易出错；
- ❌ 多个不相关会话共用同一个密钥——至少用不同的文档 URL 作为 context 做域分离，最好直接用不同密钥；
- ❌ 依赖 MAX token 等"账号凭证"代替共享密钥——那是平台账号凭据，泄露代价是账号被封，见 README.md 中的明确警告；
- ✅ 把"密钥文件 + 文档 URL"视为一组凭据整体管理，一起分发、一起轮换、一起销毁。
小结
OpenFlux 共享密钥管理可以浓缩为三句话：带外传输一次、文件级严格存储、事件驱动定期轮换。加密层的 scrypt 派生、双向 AES-256-GCM 与 nonce 防重放已经做好了"运行时"保护，剩下的"生命周期"保护就掌握在你手中。
相关源码入口：main.go（密钥参数与加载）、transport/encrypted.go（加密传输核心）、transport/encrypted_test.go（攻击场景测试）、ios-app/OpenFlux/ContentView.swift（iOS 连接配置界面）。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
