Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The client could do 'signed' hashes using the local phone number and the friend number (sending the server both the local:friend pair and the friend:local pair).

That wouldn't really stop anybody from reversing the hashes, but it would make a global rainbow table useless.



It would make reversing the hashes substantially harder for any given hash function, though, right? Thanks very much for this idea. I'd thought about tracking social connections by sending hashes (on an explicit and opt-in basis) for my research app, Mappiness[1], but gave up the idea mainly because hashing seemed so hopelessly weak. But I think this + bcrypt might make it workable.

1. mappiness.org.uk


At that point it's also useless for matching.


It wouldn't be a strong signature, it would simply be the other half of the number pair. Numbers A and B both have easy access to A:B and B:A.

The hashes for a given user could still be attacked using their phone number, but a global table wouldn't work.


That's clever. You can then even improve the algorithm by only sending the hash of A:B for every phone number, where A < B (numerically). Then you don't have to worry about whether it's Friend:Local or Local:Friend.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: