英文:
Using SHA-256 hash for looking up row
问题
我是新手对于密码学。
在我的应用程序中，我们计划使用AES GCM来加密各种数据。
除此之外，假设我有一个要求，需要将一些信息保存在数据库中。当直接在数据库中查找时，这些信息不应该是可读的。它不是关键信息，比如说一个密码。
有一个需要，就是在给定相同的输入时，我应该能够在一个索引列中以不可读的格式查找存储这些数据的表的行。任何人都可以运行查询并将这个不可读的格式与另一个相同的值匹配，从而识别其原始输入并不是问题。
如果这不是问题的话，是否可以使用SHA-256哈希来实现这个目标？
如果不可以，您有更好的替代建议吗？
我已经尝试搜索了这个问题。
看起来这个趋势随着年份的变化而不断发展。
对我来说，这样做应该是可以的。
但总的来说，我看到很多帖子都不鼓励使用SHA。
话虽如此，我也看到有一篇帖子说，即使是比特币也使用SHA-256。
我已经注意到了非常有帮助的建议。对此我表示感谢。截止目前，我已经理解到：
- 根据数据的敏感性，可以使用SHA256 - 当不太担心数据本身的破解时（但那么为什么要哈希它呢？话虽如此，可能有一些情况可以使用它）
- 在使用SHA-256进行哈希时添加盐，如果我们想要避免基于明文输入的相同密码的查找。但这可能会受到暴力攻击的威胁，因为SHA-256的速度很快。所以如果是密码之类的敏感数据，也不要使用这种方法
- 使用类似于Argon2、bcrypt、scrypt之类的东西，它们具有内置的（至少bcrypt通过将盐添加到哈希中来实现）盐化。并且可以配置为执行较慢，并使用更多的CPU、内存，从而使其更安全。
- 可能是最安全的，我需要进一步探讨的是由Topaco建议的—即盲目索引。
英文:
I am new to cryptography.
In my application we are planning on securing various data using AES GCM to encrypt the data.
Additional to that, let’s say I have a requirement to save some information in a database. This information must not be readable when looked up directly in the database. It’s not critical information like, say, a password.
There is a need that given the same input I should be able to look up the row of the table where this data is stored in the unreadable format in an indexed column. It’s not an issue that anyone can run a query and match this unreadable format with another same value and identify its original input.
If that is not an issue, is it OK to use SHA-256 hashing for this?
If not, what's your suggestion for a better alternative?
I have tried searching for this.
It appears the trend keeps evolving across the years.
To me it looks like it should be OK to do this.
But in general I do see many posts discouraging use of SHA.
That said, I also saw a post which said even bitcoin uses SHA-256.
I have noted the very helpful inputs. My thanks for the same. As of now, I have understood this much:
- Depending on the sensitivity of the data one can use SHA256 - when not worried about cracking of the data itself too much (but then why even hash it? That said, there may be cases where we can use it)
- Add salt when hashing using SHA-256 if we want to avoid a lookup based on the same password in plain text input. But this can be vulnerable to brute-force attack because of the speed of SHA-256. So don't use this approach also if it’s a password kind of sensitive data
- Use something like Argon2, bcrypt, scrypt which have inbuilt (at least bcrypt has by adding salt into the hash itself) salting. And it can be configured to perform slowly and use more CPU, memory, thereby
making it safer. - Possibly safest which I need to explore further is what was suggested by Topaco—namely a blind index.
答案1
得分: 1
如果您的意图是从任意输入中一致派生出一个唯一密钥，但不泄漏关于该输入的信息，那么SHA-256是一个优秀的选择。这是安全哈希的关键特性之一，除非您有专门的需求，否则您的默认安全哈希选择应该是SHA-256。
根据您要哈希的内容，您可能希望向您的哈希添加一个盐。如果输入位于一个小领域（输入空间）上，您可能还需要拉伸您的哈希。从您的问题中并不完全清楚您打算要哈希什么。
英文:
If your intent is to have a unique key that can be consistently derived from an arbitrary input, but does not leak information about that input, then SHA-256 is an excellent choice. This is one of the key features of a secure hash, and unless you have specialized needs, you default choice of a secure hash should be SHA-256.
Depending on what you're hashing, you may want to add a salt to your hash. You may also need to stretch your hash if the input is over a small domain (input space). It's not completely clear from your question what you're planning on hashing.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论