Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Difficulty Of Private Contact Discovery

whispersystems.org

Post reply on HN
Print view View original

51–60 of 76 posts

Re: The Difficulty Of Private Contact Discovery

#51

Post by tinco »

MagicWishMonkey wrote: post #21
herge wrote: post #5

Earlier quoted context omitted.

RTFA. He addresses that in the first few paragraphs. Because there are 10^10 possible phone numbers (approximately), it is very easy to build a rainbow table of all hashed phone numbers and back-track a hash to it's phone number.

Phone numbers are not unique values, you should never assume that a phone number alone (or even a phone number and last name) is enough information to uniquely identify an individual. Case in point: I work with a guy who used to work at his dads office. He and his dad both have the same name, and they both had the same office number. This algorithm would incorrectly identify both people as being the same person when…

You should never assume that any piece of information is not enough to uniquely identify an individual.

You are thinking from the point of view of a database administrator, whose job it is to make it easy to uniquely identify an entity.

In security it's about making it as hard as possible to deduce even the slightest of information about a person, increasing the k-anonymity as they say.

For all intents and purposes, that a phone number resolves to only two people, and they're also conveniently located geographically near to each other, and are probably very distinct in a whole range of other things, makes it the perfect key for any security adversary.

Re: The Difficulty Of Private Contact Discovery

#52

Post by sln »

robrenaud wrote: post #39

Is this a real problem? Is it reasonable to trust for me to trust you to you run some arbitrary binary on my phone that does some magical black box computation on my contact list and then phone home to your service, but not trust to that you will just not be a dick with the raw data? Stated more simply, if I am paranoid about my privacy, then why am I running your apps and letting you read my contact list at all?

Yes this is a real problem. Being "paranoid about privacy" is not a yes/no decision for people to make. Different people have different things they would like to be private about and to different degrees. Some people may not want it to be possible for anyone to ever know anything at all about them. Those people don't use phones of any nature. Maybe some other people only trust phones that they build themselves. Other people are willing to trust open source software and the communities around it. Some people only care about making dragnet surveillance difficult or expensive. Others need perfect assurance of privacy because their lives are in danger. Others don't care if anyone listens to their calls.

But what you are saying is like looking at football players, seeing that they could still get hurt when they wear lots of padding, and deciding either no one should play the game or we should all play inside giant airbags.

Re: The Difficulty Of Private Contact Discovery

#53

Post by goatslacker »

Spearchucker wrote: post #47
goatslacker wrote: post #44

Earlier quoted context omitted.

To the end user probably not but if the encryption is performed on the client and the client code is open sourced and you don't auto-update your application then you'll know exactly what is happening to your data when you let it access your contacts.

