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

1 points by romanr 3 years ago | 1 comment

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.

1Password does not provide functionality to sweep and remove all duplicates. The reason for that, it's not possible to compare encrypted entries, since it's using one-way encryption function. Meaning even two identical entries will have different signatures.

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.

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 "seed", so we can compare entries encrypted with that seed. The algorithm/hash should satisfy requirement of not being reversible, and not open possibility to brute force cracking.

On a related note, almost every password manager including ones built into browsers and 1Password itself, all have "your password is too weak" recommendations. Does it mean they have that flag set at the time they encrypt the password?

supriyo-biswas 3 years ago |

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.

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].

[1] https://www.troyhunt.com/understanding-have-i-been-pwneds-us...