Open jf99 opened 9 years ago
Something like 2nd idea will be implemented at some point.
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.
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
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
I like the second idea there a lot. You'd be able to see who gave out your ID.
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.
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.
@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
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
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 .
@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.
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.
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.
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.
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.
@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.
@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'.
@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.
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: