Encryption 如果加密数据总是在本地保存和检索，是否仍然需要HMAC

我对HMAC的理解是，它可以帮助在处理数据之前验证加密数据的完整性，即，它可以用来确定发送到解密例程的数据是否以任何方式被修改

在这种情况下，如果数据从未在生成它的应用程序之外传输，那么将它合并到加密方案中有什么好处吗？我的用例非常简单——用户将数据（以明文形式）提交到我编写的用于存储客户详细信息的脚本中。然后，我的脚本对这些数据进行加密并将其保存到数据库中，然后我的脚本为用户提供了一种方法来检索数据并根据它们提供的记录ID对其进行解密。我的用户无法将加密数据直接发送到解密例程，我也不需要提供外部API

因此，假设应用程序中默认存在信任链是否合理，因为同一应用程序负责写入和检索数据？如果我将HMAC添加到这个方案中，在这个上下文中是多余的，还是不管上下文如何都始终实现HMAC的最佳实践？我打算使用Defuse库，但我想了解HMAC对我的项目有什么好处

---

提前感谢您的建议或意见：）

我的OCD通常规定，如果没有其他原因，从日志中删除警告，实施HMAC始终是一种良好的做法

---

在您的情况下，除了确保纯文本提交的完整性之外，我认为实现HMAC没有明确的优势。您的脚本可能会加密数据，但在不太可能向其传递坏数据的情况下，它不会有用

我的OCD通常规定，如果没有其他原因，从日志中删除警告，实现HMAC始终是一种良好的做法

---

在您的情况下，除了确保纯文本提交的完整性之外，我认为实现HMAC没有明确的优势。您的脚本可能会加密数据，但在不太可能向其传递坏数据的情况下，它不会有用

首先，您应该了解，存在允许攻击者修改加密数据而不解密数据的攻击。请参阅on Security.SE和on Crypto.SE。如果攻击者获得对加密数据的写访问权——即使没有任何解密密钥——可能会造成严重破坏

你说加密数据“从未在生成它的应用程序之外传输”，但在接下来的两句话中，你说你“将它保存到数据库”，这（对我来说）似乎有点矛盾。信任对内存中加密数据的处理是一回事，但信任对磁盘的序列化，尤其是由另一个程序（如数据库系统）和/或在单独的物理机器上（现在或将来，随着系统的发展）进行的序列化

---

这里的一个重要问题是：攻击者是否有可能在不访问应用程序和密钥的情况下修改加密数据或将加密数据替换为其他加密数据？如果攻击者是内部人员并以普通用户的身份运行程序，则通常不可能保护您的数据：程序允许攻击者执行的任何操作都在桌面上。但是，当非用户（或超出其正常权限的用户）可以对数据进行写访问时，HMAC是相关的。如果数据库遭到破坏，攻击者可能会修改数据而不受惩罚，即使无法访问应用程序本身。使用HMAC验证严重限制了攻击者有效修改数据的能力，即使他们获得了写访问权。

首先，您应该了解，存在允许攻击者修改加密数据而不解密数据的攻击。请参阅on Security.SE和on Crypto.SE。如果攻击者获得对加密数据的写访问权——即使没有任何解密密钥——可能会造成严重破坏

你说加密数据“从未在生成它的应用程序之外传输”，但在接下来的两句话中，你说你“将它保存到数据库”，这（对我来说）似乎有点矛盾。信任对内存中加密数据的处理是一回事，但信任对磁盘的序列化，尤其是由另一个程序（如数据库系统）和/或在单独的物理机器上（现在或将来，随着系统的发展）进行的序列化

---

这里的一个重要问题是：攻击者是否有可能在不访问应用程序和密钥的情况下修改加密数据或将加密数据替换为其他加密数据？如果攻击者是内部人员并以普通用户的身份运行程序，则通常不可能保护您的数据：程序允许攻击者执行的任何操作都在桌面上。但是，当非用户（或超出其正常权限的用户）可以对数据进行写访问时，HMAC是相关的。如果数据库遭到破坏，攻击者可能会修改数据而不受惩罚，即使无法访问应用程序本身。使用HMAC验证严重限制了攻击者有效修改数据的能力，即使他们获得了写访问权。

谢谢。正如apsillers所提到的，我自动假设我的PHP脚本和数据库之间存在一个信任链（理论上）可以被利用。不过，所有的加密/解密都是在应用程序中完成的——对我来说，这意味着，如果有人发现了利用PHP和数据库服务器之间链接的方法，那么验证加密数据的完整性将非常有用。谢谢。正如apsillers所提到的，我自动假设我的PHP脚本和数据库之间存在一个信任链（理论上）可以被利用。所有的加密/解密都是在t内完成的