Croc：基于 PAKE 密码认证的跨平台端到端加密文件传输工具

Croc 真正解决的是"如何在两台任意电脑之间安全地传文件"这个老问题——不需要公网 IP、不需要端口映射、不需要注册账号、不需要上传到第三方服务器，同时还能保证端到端加密。

在它之前，大多数方案都有明显的短板：scp/sftp 需要双方能直连；WeTransfer 之类的网页工具需要把文件上传到中间服务器；局域网传输工具出了内网就用不了。而 Croc 用一个相对优雅的技术组合解决了这些问题：由 Go 编写的命令行工具，作者是 schollz，完全开源。

系统地图：Croc 的四层技术架构

这四层设计的核心优势是：用户只需要记住一串简短助记词，就能在底层获得完整的加密安全保障——不需要理解密码学，也不需要手动交换密钥。

四层的边界划分是刻意的：加密层负责"安全"，传输层只负责"转发"。两层互不耦合，决定了整个系统的信任模型（下文详述）。

为什么 PAKE 是这项技术的核心

Croc 使用的是 PAKE（Password Authenticated Key Exchange，密码认证密钥交换） 协议，这是它与其他文件传输工具最大的区别。

传统的密钥交换有两种模式：

1. 公钥加密：双方需要先知道对方的公钥，但如何安全地交换公钥本身就是个问题
2. 对称加密：需要一个共享密钥，但如何在不安全的信道上安全地交换密钥？

PAKE 解决的就是这个问题：双方只需要共享一个短口令，就可以在协议层协商出一个安全的会话密钥，而攻击者即使截获了所有流量，也无法获得这个密钥。

更重要的是：即使口令强度不高，PAKE 协议也能让离线暴力破解失效——PAKE 的关键设计是在每一轮猜测中都必须与通信对端做一次真实交互，攻击者无法把抓到的报文拿回去离线穷举。这让"破解口令"从"算得快就行"变成"必须在线上一次次试探"，攻击代价大幅上升。

这就是为什么 Croc 只需要几个助记词就能达到很高的安全性——不是因为口令本身难以猜测，而是因为协议本身把暴力破解限制在了线、逐次进行的量级。

核心机制拆解

1. 中继模式：无需直连

Croc 使用中继服务器来连接两台无法直连的电脑：

• 发送方连接到中继服务器，生成一个 code phrase（例如 croc-apple-banana-cherry）
• 接收方用同一个 code phrase 连接到中继服务器
• 中继服务器把两方的连接对接起来，数据开始流动

关键在于：中继服务器只能看到加密后的数据流，无法解密内容。它只负责转发，不存储、不解密。

这意味着即使中继服务器被攻破，攻击者也无法获得传输的文件内容——因为密钥只存在于发送方和接收方的本地，从未离开过两端。

2. 端到端加密流程

一次完整的加密传输流程是这样的：

1. 发送方和接收方通过 PAKE 协议协商出一个共享会话密钥（双方都不需要暴露自己的私钥）
2. 发送方用认证加密算法加密文件内容
3. 加密后的数据通过中继服务器转发
4. 接收方用会话密钥解密数据，并校验完整性与真实性
5. 传输完成后会话密钥即被丢弃

整个过程中，未加密的明文数据永远不会离开发送方和接收方的本地机器。文件包本身还有一个重要细节：文件元信息（文件名、大小）也由加密层保护，中继端看到只有密文，拿不到文件名与内容。

3. 断点续传与多文件支持

Croc 支持在传输中断后从断点恢复，而不需要从头开始：

• 发送方和接收方会以哈希标识对已传输的块做校验
• 如果接收方已经有部分数据，会通知发送方从剩余处继续
• 传输进度会实时显示在终端上

同时支持一次传输多个文件或整个文件夹，也可以显式列出多个文件与文件夹一起发送。对超大文件而言，断点续传意味着几十 GB 也不会因为一次断网就前功尽弃。

4. IPv6 优先与代理支持

Croc 默认 IPv6 优先、IPv4 兜底，这在未来网络环境中会越来越重要。同时支持通过 --socks5 走 SOCKS5 代理（例如 Tor），可以满足更高的匿名性需求——代理只负责传输路径，文件内容依旧是端到端加密的。

常用命令速查

以下命令均可在发送或接收端灵活组合：

自建中继：把信任握在自己手里

Croc 默认使用公开中继，但既然完全开源，也支持自建中继：

