讲解一下Cryptomator这个项目

Cryptomator 这个项目挺适合拿来讲的——它是「客户端加密 + 云盘无关」的典型设计，面试里问「你怎么设计一个安全的云盘加密方案」基本就是这套思路。 先说它解决的问题。把文件放 Dropbox / Google Drive / OneDrive，服务商理论上什么都能看，包括文件名和目录结构。Cryptomator 的做法是在本地建一个加密「保险箱」（vault），这个 vault 就是一个普通文件夹，放在任何会同步的目录里。挂载 vault 后你看到的是一个虚拟磁盘，读写和普通盘一样，但落到磁盘上的全是密文，同步上去的也是密文，密钥只在你自己手里。所以它不绑云、不注册账号，就是个纯本地加解密的中间层。 架构上分几层，从下往上说比较清楚。 vault 根目录只有两个元文件：vault.cryptomator 和 masterkey.cryptomator。前者是个 JWT，里面写 format 版本、cipherCombo（SIV_GCM 或 SIV_CTRMAC）、shorteningThreshold、vault UUID，并用「加密主密钥 + MAC 主密钥」拼接后做 HS256 签名。打开 vault 的顺序是：先不验签解码 JWT，读 kid 拿主密钥，再验签，再检查 format 和 cipherCombo 是否支持。这种「先读再验」的顺序是必要的，因为验签的钥匙得从文件里指过去。 masterkey.cryptomator 里存的是加密后的主密钥。两个 256 位主密钥（一个加密、一个 MAC）都是 CSPRNG 生成的，然后用 scrypt 从密码派生出一个 KEK，再用 AES Key Wrap（RFC 3394）把两个主密钥包起来存进 JSON。还有个 versionMac，是 vault 版本号的 HMAC-SHA256，用来防降级攻击。如果 vault 是 Cryptomator Hub 托管的，kid 就是 hub+[链接已隐藏]... 形式，授权用户的密钥以 JWE（ECDH-ES + A256GCM）的形式单独发给他，也就是说 Hub 场景下支持吊销和团队授权。 文件内容加密这块分了 header + 分块。每个文件开头 68 字节 header：12 字节 nonce、40 字节 payload、16 字节 tag，payload 是 8 字节填充（以前放文件大小）+ 32 字节随机生成的文件内容密钥，用加密主密钥 AES-GCM 加密。接着正文按 32 KiB 切块，每块也是 12 字节 nonce + 密文 + 16 字节 tag，GCM 的 AAD 是「64 位大端块序号 ‖ header nonce」。这两个 AAD 设计得很关键：块序号防止块被重排或调换，header nonce 把每块绑定到这个文件的 header 上，防止把别的文件的内容拼过来。也就是说流式解密时可以逐块校验，而且改任何一块都会被抓到。 文件名和目录结构是它比很多同类工具多做的一步。每个目录有个 dirId（根目录是空字符串，其他推荐 UUID）。子目录在密文里的实际路径是这样算的：先 AES-SIV 加密 dirId，再 SHA-1，再 Base32，然后切成 vault/d/ 前 2 字符 / 后 30 字符。结果是密文目录被拍平成一层「/d/XX/..."」的兄弟结构，明文里的层级完全看不出来，这就是所谓 flatten。 文件名的加密用 AES-SIV（RFC 5297），把父目录的 dirId 作为 associated data 传进去，输出 base64url 加.c9r 后缀。这个设计有两个安全作用：一是同样的文件名在不同目录下密文不同，二是文件被挪到别的目录后，用新父目录 dirId 解密会失败，能检测到未授权的移动。目录节点本身不使用独立文件名，而是存成目录，里面放一个 dir.c9r 文件装着 dirId；符号链接类似，是 symlink.c9r 装加密后的指向。长文件名超过 220 字符会退化成「SHA-1 +.c9s」目录，里面放 name.c9s（原名映射）和 contents.c9r（真正的文件内容）。另外还有可选的 dirid.c9r 备份层，用来防止 dir.c9r 丢了导致整个子树名字失联——这个不算安全强化，纯粹是可恢复性。 虚拟文件系统的前端就是 WinFsp（Windows）、macFUSE（macOS）、FUSE（Linux），都没有就退到 WebDAV，只监听本机 loopback，所以浏览器和文件管理器都能当普通挂载用。 安全边界这部分值得单独记，因为面试官大概率会拿这个追问。它明确不保证的是：本机被恶意软件感染、键盘记录、程序自己产生备份副本（比如 Office 的临时文件）。它不加密元数据：访问/修改/创建时间、文件数量、文件大小都能被云服务商看到。它是可识别的——.c9r /.c9s 后缀和两个配置文件名一看就知道用了 Cryptomator，它不是隐写工具。还有一个官方接受的低风险缺陷：有写权限的攻击者可以在同一目录内交换两个密文文件名，内容依然安全、篡改也会被发现，但文件名和内容的映射会错乱；因为要做「文件名与内容密码学绑定」对移动端和网络磁盘性能影响太大，所以他们选择接受并在安全公告里写清楚。 拿它和别的方案对比能说明取舍：VeraCrypt 那类容器文件是整体一个加密卷，元数据也藏得更好，但同步时每次改动都是整个大文件变化，冲突几乎无解；Cryptomator 是逐文件加密，天然适配同步和冲突处理，代价是暴露大小、时间、数量。所以它才特意注明「不是容器型工具的完整替代品」。 如果你要更深的方向可以挑：想聊设计就深挖 AES-SIV 为什么适合文件名（确定性且能用 associated data 绑定父目录）、想聊性能就聊 32 KiB 分块和 GCM 的流式校验、想聊工程就聊 dir.c9r 单点失效和 Hub 的密钥分发。你是想拿它当面试素材，还是打算自己写个类似的加密层？说清楚我能往那个方向展开。