文件级加密在多种情况下很有用，这里有几个例子：

• 通过不安全的渠道发送数据。您提到了 TLS，当您拥有它时就足够了。但是，如果您不确定每个节点实际上都使用 TLS 怎么办？你真的信任每个节点吗？例如，想想电子邮件。
• 将数据存储在不受信任的地方。您可能信任加密的外置硬盘，但 Google Drive 呢？您的托管服务提供商呢？如果您想确保没有其他人能够访问您的文件（谷歌、您的托管服务提供商的员工、设法破坏这些服务的网络罪犯等），您将需要加密您的文件。
• 深度防御。全盘加密将在您的机器关闭时保护您的数据，但如果攻击者在您的笔记本电脑打开时抓住了它怎么办？如果您的机器被感染并且在您注意到所有敏感文件都发送给攻击者之前怎么办？使用文件级加密，攻击者将无法立即访问您的敏感文件的内容，因此此类攻击可能会失败。

当您的机器通电时，全盘加密无法针对远程访问的攻击者提供任何保护（根据定义， FDE要求在每次访问时解密数据）。因此，要完全使用机器，您必须解锁所有数据。

相比之下，加密文件仅在明确的用户请求提供密码时才被解密。这意味着即使机器受到威胁，这些文件在用户提供有效密码之前都是安全的，这为检测攻击者和保护自己提供了额外的时间。这也提供了更高的粒度（因为每个人的密码可能不同，或者取决于数据的敏感性，或与之共享的用户组），通过最小权限原则提供额外的安全性

例如，我每天使用的烹饪食谱可以用一个密码保护，我每月支付一次的支票银行账户可以用另一个密码保护，我每 10 年更改一次的遗嘱可以用第三个密码保护。所以攻击者必须在 10 年内不被发现，他希望看到我的意愿。使用 FDE，他可以立即访问它以及其他所有内容。

此外，单独加密的文件与共享文件服务器兼容，共享文件服务器由具有不同权限的用户访问（因此只知道文件加密的共享密码子集）。

TLS 本身有很多问题，例如MiTM 攻击或 CA 妥协（你真的信任 Web 浏览器中的所有 CA吗？我当然不是为了任何严重的事情 - 你可以删除所有这些并只使用你自己的 CA，这将是安全的，但没有人这样做，因为它会阻止您访问您的银行等）。

另一方面，加密文件仅取决于您和其他需要访问该信息的人共享的密码的保密性 - 您可以完全控制它。

当您传输加密文件时，它们也受到端到端保护，因此它们不在乎您和接收者之间的路径是否受到损害。您将加密文件附加到您的电子邮件中，并且您知道除非他们知道密码，否则没有人可以阅读它。如果您改为依靠 ISP 在 SMTP 中正确实施 TLS，那么您将陷入痛苦的世界（SMTP STARTTLS 剥离 MiTM，默认 SMTP 回退为纯文本，文件以纯文本形式存储在收件人 IMAP 服务器上，并且取决于 ISP 的安全性和心怀不满的员工等的善意）

另外，想想纵深防御。您可以（并且应该，如果您足够关心的话）使用加密文件以及TLS和FDE 来实现最佳安全性。

我能看到的唯一一点是一个低技能的攻击者，它可以访问带有加密文件的机器。本质上，如果朋友/家人可以访问并且没有意外看到某些东西。我错过了一个场景吗？

您假设攻击者可以访问您的计算机的唯一方法是亲自到场是完全错误的。虽然我不会谈论所述攻击者的技能，但他仍然有很多方法可以在您的计算机中运行恶意代码，一旦他可以做到他还可以将数据泄露到他的 C2。

我想知道他们实际上可以帮助什么场景，或者它是否只是一个糟糕的解决方案。

加密数据有助于数据存储的场景，并且是一种纵深防御概念。看看去年有多少公司被入侵并被盗，想想所有以明文形式存储的密码/信用卡号。在我的敏感数据的意见文件加密是必须的，应该是每个人的威胁模型。

你提到了大部分，中间人，家人/朋友访问文件，设备丢失。

大多数人忽略的另一件事是在企业方面，合规性是另一个需要考虑的因素。数据保护政策等

将您的加密文件托管在另一个人或组织的基础架构中怎么样？云服务现在是一件大事，AWS 确实采取了措施来加密和安全保存您的数据，但最好您也添加自己的“层”！