NDB Datastore 的快速加密、慢速解密方法答案

【问题标题】：Fast encrypt, slow decrypt method for NDB DatastoreNDB Datastore 的快速加密、慢速解密方法
【发布时间】：2013-10-19 11:22:30
【问题描述】：

我有未加密的网络请求数据（不在我的管辖范围内），我想将其快速保存到数据存储区中，以免减慢请求过程。

系统用户有时需要通过网络打开敏感数据。当用户提出此类请求时，它将要求他们在解密过程开始之前完成 reCAPTCHA，并记录有关其行为的事件。对于 10 到 20 个字符的字符串，解密时间最长可达 1 分钟。

在这种情况下，是否有一种加密算法可以在 GAE 上使用，它的解密速度比加密慢？

我正在考虑另一种方法来减少加密时间：

临时存储使用 ~~MD5 和哈希~~ 快速加密方法轻度加密的数据，而计划的作业会迭代任何未标记为正确加密的记录，并经济地应用非常强的加密（对于如果用户在输入后立即尝试访问数据，则会提醒用户加密尚未完成）

假设上述方法是可行的，那么我假设我可以在几分钟内从数据中加密裤子，如果数据被泄露但系统没有被泄露，则尝试解密的成本非常高。

【问题讨论】：

数据加密后是否需要解密？如果是这样，MD5 不会对你有好处，因为它是一种单向散列算法。我很好奇你为什么会有这么长时间解密数据的要求。这是安全问题吗？
谢谢@IvayloSlavov，好点子。数据确实需要能够解密，所以我将擦洗上述方法的MD5部分。
听起来您将解密时间（对于拥有密钥的人）与破解时间（对于没有密钥的人）混为一谈。您能否更清楚地解释使用正确密钥解密需要 20-60 秒才能满足您的安全需求？
@svk，解密不需要花费任何时间，但是如果解决方案需要这么长的解密时间，则不会有问题。我认为更强大的加密需要更多时间来解密，但如果有任何快速（CPU时间）加密方法可能适合用例，需要比其他方法更长的时间来解密，我不熟悉。如果可能的话，我还想通过花时间解密来降低 GAE 成本。
更强的加密不一定需要更多的时间来解密。这仅适用于您尝试在没有所有必要数据（如加密密钥）的情况下破解它。用 1s 来解密一个短字符串听起来很疯狂。另外，不要加密短字符串，更容易攻击它们。总是将它们填充到最小长度我们一些随机数据（所以它也不总是相同的长度）

【解决方案1】：

听起来传统的加密方法应该可以满足您的需求，例如AES256。当谈到加密时，你应该尝试尽可能少地进行创新。使用行之有效且值得信赖的方法——当“自己动手”时，很容易犯错误，而且您无法从学术密码学社区的同行评审中获益。

在着手解决加密阻塞请求的问题之前，请务必对使用您选择的强算法进行加密实际需要多长时间进行基准测试。几百毫秒的延迟真的有问题吗？

如果事实证明加密速度太慢，您仍然不应该在加密算法的质量上妥协。更好的解决方案是在后台线程中执行加密并立即继续请求。

在您的数据库中为要以加密形式插入的资源分配一个 ID，但不要在“真正”加密之前使用中间的、有意的“温和”加密形式。这一层只会提供一种虚假的安全感。

如果用户尝试访问尚未加密的资源，则返回一个错误，指示该资源仍在处理中（或加密失败，如果适用）。

确保加密过程不会失败或延迟，导致未加密数据的保留时间超过应有的时间。如果加密不能及时成功（因为磁盘满/电源故障/宇宙射线），必须简单地允许插入失败，并且不能保留未加密的数据。

【讨论】：

感谢 svk，非常有教育意义，我将测试 AES 或类似的实现。如果时间看起来很慢，后台线程应该不是问题（一些关于 GAE/Python 加密时间的 SO 帖子提出了最初的担忧）。
您将无法在前端请求处理程序的后台线程中处理加密。加密是 CPU 密集型的，它只会阻塞处理程序。您可能希望将数据发送到常驻后端并让它处理加密。