croc：用 PAKE 加密解决“无公网也能安全传文件“的命令行工具
信息充足，下面直接输出完整笔记。
croc：用 PAKE 加密解决"无公网也能安全传文件"的命令行工具
一句话定位：croc 是一个用 Go 编写的 CLI 文件传输工具，核心价值不是"又一个传文件的"，而是把PAKE（密码认证密钥协商）这个密码学协议做成了零配置的日常命令——它处于"成熟可用"而非"前沿实验"阶段，是渐进优化，不是范式突破，但它把正确的工程决策组合到了一起。
核心观点
croc 作者在 README 里声称这是唯一同时满足以下所有条件的 CLI 传文件工具：
- 通过中继（relay）让任意两台机器互通，不需要端口转发
- 使用PAKE做端到端加密，密钥不经过中继服务器
- 支持跨平台（Win / Mac / Linux / Android）
- 支持多文件、文件夹、断点续传
- IPv6 优先，IPv4 回退
- 可接 Tor 或 SOCKS5 代理
这个"同时满足"的说法是有含量的——后面交叉验证部分会核实。
最核心的机制：PAKE 让中继服务器"瞎了眼"
croc 最巧妙的设计只有一个点：中继服务器只负责中转 TCP 流量，永远看不到明文。
具体流程：
- 发送方运行
croc send，终端打印一个随机 code phrase（如purple-monkey-dishwasher） - 接收方输入这个 code phrase，双方通过PAKE协议在不可信的中继通道上协商出一个共享对称密钥
- 之后的数据流用AES-GCM加密，中继服务器只是一个哑管道
PAKE 的关键特性是：即使攻击者截获了完整通信记录，也无法暴力破解 code phrase（每次尝试都需要真实发起一次握手，服务器可以限速）。这比传统"发文件链接+密码"的方案安全很多，后者的密码容易被中间人直接拿走。
# 发送方（自动生成 code phrase） $ croc send ./report.pdf Sending 'report.pdf' (2.1 MB) Code is: 7-skydive-cornea # 接收方（任意平台，任意网络） $ croc 7-skydive-corneaLinux/macOS 下为防止 code phrase 泄漏到进程名（CVE-2023-43621），接收时用环境变量传参：
CROC_SECRET=7-skydive-cornea croc其他常用操作：
# 发多文件+排除目录 croc send --exclude "node_modules,.venv" ./my-project # 管道传输（流式） cat db_dump.sql | croc send # 接收并输出到 stdout croc --yes 7-skydive-cornea > db_dump.sql # 自建中继（最少 2 个端口） croc relay --ports 9009,9010 # 通过自建中继发文件 croc --relay "myrelay.example.com:9009" send ./file放进历史脉络里看：croc 比什么更好？
| 工具 | 加密 | 中继 | 断点续传 | 依赖 |
|---|---|---|---|---|
| scp / rsync | 有（SSH） | ❌ 需直连或 VPN | ❌ | 需 SSH 账号 |
| magic-wormhole | SPAKE2（更严谨） | ✅ 但不参与传输 | ❌ | Python 生态 |
| croc | PAKE + AES-GCM | ✅ 参与但不解密 | ✅ | 单个 Go 二进制 |
| 局域网拖拽/AirDrop | 部分 | ❌ 跨网不行 | ❌ | 同网段 |
croc 比 scp 好在哪：scp 要求双方都有 SSH 访问权限，企业防火墙经常拦 22 端口，croc 用普通 TCP 9009-9013，更容易穿透。
croc 比 magic-wormhole 好在哪：根据 CSDN 的对比测评（见交叉验证节），croc 速度快约 18%，弱网断线恢复快 2.8 倍，且 Go 单二进制比 Python 环境更容易分发。但 magic-wormhole 的中继服务器不参与数据传输，在架构上更干净——croc 的中继虽然看不到明文，但确实承载了全部流量带宽，运营成本更高。
交叉验证
信源一：CSDN《croc vs magic-wormhole 技术深度对比》（2025-09）
- 认同 croc 的速度优势（85.6 Mbps vs 72.3 Mbps，测试 1GB 文件）
- 认同断点续传是 croc 的决定性差异（magic-wormhole 在 30% 丢包率下测试失败）
- 补充了一个原文没说清楚的点：magic-wormhole 的中继架构更轻量，中继只做信令不做数据，而 croc 中继需要承担全部流量带宽——这意味着使用 croc 官方公共中继时，带宽受限于中继服务器，建议大文件用户自建中继
- 在安全性上补充：magic-wormhole 使用 Curve25519 + SPAKE2，密钥协商上比 croc 的自定义 PAKE 实现更经过学术验证；croc 的安全性够用，但不是最严谨的选项
信源二：知乎《magic-wormhole 神奇虫洞介绍》（2021）
- 侧面印证：magic-wormhole 早于 croc 使用了 PAKE 思路，croc 的作者在 README 致谢中也明确写了"感谢 @warner 的想法"——@warner 正是 magic-wormhole 的原作者。这说明 croc 在设计上有意学习了 magic-wormhole，再加上工程化打磨
- 补充了负面信息：magic-wormhole 社区反映其传输大文件稳定性不如 croc，这与对比测评的结论一致
综合判断：两个独立信源基本认同原文的核心主张，同时揭示了原文未充分说明的架构代价——croc 用"中继参与传输"换取了更简单的使用体验和断点续传能力，这是一个合理的工程取舍，但不是没有成本。
边界与局限（原文没说透的）
- 官方公共中继是单点：默认使用
croc.schollz.com，这个服务器宕机或被封锁（国内用户注意），传输就失败。企业敏感数据不应该走任何公共中继，必须自建。 - code phrase 安全性依赖随机性：生成的 5-7 个单词短语熵值约 60 bit，对于临时性传输够用，但如果 code phrase 通过不安全渠道（如微信）传给对方，中间人窃取后可以抢在真正接收者之前连接——croc 本身有防护（PAKE 只允许一次握手），但用户心理上容易掉以轻心。
- 中继流量可见性：加密的是内容，但"谁在什么时间传了多大的文件"对中继运营者是可见的，有元数据泄漏。Tor 代理可缓解，但大多数用户不会用。
- 文章声称"唯一满足所有条件的 CLI 工具"——这是一个典型的时效性声明，随时可能被新工具打破，读者不必当真，核心是理解它在当前工具矩阵里的定位。
推演：接下来会怎样
croc 的 Go 单二进制 + 自建中继的组合，正好踩在了企业内网文件分发和开发者工作流两个场景的需求上。可以预见：
- 国内镜像和 CI/CD 集成（如 Dockerfile artifact 传输）会越来越多地用到它
- 随着
--exclude和--quiet等自动化友好参数的完善，croc 被嵌入脚本的频率会提升 - 但浏览器端或 Web UI 方向不是它的重点——Android 的两个 F-Droid 客户端质量参差不齐，移动端体验仍是短板
- magic-wormhole 生态（Python）和 croc 生态（Go/CLI）大概率长期共存，不会有一方消灭另一方
个人启发
对开发者：把 croc 加入你的工具箱，替代"发百度网盘链接"或"用微信传文件"这两个低安全性习惯。尤其是跨公司传代码包、配置文件时，croc send + 电话念 code比任何云盘都安全。
对运维/DevOps：在 CI 管道里有一类场景——构建产物需要从内网传到隔离环境——croc 自建中继 +--quiet静默模式几乎是零成本的解决方案，不需要搭 FTP/SMB。
对企业决策者：不要让员工用公共中继传敏感数据。部署一个自建 croc relay 的成本极低（Docker 一行命令），但能把数据流量控制在内部。
延伸思考
PAKE 为什么没有更早普及？PAKE 协议在学术上已有几十年历史，但直到 croc 这类工具出现才在日常工具中可见——是密码学落地工程化太难，还是行业教育不足？未来哪些场景会是下一个 PAKE 普及点（比如 SSH 密钥替代）？
"中继参与传输" vs "中继只做信令"的设计选择，本质是在易用性（断点续传、NAT 穿透）和架构纯洁性之间的取舍。随着 WebRTC / QUIC 成熟，未来是否会有工具把两者都做好——既不依赖中继带宽，又支持断线重连？
croc 依赖作者个人维护公共中继服务器，README 里也明确呼吁赞助。开源基础设施的可持续性问题在这里非常具体：如果 schollz 停止维护，不自建中继的用户会立刻受影响——这提醒我们评估任何依赖公共端点的工具时，都应该把"是否可自托管"作为一级评估维度。
📚 参考来源
- GitHub - schollz/croc: Easily and securely send things from one computer to another :package: · GitHub