信息充足下面直接输出完整笔记。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_SECRET7-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-wormholeSPAKE2更严谨✅ 但不参与传输❌Python 生态crocPAKE 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