Not realistic. If it's open-sourced I can go examine the code for sure, but it's not a good use of my time (and I can actually read code, but even if someone had the time but can't read code?). I also have no way of knowing if anyone else has looked at the code at all, and if they have, whether they're skilled enough to determine that the code is kosher. Again, if I struggle with that, how on earth is a non-technical…

You're right it isn't realistic, but it's the only way to fully know that the application is secure. Otherwise you're putting your trust in something/someone.

Re: The Difficulty Of Private Contact Discovery

#54

Post by stormbrew »

robrenaud wrote: post #39

Is this a real problem? Is it reasonable to trust for me to trust you to you run some arbitrary binary on my phone that does some magical black box computation on my contact list and then phone home to your service, but not trust to that you will just not be a dick with the raw data? Stated more simply, if I am paranoid about my privacy, then why am I running your apps and letting you read my contact list at all?

Agreed. The whole thing seems to really miss the problem Snapchat exposed, turning an access control problem into a cryptographic problem. At least I assume this is being posted now because of snapchat.

The problem with how snapchat failed isn't so much that they weren't storing the information securely but that they had absolutely no gate on getting the information aside from a global api key. If you're running their app you've already exposed the phone numbers and are trusting them not to be too evil with them.

My expectation as a user of their service (I'm not, but if I were, and this applies to things like facebook as well, of which I am a user) is that they won't tell people I don't want to know who I am and if I'm using their service.

To this end what's needed is that before it gives another user a positive result (especially tied to my name) to my phone number it should have a reasonable expectation that I want them to have it. If they store the information that lets them derive this expectation in a way that keeps my info secure, that is also fantastic, but it's a second tier concern to becoming literally the whitepages by accident.

Re: The Difficulty Of Private Contact Discovery

#55

Post by stormbrew »

mtrimpe wrote: post #15
spullara wrote: post #10

Earlier quoted context omitted.

Well, actually I did read the article and address that in my comment that I don't think that it is important to hide the address from the server but it is important to hide them from the brute force attacker. I believe that my suggestion stops a brute force attacker from pulling the whole database like you can today with many of these systems.

Properly implemented rate limiting would be a better way to achieve that though. That is were the 'blinding signature' part comes in: to give the server the possibility to intelligently rate limit.

Rate limiting is a terrible solution to this sort of problem IMO. It just forces the attacker to be patient, but they will eventually get what they want, which is name/phone number pairs of the entire numeric space of phone numbers. His solution is problematic because it distributes the burdain to the user, and anyone who's gotten massive numbers of friend requests on a chat service can attest to how unfriendly that is, but it's on the right track. It should not be possible for an attacker to get contact information for arbitrary phone numbers through an api. Something should gate that, probably through the mutuality of having each other on each other's contact list.

Re: The Difficulty Of Private Contact Discovery

#56

Post by MagicWishMonkey »

tinco wrote: post #51
MagicWishMonkey wrote: post #21

Earlier quoted context omitted.

Phone numbers are not unique values, you should never assume that a phone number alone (or even a phone number and last name) is enough information to uniquely identify an individual. Case in point: I work with a guy who used to work at his dads office. He and his dad both have the same name, and they both had the same office number. This algorithm would incorrectly identify both people as being the same person when…

You should never assume that any piece of information is not enough to uniquely identify an individual. You are thinking from the point of view of a database administrator, whose job it is to make it easy to uniquely identify an entity. In security it's about making it as hard as possible to deduce even the slightest of information about a person, increasing the k-anonymity as they say. For all intents and purposes,…

You make a good point, my job is to make it simple for machines to differentiate between two people, a task a human could do easily.

Re: The Difficulty Of Private Contact Discovery

#57

Post by ww520 »

MagicWishMonkey wrote: post #19

This is great until you realize the average address book is a disgusting mess of spelling errors, wrong values in wrong fields, punctuation in places where punctuation isn't necessary (commas in phone number fields, digits in name fields, etc.) The only field that might be fairly consistent is email address and even that is no guarantee. Sure, it's possible to clean up a contact before hashing, but when you consider…

There similarity hash algorithms that takes a fuzzy approach to hashing slightly different values to the same hash value.

Re: The Difficulty Of Private Contact Discovery

#58

Post by streetnigga »

moxie wrote: post #28
sigil wrote: post #4

Interesting problem! > It’s also possible to compress “updates” to the bloom filter. The server just needs to calculate the XOR of the version the client has and the updated version, then run that through LZMA (the input will be mostly zeros), and transmit the compressed diff to the client. > Unfortunately, for a reasonably large user base, this strategy doesn’t work because the bloom filters themselves are too large…

Our feeling is that 40MB for an initial download is not acceptable on mobile devices, particularly in many of the areas we'd like to support. Maybe we're wrong, but it seems like too much on edge networks, particularly given that it's only going to grow as more users join. Ideally we'd have 100MM or 500MM, not just 10MM. We can definitely make lightweight diffs happen, but that initial download is tough, and is going…

My original device was what you may call an edge case. Underpowered, lack of space, pretty crappy carrier plan.

Thanks for thinking of us. :)

Re: The Difficulty Of Private Contact Discovery

#59

Post by streetnigga »

sigil wrote: post #33
moxie wrote: post #28

Earlier quoted context omitted.

Our feeling is that 40MB for an initial download is not acceptable on mobile devices, particularly in many of the areas we'd like to support. Maybe we're wrong, but it seems like too much on edge networks, particularly given that it's only going to grow as more users join. Ideally we'd have 100MM or 500MM, not just 10MM. We can definitely make lightweight diffs happen, but that initial download is tough, and is going…

So make contact discovery optional. My guess is most of your growth will come from that core of early adopters in the graph, and these folks have nice data plans / fast wifi and won't mind the 40MB download at all. In the long term, where you're 10x or 50x where you are today, yes the filter size is a problem, but it's a "nice problem to have" as they say. Side question: suppose I'm a less fortunate user of TextSecur…

"My guess is most of your growth will come from that core of early adopters in the graph, and these folks have nice data plans / fast wifi and won't mind the 40MB download at all."

See my comment in this thread about low resource mobiles, or the article on BZR being overtaken by Github and complaints about resource use from low memory laptop users. Please don't assume technological knowledge or early adoption means plentiful resources from the user.

Re: The Difficulty Of Private Contact Discovery

#60

Post by pbsd »

A new private-set intersection paper, claiming to scale orders of magnitude better than predecessors, has just been released [1]. I don't know whether it solves your problem, as I haven't read anything beyond the abstract, but you might want to check it out anyway.

[1] https://research.microsoft.com/en-us/um/people/senyk/pubs/sa...

Post reply on HN