TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Method for knowing if one-way-encrypted data is identical to another?

1 点作者 romanr大约 2 年前
Since 2018 when users of 1Password 7 upgrade to 1Password 8 all their entries got duplicated because of some bug. The identical entries have same creation and modification dates.<p>1Password does not provide functionality to sweep and remove all duplicates. The reason for that, it&#x27;s not possible to compare encrypted entries, since it&#x27;s using one-way encryption function. Meaning even two identical entries will have different signatures.<p>While there may be methods of working around with that, it is apparently engineering complexity barrier that they will not tackle. And they will not implement solution that will give 1Password too much access to the data either (to decrypt all with your key and tell which are duplicates). 1Password only sees encrypted data. The solution for comparing the duplicates has to be cryptographical.<p>My question to cryptography experts, when adding password entry to password database, can we generate some kind of hash to use later for comparing entries for being identical? Maybe hash unique within some special &quot;seed&quot;, so we can compare entries encrypted with that seed. The algorithm&#x2F;hash should satisfy requirement of not being reversible, and not open possibility to brute force cracking.<p>On a related note, almost every password manager including ones built into browsers and 1Password itself, all have &quot;your password is too weak&quot; recommendations. Does it mean they have that flag set at the time they encrypt the password?

1 comment

supriyo-biswas大约 2 年前
There’s no reason this functionality couldn’t be built into the client. Adding an unencrypted hash provides a side-channel into the encrypted passwords and should be avoided. Since passwords are not chosen at random and even when using a password manager, the generated passwords usually optimize for memorization, so the input domain for the hash function is substantially smaller, and therefore, can be brute forced to reveal the password.<p>As for the second question, it is usually implemented using hashing the password but revealing only a small prefix of the hash to a remote server. The remote server then sends a list of known-to-be-compromised password hashes that start with said prefix, which the client can use to find out if a password is compromised without revealing the password or its complete hash to the server[1].<p>[1] <a href="https:&#x2F;&#x2F;www.troyhunt.com&#x2F;understanding-have-i-been-pwneds-use-of-sha-1-and-k-anonymity&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.troyhunt.com&#x2F;understanding-have-i-been-pwneds-us...</a>