Dropbox 速度快、可靠，而且无处不在。因此，在您放心地把最私密的文件交给它之前，问一个简单的问题是很合理的：Dropbox 的加密够用吗？ 诚实的回答是：这取决于您想要防范什么 —— 因为 Dropbox 确实加密了您的数据，只是并非以大多数人以为的那种方式。
是的，Dropbox 真的加密了您的文件
我们要客观地看待这个问题。Dropbox 并没有让您的文件裸奔。它通过两种方式保护它们：
- 传输中： 在您的设备和 Dropbox 之间移动的文件会通过 SSL/TLS 加密保护。
- 静止时： 存储在 Dropbox 服务器上的文件会使用 256 位 AES 算法进行加密。
这是货真价实的加密。对于许多日常内容来说，这已经非常合理了。如果您同步的是项目草稿、菜谱，或者是那些您原本就乐意发朋友圈的度假照片，Dropbox 内置的保护就完全足够了，您不必想太多。
那么问题出在哪？谁掌握着密钥
问题不在于加密的强度 —— 而在于谁掌握着密钥。
Dropbox 管理着您账号的加密密钥。这是他们刻意为之的设计选择：正是这使得您可以在忘记密码时重置密码、在浏览器中预览文档，或者恢复已删除的文件。但这也意味着 Dropbox 的系统能够解密您的文件。把密钥交在别人手里的加密，只能保护您的数据免受外部人员的窥探 —— 无法防范服务商本身，也无法防范任何攻破了服务商的人。
对于真正敏感的文件来说，这个漏洞很致命。仅靠服务器端加密，无法让您免受以下威胁：
- Dropbox 服务器遭到黑客攻击，或者由于配置错误导致存储的数据泄露。
- 内部访问 —— 员工滥用权限，或者内部账号被盗用。
- 迫使服务商交出解密后内容的法律请求。
- 账号被盗，任何登录您账号的人，都能看到和您自己看到的一模一样的文件。
这些都不是什么罕见的奇谈。它们是云端数据泄露最常见的途径 —— 这也是为什么您的照片在云端其实并没有感觉起来那么安全的原因。
缺失的一环：在文件离开设备前进行加密
解决办法不是放弃 Dropbox。而是要确保，当文件抵达 Dropbox 时，它对除了您之外的任何人都已经是无法读取的了。
这就是**零知识（Zero-knowledge）或客户端（Client-side）**加密。您的文件在您自己的设备本地进行加密，使用的密钥只有您自己掌握。最终落入 Dropbox 的，是一堆被打乱的密文。如果 Dropbox 被黑客攻破、被传票索取，或者只是员工出于好奇心偷窥，他们什么实质内容也得不到 —— 因为解密密钥从未交到他们手上。
这就是“已加密”和“专为您个人加密”的区别。只有第二种，才能在服务提供商沦陷时幸存下来。
如何给 Dropbox 加上客户端加密
这里有两条可行的路径：
- 手动操作。 创建一个受密码保护的加密压缩包（Windows 上用 7-Zip，macOS 上用 Keka 或终端）并将其放进 Dropbox 文件夹。这有效，但很繁琐 —— 每次查看或编辑都意味着解压、修改、重新打包，然后安全地删除留下的未加密痕迹。
- 使用专用的加密保险库。 保险库应用在本地加密每个文件，并自动为您同步已经加密好的版本，所以日常使用起来感觉很自然。
我们在如何在上传到 Dropbox 之前加密文件中逐步详细介绍了这两种方法。
Vaultine 的角色
Vaultine 专为第二条路径——也是最无缝的路径——而生。您可以把它当成一个能自动运行的 Dropbox 保险库：一个本地的、加密的保险库，在文件被同步出去之前就将它们锁定。
- 本地加密优先。 在同步之前，文件已经在您的设备上被加密了。每个文件都会获得自己专属的 AES-256 密钥。
- 您的密钥，我们永远拿不到。 密钥由您自己的图案或 PIN 码派生，并且永远不会离开您的设备。我们没有账号系统，不需要电子邮箱 —— 我们的服务器上没有任何关于您的信息，自然也无从泄露或被传唤。
- 云端是可选的。 默认情况下，您的保险库留在您的设备上。如果您想要同步，您连接的是您自己的 Dropbox，并且 Vaultine 只会将密文上传到一个专属的应用文件夹里 —— 这个云端副本对任何拿到它的人来说都是毫无用处的。
- 多设备共享同一个保险库。 在另一台电脑上连接同一个 Dropbox 账号并使用相同的图案，您的加密保险库就会跟随着您。
总结
Dropbox 的加密够用吗？对于普通文件来说，是的。但对于那些您绝不希望被陌生人——或是一纸传票——看到的文件和照片来说，不：服务商掌握着密钥的服务器端加密留下了真正的隐患。答案不是弃用 Dropbox；而是在敏感文件同步之前对它们进行加密，这样云端保存的就是一堆密文，而密钥永远留在您自己手里。
用您自己的文件试一试 —— Vaultine 免费为您保护前 10 个文件。