croc relay

• 默认监听 TCP 端口 9009-9013，至少需要 2 个端口
• 用 --ports 1111,1112 可自定义端口范围
• 发送方 / 接收方通过 --relay "myrelay.example.com:9009" 指定自己的中继

自建中继的价值有二：一是内网或隔离网络里无法访问公开中继时可自建出口；二是把"转发流量"这一环完全掌控在自己手里，进一步收紧信任边界。需要注意的是，自建中继依然看不到明文——它只是把加密的传输层也从默认服务商那里收回来而已。

一个典型的文件传输流程

让我们看看"发送方 A 给接收方 B 传一个大文件"的完整流程：

1. A 在终端输入 croc send big-file.zip
2. Croc 生成 code phrase：croc-apple-banana-cherry
3. A 通过聊天工具把这个 code phrase 发给 B
4. B 在终端输入 croc croc-apple-banana-cherry
5. A 和 B 通过 PAKE 协议在本地协商出共享会话密钥（中继服务器全程看不到这个密钥）
6. A 用认证加密加密文件，并通过中继服务器转发给 B
7. B 接收加密数据，在本地解密，实时显示进度
8. 如果网络中断，任何一方重新执行命令即可从断点继续
9. 传输完成，会话密钥被丢弃

整个过程中，A 和 B 都不需要知道对方的 IP 地址，也不需要配置任何端口映射或网络参数。

安全与隐私约定

这里把 Croc 的安全性质明确为四条"约定"，方便你判断它在自己的场景下是否够用：

• 中继无知情权：中继只能看到密文，拿不到文件名、内容和会话密钥；被攻破也不泄露文件。
• 信任锚是口令：code phrase 是唯一的访问凭证。它应通过可信信道（如加密聊天）传递给接收方，且不要在同一会话里反复使用同一个口令，避免在线上为攻击者堆积试探机会。
• 进程列表也会泄露秘密：在 Linux / macOS 上，若把 code phrase 直接作为命令行参数传入，它可能短暂出现在进程列表中（相关安全公告为 CVE-2023-43621）。官方建议改用环境变量传入密钥（CROC_SECRET=... croc），或在单用户系统上用 croc --classic 恢复传统行为。
• 传输优先直连：在理想网络下双方可建立端到端直连（P2P），中继只在无法直连时作为回退通道介入，进一步减少数据经过中间节点的机会。

适用边界与采用建议

谁应该优先使用

• 需要跨平台传文件的人：Windows、Linux、Mac 之间互传，再也不用找 U 盘了。
• 需要传大文件的人：断点续传意味着即使传几十 GB 的文件也不怕断网。
• 注重隐私的用户：文件不会在第三方服务器明文落地，只有发送方和接收方能解密。
• CLI 用户：在终端就能完成所有操作，不需要打开浏览器，也方便脚本化。

谁可以暂时不用

• 只在同一局域网内传输：局域网直连速度可能更合适，且无需依赖中继。
• 传输极度敏感的数据：虽然 PAKE 协议很安全，但极端敏感场景可能还是需要物理介质。
• 完全不会用命令行的用户：Croc 主要面向 CLI，虽然有浏览器版（getcroc.com）可以免安装收发，但完整能力仍在命令行。

采用顺序

1. 先安装：brew install croc，或用对应平台的其他包管理器（scoop、choco、Nix、pacman、pkg 等）。
2. 试传一个小文件，体验基本流程。
3. 尝试传文件夹和大文件，测试断点续传功能。
4. 落到正式使用前，最好自建一个中继（croc relay），把传输链路也收进自己手里。
5. 有需要时，配置 --socks5 通过 Tor 等代理传输以提高匿名性。

总结

Croc 是那种"用了就再也回不去"的工具——它把一个复杂的问题（安全跨平台文件传输）封装成了极其简单的用户体验：发送方输入命令得到一串助记词，接收方输入这串助记词，文件就开始传了。

这种"简单的用户界面 + 扎实的底层技术"的组合，在开源工具中并不多见。大多数工具要么界面简单但技术上有妥协，要么技术很牛但用户体验一塌糊涂。而 Croc 两者都做到了：PAKE 端到端加密做得稳，入口却收敛成一行命令。

如果你还在为"怎么把这个大文件传给另一台电脑"而烦恼，Croc 值得你立即尝试——你唯一需要记住的，就是那串助记词。