Two ideas for the "sending friends to friends"-problem

jf99 commented 9 years ago

One big issue with Tox still is the way of handling ToxIDs. There has been a lot of discussion about it. It has been stated, that copying the complete ToxID of a friend (including the nospam value) won't be implemented. However, we really need an easy way to connect to friends without using centralized infrastructure, such as ToxDNS. Here are two ideas:

A nospam value as protection is a nice idea, but give the user the possibility to (temporarily) disable it. This would make it possible for others to send friend requests without knowing the correct nospam value. You could simply take the public-key from the friends list of another friend. Tox should however automatically re-enable the spam-protection when too many friend requests arrived in a specific amount of time.
Another way of preventing spam is the following: Alice and Bob are friends. Carol wants to add Alice, but doesn't know her ToxID. Since Carol and Bob are friends too, she can ask Bob for Alice's public key. Bob sends Alices public-key to Carol and signs with his secret-key, that he gave Alice's key to Carol. Now Carol can send a friend request to Alice composed of Alice's public-key and the signature created by Bob. Alice's Tox client will show her the friend request, because it is signed by Bob, who is in Alice's friend list.

zetok commented 9 years ago

Something like 2nd idea will be implemented at some point.

aaannndddyyy commented 9 years ago

I like the second idea more than the first. It is similar to the one I had for this problem: Alice asks Bob for Charlie's pubkey, Bob gives Alice Charlie's pubkey and Bob gives Charlie Alice's pubkey Charlie decides whether or not to add Alice. If both have added each other, they need no nospam.

Drawback, Alice would have to wait until Bob and Charlie are online at the same time too. In your approach that is not needed.

linux-modder commented 9 years ago

I also like the 2nd idea seems to be essentially pgp mail qhich I'm sure at least 98% of tox users are familiar with using...

On 5/23/15, aaannndddyyy notifications@github.com wrote:

I like the second idea more than the first. It is similar to the one I had for this problem: Alice asks Bob for Charlie's pubkey, Bob gives Alice Charlie's pubkey and Bob gives Charlie Alice's pubkey Charlie decides whether or not to add Alice. If both have added each other, they need no nospam.

Drawback, Alice would have to wait until Bob and Charlie are online at the same time too. In your approach that is not needed.

Reply to this email directly or view it on GitHub: https://github.com/irungentoo/toxcore/issues/1350#issuecomment-104960531

Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor (p) 310.909.7672 G+: https://www.plus.google.com/+CoreySheldon LinkedIn: https://www.linkedin.com/profile/view?id=70127804 Github: https://www.github.com/linux-modder Facebook: https://www.facebook.com/corey.sheldon Several Communities on Stack Exchange https://www.stackexchange.com

http://www.facebook.com/1stclassmobileshine

Tutoring in person or via any of the following platforms: HackHands https://www.hackhands.com Wizpert https://www.wizperts.com FieldNation https://www.fieldnation.com AirPair https://www.airpair.com Truelancer http://www.truelancer.com

{PayPal,Google Wallet/Play store, Apple Pay}

pub 3072D/718BF597 http://pgp.mit.edu/pks/lookup?op=get&search=0xE958C5D6718BF597 2014-12-08 Key fingerprint = 2930 99EB 083D D332 0752 88C4 E958 C5D6 718B F597

uid Corey Sheldon (Fedora Key) sheldon.corey@gmail.com

ProMcTagonist commented 9 years ago

I like the second idea there a lot. You'd be able to see who gave out your ID.

jf99 commented 9 years ago

Thinking further, the 2nd idea should be extended. Given the example above, Bob would now be able to mitm the communication between Alice and Carol, right? He could have given a wrong key to his "friend" Carol. Carol needs a way to verify that she got the correct key.

The least Tox should do, is to display the public keys of each friend so that you can compare them when you meet your friends in real-life. Other messengers (Threema afair) can even show this information as QR-code.

Another possibility would be a web-of-trust. Like Carol asks her friend Dave, who is also a friend of Alice, whether he has the same pubkey of Alice. Consider giving Dave the choice of ignoring Carol's WOT-request, since Carol could find out who of her friends is also Dave's friend.

zetok commented 9 years ago

Something like 2nd idea will be implemented at some point. ≠ Exactly that idea ≠ Almost that idea, but with few changes

Eh.

Unless something in that regard has changed, actual implementation won't have all that unnecessary "bullshit" (my wording), and it's main goal is to allow to introduce contacts to each other. That itself is not going to be secure. Trying to go in a technical way about something that by definition is not secure is not going to work, and as such is a waste of time.

If you want security, meet with person IRL and exchange Tox IDs. Anything other is not going to work.

linux-modder commented 9 years ago

@zetok, why would it not be secure (especially using the 2nd idea or something based off it)?

Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor (p) 310.909.7672 G+: https://www.plus.google.com/+CoreySheldon LinkedIn: https://www.linkedin.com/profile/view?id=70127804 Github: https://www.github.com/linux-modder Facebook: https://www.facebook.com/corey.sheldon Several Communities on Stack Exchange https://www.stackexchange.com

http://www.facebook.com/1stclassmobileshine

Tutoring in person or via any of the following platforms: HackHands https://www.hackhands.com Wizpert https://www.wizperts.com FieldNation https://www.fieldnation.com AirPair https://www.airpair.com Truelancer http://www.truelancer.com

