New answers tagged

1

This method should have following properties: Probability of false positives can be made as small as desired Server learns only the (approximate) number of items on each person's phone book, but not numbers themselves and cannot brute-force them Client-side brute-force attacks are impossible, as server can enforce policies against them Phones do not learn ...


3

With Isemis mention of "probability of false positives" I thought about Zero-knowledge proof. This answer makes no claims to be secure as it was never reviewed, so others should review and comment it. I am no professional security expert either and I didn't have the time to make sure the low number of possible phone numbers might be a problem. User A and ...


0

Why hash them? Why not encrypt instead, and send them to your own server. That way neither client device has to have access to each other's contacts, and the server does most of the work. This does introduce a single point of failure though, the server. If it was compromised, the attackers could potentially access all numbers. This could be controlled if ...


6

How can we do this in a cryptographically secure way and respecting the users' privacy (i.e. without sharing the numbers in plain-text between them or with a server)? tldr: You can't. Hashing is great for certain uses, but this is probably not one of them. The reason is that an attacker would know that there are only 10 billion possibilities (for ...


5

Let's do some tests! I started with a naive bash implementation, and calculated 10k numbers in 33 seconds: #!/bin/bash phone="2125551212" salt="abcdefghijklmnopqrstuvwxyz" shasalt() { echo "$* $phone $salt" | sha512sum; } for f in {1..10000} do shasalt $(shasalt $(shasalt)) >/dev/null # or write to a file... ((phone++)) done echo ...


17

There are potentially other privacy issues you're not considering yet. By design your app makes it easy to see who is connected to a certain target. So an attacker creates one contact on their phone (the activist/informant/terrorist/victim they are interested in) and then connects to many other users through your app, to create a list of the target's ...


11

Yes, it is (a bit) flawed. The problem is that the space is too small, so even with the multiple rounds and salts, it's relatively easy to bruteforce. Open Whisper Systems had a witty system where they provided an encrypted bloom filter that can be queried locally using blind signatures. They explain the process (as well as providing a good discussion of ...


24

bcrypt would be a somewhat better approach because it is designed to be (programmably) slow. Using a large enough salt and a reasonable complexityFactor, bcrypt(salt + number, complexityFactor) should yield a viable hash and you avoid "rolling your own cryptography", which could possibly turn out to be a difficult sell. To increase security you just crank ...


0

As I mentioned in the comment, you can't trust javascript served by the server. The idea of keeping the client side downloaded on their computers is interesting, although that doesn't really solve the issue. The server can still include javascript as part of a response unless you are insanely careful. In this case I really wouldn't go with javascript. ...



Top 50 recent answers are included