CXPLAY on Nostr: gocryptfs 和 cppcryptfs 是同一个加密方案的实现, ...

gocryptfs 和 cppcryptfs 是同一个加密方案的实现, 缺陷是不混淆文件目录结构和文件体积.
另一个专为云备份设计的加密文件系统 CryFS 对比了包括以上两种(实际上一种)以及流行的 TrueCrypt/VeraCrypt, EncFS, eCryptfs 的优缺点:
> https://www.cryfs.org/comparison

但 CryFS 的对比文章里缺少了 #Cryptomator 的对比, 根据自己的使用体验, CryFS 实际上是比 Cryptomator 更先进的一种设计, 支持了更多 Cryptomator 没有的特性, 比如: 保护文件内容免遭恶意修改, 保护文件元数据和文件大小免遭恶意修改, 保护目录结构免遭恶意修改.
这三个特性是以上所有加密文件系统都有的问题, 即只要加密后的目录结构和文件名被篡改, 整个加密库就会损坏, 无法挂载. CryFS 的为了避免这种情况, 会把所有进入加密挂载点的文件切分成 16KiB 大小的分块, 分散保存在加密后的文件系统各处, 可以做到损失部分分块和目录结构也能正常挂载加密库. 不过, 受损分块对应的完整文件是没办法恢复的, 在挂载点中对应的这个文件将会无法被操作(删除, 复制, 移动和读取).

16KiB 这个分块大小是 Linux 常用的 ext4 文件系统的默认格式化「块」(在 Windows/NTFS 叫「簇」)大小的两倍, 可能是权衡了 4KiB 性能和未加密文件最小体积的结果.
Windows 现在为 NTFS 的默认格式化的簇大小是 4KiB, 如果被格式化为了大于 4KiB 以上的簇大小, 那么 NTFS 特性之一的透明压缩功能将会无法在这个磁盘启用.

CryFS 的 16KiB 对于大多数现代的文件系统来说不是问题, 但是对于硬盘来说, 即使是现代的 NVMe SSD 来说, 16KiB 虽然并不能直接对比极限的 4KiB 性能, 但是数量一旦多起来, 跨磁盘备份操作也会非常痛苦, 一个 100MiB 的文件都能被切分为 6400 个块. 虽然 CryFS 通过分块实现了 Cryptomator 没有的功能, 但是代价是加密性能会变得更差.

CryFS 使用 C++ 编写, Cryptomator 使用 Java 编写. 前者支持良好的只有 Linux 和 macOS, Windows 上还存在大量问题, 并且目前只有命令行客户端, 虽然一个叫 SiriKali 的项目使用 QT 给包括 Cryfs 在内的文件系统加密后端适配了一个桌面 GUI, 但这个 GUI 的体验相比后者还有很大欠缺, 在 Android 上目前可以使用 DroidFS 来兼容 CryFS 和 gocryptfs 的使用.
所以目前来说, 仅在 Linux, macOS 和 Android 上, CryFS 才是 Cryptomator 的完全替代品. 但 16KiB 的分块特性可能在某些储存介质和备份方案上并不能称之为有效提升.