{PayPal,Google Wallet/Play store, Apple Pay}

pub 3072D/718BF597 http://pgp.mit.edu/pks/lookup?op=get&search=0xE958C5D6718BF597 2014-12-08 Key fingerprint = 2930 99EB 083D D332 0752 88C4 E958 C5D6 718B F597

uid Corey Sheldon (Fedora Key) sheldon.corey@gmail.com

On Thu, May 28, 2015 at 3:02 PM, zetok notifications@github.com wrote:

Something like 2nd idea will be implemented at some point. ≠ Exactly that idea ≠ Almost that idea, but with few changes

Eh.

Unless something in that regard has changed, actual implementation won't have all that unnecessary "bullshit" (my wording), and it's main goal is to allow to introduce contacts to each other. That itself is not going to be secure. Trying to go in a technical way about something that by definition is not secure is not going to work, and as such is a waste of time.

If you want security, meet with person IRL and exchange Tox IDs. Anything other is not going to work.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1350#issuecomment-106567175 .

zetok commented 9 years ago

@linux-modder That's a wrong question. Correct one would be: "why would it be secure?".

AFAIK there is no way of making a secure, verified way of communicating with other party, about which you have no previous knowledge.

If you will think about how it's "doable" with https, there are certificate authorities, who are supposed to confirm that the entity is really who they claim to be - but in reality that model is simply broken. Also, it's not applicable in case of Tox.

aaannndddyyy commented 9 years ago

The advantage of signed pubkey over exchanging pubkeys bidirectionally: Faster, as you don't need to wait until the one who gave you the id, gives yours to the other peer.

The disadvantage of signed pubkey over exchanging pubkeys bidirectionally: Now someone can prove that you are in cotnact with that person whose pubkey you just signed.

Both approaches have the advantage that you can see who gave out your ID. Both approaches are per sé insecure and need additional securing (see issue about authentication) or trust in that entity. Either way, the user should be informed by the client about it.

Ferk commented 9 years ago

Correct one would be: "why would it be secure?".

It will only be secure if Tox communications beetwen A-B and B-C are secure as well.

I guess what you mean is that B, even if authentic, can try and deceive A by giving him the wrong contact (one that pretends to be C but isnt). But this wouldn't be a problem in the software, it's more of a social engineering thing and there's no defense against that. The thing is that A is supposed to trust B if she wants to receive a contact from him. The same thing would happen for email, phones or any other system.. even IRL someone can give you a paper with the wrong Tox ID. Or a person maintaining a Tox DNS server could go nuts and start giving wrong IDs for certain users.

codedust commented 9 years ago

Inspired by @jf99's 2nd idea and #1317, I would like to suggest a slighly different approach. The main difference to @jf99's idea is using NOSPAMs instead of signing publickeys. Here is how it works:

Alice and Bob are friends. Charlie is a friend of Bob and wants to become friends with Alice. Because Alice and Bob are friends, they already have exchanged their NOSPAM values with each other when they first connected (Alice has send different NOSPAMs to each friend). Now Bob can easily send [Alice's publickey, the NOSPAM value Alice sent to Bob] to Charly. Charly is now able to send a friend request to Alice. Alice will accept this friend request because it contains a NOSPAM value she previously sent to one of their friends.

Since Alice has send different NOSPAM values to each of her friends, she knows which of her firends gave out her publickey and is also able to revoke the permission to share her Tox ID simply by deleting the NOSPAM value she sent to Bob. It would also be possible to generate another NOSPAM value and publish the Tox ID containing this NOSPAM to your website/social network/... which was the idea behind #1317.

ovalseven8 commented 8 years ago

To be honest, I don't believe that Tox needs something like this at all. We should keep it simple, secure and privacy-friendly as possible.

A simple window with the display of the Public key with further explanations would be fine -> https://github.com/tux3/qTox/issues/235#issuecomment-54132957

The implementations, that are suggested here would cheat the purpose of the NoSpam value in my opinion. Perhaps someone don't like it that friends know the current Tox ID and are able to give it away.

Assume Alice and Bob are friends. Charlie is a friend of Bob and wants to become friends with Alice. Why not just this way? Bob is asking Alice for her current Tox ID and Bob will forward it to Charlie or the other opportunity is that Alice is using a ToxDNS service like ToxMe.

aaannndddyyy commented 8 years ago

@ovalseven8 The tox id with nospam would not be given out at any time, so this point if your criticism is mute. Re ToxMe: It is centralized. The model of friends introducing friends is a more distributed model without central points or a hierarchy.

ovalseven8 commented 8 years ago

@aaannndddyyy Of course, I have expressed myself wrongly. :wink: What I mean is that you cannot control then from who you're getting friend requests. Without this function you can change your NoSpam value and nobody is able to make a friend request unless he knows your current Tox ID. So, you're able to decide it. But with such a function your contacts are able then to give their friends the possibility to make requests to you. Also if you don't want that. That's what I mean with 'cheating the purpose of NoSpam'.

aaannndddyyy commented 8 years ago

@ovalseven8 As you would know which firend forwared the request or signed or whatever, i do not see a problem here. If you ge spammed from requests that a certain friend forwared, tell him to stop. if he does not, unfriend him. And the feature has often been asked for by users.

irungentoo / toxcore