Hacker News Reader

Comment by chubs | Hacker News Reader

What if your address book was hashed (sha1, bcrypt) and then uploaded? In that case, all that would be uploaded is a list of hashes for the email addresses or phone numbers of people i know.

Then, when another person signs up for an account, it's easy to see who they should suggest they should join, but nowhere is any personal data being stored.

Sounds like it'd work to me?

View on HN

It would take laughably small time to bruteforce the phone number out of a hash. Knowing the algorithm I can compute all possible 10,000,000,000 combinations and store them in one file.

Same goes for hashing IPv4 addresses. There is no way to make eitther one secure by hashing.

Concatenate FirstName+LastName+emailAddress+phoneNumber, then hash or HMAC that.

Your lookup table just got a lot bigger.

And the likelihood that you'll match somebody got a lot smaller. Names have different spellings, phone numbers have different spellings (to say nothing of different numbers), people have multiple emails. You can't canonicalize some of these either.

So send multiple hashes per contact!

Feral, Chimp, myEmail, myDeskPhone, myCellPhone

H1 = sha1(Feral-Chimp-myEmail-myDeskPhone-myCellPhone)

H2 = sha1(F-Chimp-myEmail-myDeskPhone-myCellPhone)

H3 = sha1(Feral-C-myEmail-myDeskPhone-myCellPhone)

H4 = sha1(F-C-myEmail-VALUEOMITTED-VALUEOMITTED)

...

So flexibility is available, it's just more computationally expensive for the server to do the extra comparisons. The hash calcs use a little extra battery per user, but I'm much happier to donate some of my processor/battery than I am my Address Book contents.

Not all names are simple or even computable transforms though. How do you deal with entries like "Mom" or "Steve," names like "St. Clair" that may be entered dozens of different ways, or non-English names like "姚明" that may have dozens or hundreds of different possible romanizations, anglicizations, francizations, and spellings under any other language?

How much extra battery are you willing to spend, and more importantly, how much effort are you willing to spend running your users' batteries down for something that you'd never yourself use?

> How do you deal with entries like "Mom" or "Steve," names like "St. Clair" that may be entered dozens of different ways, or non-English names like "姚明" that may have dozens or hundreds of different possible romanizations, anglicizations, francizations, and spellings under any other language?

That's sort of beside the point, though. The question is: How does uploading my Address Book information provide a much more efficient or complete solution to that set of problems? I don't think that it does. In each case, you're dependent on heuristics and sometimes those heuristics are going to miss a match. If I were Twitter, I'd happily accept those misses in exchange for hitting the matches where people spell each other's first names and email addresses consistently (for example).

> how much effort are you willing to spend running your users' batteries down for something that you'd never yourself use?

You lost me there. My point was just that for Twitter, my iPhone CPU/battery are an "externality." So while they might spend more cycles doing server-side comparisons on the hashes my phone sends over, at least they're not paying to compute the hash values.

The engineer in me says you could soundex/metaphone the names before adding them to the hash. The rest of me says apps just shouldn't be doing this.

I'm probably out of my territory (I don't have a phone right now[1]), but my first UI instinct would be to allow address book entries to be grouped (or tagged or labelled, the actual mechanism is secondary), and on first request from the app being asked what groups I'd like to allow it access to. Bonus points for the option to create a per-app group and put some users in right there and then.

But as I said, outside of my territory.

[1] I'm not that old, really.

But all we care about is making it look secure for the hobbyist packet sniffers, right? (kidding)

Although what about hardcoding a salt into the app to hash with?

Salting wouldn't help. The data is collected to match it to other users' data, so the salt would have to be identical for all hashes for all users. An attacker would just precompute the dictionary with the hard coded salt, nullifying its purpose.

You're right in the case of SHA1. However, with a suitable work factor, you can't bruteforce bcrypt AFAIK

1) bcrypt uses salts so that won't work at all

2) if you use some other computationally expensive hash you run into the problem of low powered mobile hardware. Remember you're not hashing 1 thing, but dozens or hundreds of phone numbers or email addresses.

You know, i think you're right - if we use different salts for each emails/phones, there'd be no way of ensuring that different users use the same salts, or even if we stored the salt along with the hash, it wouldn't be much use. Hmm this is a tricky problem!

I'm pretty sure the parent meant "precompute" (e.g. a rainbow table), not "brute force".

Again: you're right in the case of SHA1, but rainbow tables don't apply to bcrypt because of the varying work factor, also you can use a different salt for each person.

Crypto is actually really cool these days, there's pretty much a solution to every weakness :)

So your solution to providing a "secure" way to compare phone numbers, etc, between users is to make the hashes non-comparable? Remember, the goal is to make it so two people can come up with the same hash in order to "find" each other.

What problem would this solve?

If my problem is that I don't want Facebook to have the phone numbers in my address book, then surely I don't want them to have the SHA1 of each of the numbers in my address book, either?

Isn't it going to be easy for an organisation with Facebook's resources to build a dictionary of the space of SHA1s of phone numbers?

And if they salt the numbers, first, then they can't be compared with each other for suggestions? So whats the point?

Have I overlooked something?

It avoids accidents. With plain text data, there is a lot of room for accidentally leaking private data (for example, to server logs). Building a sha1 dictionary isn't something you do by accident.

Facebook only knows the contacts that match i.e. are already on Facebook. And that's exactly what the user wanted to find out.

It's true that they could store the hashes and build a graph of mystery contacts, but that's still not as bad as taking the actual contact info.

If users aren't asked for access to their address book, this is still a potential public relations nightmare, since many people will inevitably be distressed that a company will be able to know who was in your address book even if they don't know those people's phone numbers.

Reply on news.ycombinator.com