Timeline for Software implementation of a commutative cipher?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 3, 2012 at 17:12 | comment | added | David Cary | @IlmariKaronen: Yes, good point. | |
| May 1, 2012 at 14:12 | comment | added | Ilmari Karonen | You could try to use truncated hashes, but unless the number of SSNs that need to be compared is quite small, it'll be hard (or impossible) to choose a hash length that is short enough not to be identifiable (especially if an attacker can narrow down the search space to a given geographical region) yet long enough not to yield too many false matches. | |
| May 1, 2012 at 14:04 | comment | added | Ilmari Karonen | I'll quote poncho's comment to a now deleted answer that suggested more or less the same: "The problem is using a hash that there are only $10^9 \approx 2^{30}$ possible SSNs -- what one side could do is just hash all possible SSNs, and then look up all the hashed SSNs that the other side gave." Using a different salt for each hash would help some, but not much; it slows the brute force breaking (and legitimate checking) of $n$ hashes by roughly a factor of $n$. | |
| May 1, 2012 at 5:59 | history | answered | David Cary | CC BY-SA 3.0 |