#吐槽
#Cryptomator 自 2017 年开始就在重构他们的 Android 客户端, 期间甚至还开发了 Cryptomator Hub 用于给加密库提供 SSO 身份管理和加密库解密. 所以到现在 Android 客户端还只是凑合能用的级别, 还不支持 Documents Provider 这种非常重要的特性(约等于挂载点功能).
> https://github.com/cryptomator/android/issues/35
这个 issue 的讨论还因为 "too heated" 被关闭了, 笑死. 在他们完成重构并给 Android 支持 Documents Provider 特性之前我估计不会考虑付费支持了.
via Nostr@cxplay
#Cryptomator 自 2017 年开始就在重构他们的 Android 客户端, 期间甚至还开发了 Cryptomator Hub 用于给加密库提供 SSO 身份管理和加密库解密. 所以到现在 Android 客户端还只是凑合能用的级别, 还不支持 Documents Provider 这种非常重要的特性(约等于挂载点功能).
> https://github.com/cryptomator/android/issues/35
这个 issue 的讨论还因为 "too heated" 被关闭了, 笑死. 在他们完成重构并给 Android 支持 Documents Provider 特性之前我估计不会考虑付费支持了.
via Nostr@cxplay
#吐槽
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 的分块特性可能在某些储存介质和备份方案上并不能称之为有效提升.
via Nostr@cxplay
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 的分块特性可能在某些储存介质和备份方案上并不能称之为有效提升.
via Nostr@cxplay
一些文件系统加密软件, #Cryptomator 的替代品.
● gocryptfs: https://github.com/rfjakob/gocryptfs
● cppcryptfs: https://github.com/bailey27/cppcryptfs
● eCryptfs: https://www.ecryptfs.org/
#Software #encryption #opensource
via CXPLAY's Memos
● gocryptfs: https://github.com/rfjakob/gocryptfs
● cppcryptfs: https://github.com/bailey27/cppcryptfs
● eCryptfs: https://www.ecryptfs.org/
#Software #encryption #opensource
via CXPLAY's Memos
#吐槽
#Cryptomator 是个很优秀的一体化加密工具, 但是没办法按需解密加密库中的文件, 加密库内的整体数据不完整的时候继续操作可能会损坏整个库. 本身它是为了 Dropbox 和 OneDrive 这类同步型云储存设计的, 按需同步是非常重要的一个功能, Dropbox 是 "仅限在线访问", OneDrive 叫做 "文件随选", Cryptomator 只能在同步客户端映射了正确文件名的位置使用, 但可惜大多数的云储存移动客户端都不能直接把仅存在云端的文件映射在本地文件系统里, 于是 Cryptomator 移动客户端也变成了一个事实上的第三方云储存客户端, 不再是一个单纯的加密软件.
解决完本地文件加密后, 还要解决元数据泄露的问题, 至少要把最基本的元数据加密 —— 文件名, 于是没办法保持文件名加密的同时还要让文件名可读, 要把加密后的元数据与原始元数据对应起来, 建立一个元数据索引数据库, 便于维护内外数据. 但是理论上 Cryptomator 的元数据索引也是随库加密的(如果真的有的话), 这应该说是合理的操作, 但也导致没办法和加密库分离使用. 不过现在本来就不适合按需解密, 再去追求分离使用元数据索引也就没有意义了.
元数据泄露无法完全避免, 即使经过加密改变了文件名或者文件特征, 产生了新的加密后文件也是含有元数据的实体, 只是给原始元数据加上了一层壳. 依旧还有其他手段取得与这个加密文件关联的元数据, 不需要知道壳里面具体套的什么娃, 只要有可疑的元数据关联上, 直接干掉就够了.
via Nostr@cxplay
#Cryptomator 是个很优秀的一体化加密工具, 但是没办法按需解密加密库中的文件, 加密库内的整体数据不完整的时候继续操作可能会损坏整个库. 本身它是为了 Dropbox 和 OneDrive 这类同步型云储存设计的, 按需同步是非常重要的一个功能, Dropbox 是 "仅限在线访问", OneDrive 叫做 "文件随选", Cryptomator 只能在同步客户端映射了正确文件名的位置使用, 但可惜大多数的云储存移动客户端都不能直接把仅存在云端的文件映射在本地文件系统里, 于是 Cryptomator 移动客户端也变成了一个事实上的第三方云储存客户端, 不再是一个单纯的加密软件.
解决完本地文件加密后, 还要解决元数据泄露的问题, 至少要把最基本的元数据加密 —— 文件名, 于是没办法保持文件名加密的同时还要让文件名可读, 要把加密后的元数据与原始元数据对应起来, 建立一个元数据索引数据库, 便于维护内外数据. 但是理论上 Cryptomator 的元数据索引也是随库加密的(如果真的有的话), 这应该说是合理的操作, 但也导致没办法和加密库分离使用. 不过现在本来就不适合按需解密, 再去追求分离使用元数据索引也就没有意义了.
元数据泄露无法完全避免, 即使经过加密改变了文件名或者文件特征, 产生了新的加密后文件也是含有元数据的实体, 只是给原始元数据加上了一层壳. 依旧还有其他手段取得与这个加密文件关联的元数据, 不需要知道壳里面具体套的什么娃, 只要有可疑的元数据关联上, 直接干掉就够了.
via Nostr@cxplay
#Cryptomator 中一个持续了三年的 Windows 的 Unicode CJK 字符问题, 会导致托盘菜单中的 CJK 字符无法正常显示. 目前任然没有解决. 看起来是上游 JDK 中的老问题, 最近有望通过新的 TrayMenuController API 实现解决.
https://github.com/cryptomator/cryptomator/issues/1474
via Nostr@cxplay
