Tox IDs too long

[azazar]

Tox IDs take too much space on a webpage. Why not use base58 encoding instead of hex? Vanity generator can also be used to shorten IDs further.

[LittleVulpix]

@azazar just use https://toxme.io/ :)

[ProMcTagonist]

@azazar You can also use QR codes and tox: links, both are very easy to use.

[o-jasper]

I think base58 might be better too. Disadvantage is that they might look too much like bitcoin addresses. Dunno if something like base50 or base32 looks drastically different to the eyes?

Or alternatively, go unicode.. It'll probaby "select right" with the mouse. Then could base... high. Gotta be careful of doppelgangers there though...(and use unicode that is always installed)

toxme.io is a centralized service? Decentralized alternatives is to put names into some blockchain.

[optimumtact]

Well correctly the toxdns system is federated, but yeah, it does compromise somewhat on decentralized nature and safety for convenience.

[azazar]

Contact information should be compact. QR codes or very long addresses look awful near e-mails or phone number.

[GrayHatter]

is there any reason that this shouldn't be a client issue? Toxcore should/could/does see tox addresses as binary, clients should/could use a different base to represent them?

[o-jasper]

Well you want the different clients to be consistent about it! You want the address to be usable in any client.

[ameenross]

@GrayHatter I'm thinking about the Tox URIs

[friend2]

Websites like https://toxme.se/ and https://toxme.io/ are completely centralized and defeat the purpose of Tox (decentralization). It's very weird that the tox developers allow this websites to be advertised like this everywhere.

Huge point of failure and privacy concern. Should stay away from centralization like this.

[nachfuellbar]

@friend2 i don't see problems with centralized services like toxme.io because they are optional Maybe it should be said this services are optional and centralized

[o-jasper]

@friend2 good point; they're alledgedly against MITM, but really provide a central location to MITM. It is even demonstrated by domains they lost recently.

Question: if a connection is MITMed can you see that by the delays or something? Suspect it'd be too easy to false-positive or might be noisy.

I think blockchain approaches could be neat.. Probably would weigh the project down. Imo; let some layer behind -like clients- do it. Main issue with it is that with existing blockchains you need some coin in to establish a name. However, maybe some parties could just collect names, and then push in the root hash of a merkle tree for minimal costs. Note that a merkle tree proof that your name is in there is potentially not enough; your name might be in there twice. You need all the data about the merkle tree, and to verify that whole thing. Hurting privacy again. Besides, the collector knows it too.

Alternatively, could go like twister and modify NoSpam hashes, and make establish a name hashes such that they support a blockchain.(something distinct from all existing blockchains and ASIC/GPU hard) Nospam hashes might be helping secure a blockchain, i think it might be a bad idea to make them worth something outside of what they do.. because that might attract people mining that value, and thus able to produce nospams at a massive rate. (besides, you already april-foolsed it :p)

[aaannndddyyy]

@o-jasper about the MITM threat there is already a ticket. The easiest way to mitigate that is a simple authentication protocol, where you verify your friend after adding or in the process of adding him. Some also suggested, the central server give out only partial tox ids, and the user must complete them. This would not be a good solution though, as it is too easy to break.

[x368]

@friend2 :+1: indeed the documentation and advertizing badly lacks a clear distinction between secure and insecure tools and behavior.

This is without doubt confusing to many of the visitors. The security minded ones feel being cheated. The naive ones get an impression that the system is too complicated without a good reason.

Moreover, the security minded also get the impression of overcomplication. A lot of attention is put on the support of insecure practices, for example ToxDNS is referenced without clearly marking the huge gap between the hopefully secure Tox network and this conceptually fully independent and insecure protocol and services.

All references to "name mapping" services should go into a part of Wiki marked "related but insecure tools".

[x368]

@aaannndddyyy As long as a "simple authentication protocol" is not detailed and analyzed it unfortunately remains nothing more than a wishful thinking and can hardly be called "the easiest way to mitigate".

The whole issue of MITM-in-Tox stems from misunderstanding of the promises of the Tox protocol and network. This network does not in any way establish a proven connection between a key and a physical entity. It can not. Actually, nothing can (surprise?).

This problem is very general, any communication system faces it. There is no known complete solution, it is being partially mitigated by different means like state-run identity services (id-cards), the PGP web of trust, web PKI, ssh/web key pinning and similar approaches, all of which are approximations and incomplete in different ways.

It would be naive to percept Tox as a solution to this general problem which is totally separate from what Tox actually solves: to securely and comfortably communicate with the owner of a given key whoever the owner is.

Anything beyond this is wishful thinking but lots of people seem to fall for it, resulting in totally pointless dissatisfaction and attempts to "fix" it despite the constraints of the reality.

Please keep the "available, possible and secure" apart from "desired but either insecure by choice or impossible".

[aaannndddyyy]

@x368 re the first of your two comments: +1 A clear separatation and distinction would be good. Mark insecure things as insecure. But many skype, facebook and whatsapp users would be scared by reading it is insecure, and stay with their services, not knowing that they are insecure too. So it should be stated that insecure means basically as insecure as those services, not more not less. You must not forget that "normal users" are targetted, not necessarily people tech-savy.

re your second comment: I know nothing is perfect, but I do not think that otr's socialist millionaire protocol is as insecure as you make it look. It is not perfect, but it would imho be a huge gain, and making MITM very difficult, given a secure secret is chosen.

But as I said, nothing is perfect. Not even the parts you call secure. Security just means a low probability of compromise, not that it is impossible. Such systems do not exists.

[x368]

@aaannndddyyy Thanks for the constructive reply.

I agree that the socialist millionaire protocol would be useful to exchange Tox keys between two parties possessing a common secret token (among others, each pair of prospective parties needs a separate secret for the protocol to be applicable).

Basically, this would move the hard task (establishing a reliable shared secret) somewhere else so that no miracles will be expected of Tox. The project could get rid of some mirrors and smoke! :)

Then we could say:

"The authentication task is not solvable in general but if you meet in person and create, or otherwise happen to trust some shared secret, then Tox can make proper use of this information, as securely as the secret is by itself. (Concerning other means to verify Tox keys, we recommend to never trust any name-to-Tox-key services.)"

This would be understandable for the users, probably appealing to them and also correct.

Until the socialist millionaire protocol is implemented, all we honestly can say is:

"The authentication task is not solvable in general. For the technically savvy we can suggest to exchange your Tox keys via signed PGP mail (thus moving the hard task somewhere else) or print them on paper for OCR if you meet in person. For the others who can not afford a meeting in person we recommend use of several independent channels, like telling the Tox id over the phone and at the same time sending it in a paper letter for verification, both received versions have to coincide perfectly for the key to be acceptable. Email can also be used as an additional independent channel for extra verification. Sorry for the ID being long, it must be long and every character verified, to be reliable. By the way, we recommend to never trust any name-to-Tox-key services."

This is far from appealing but this is what should be said right now by a responsible project aiming for security.

Thus, your suggestion about the socialist millionaire protocol looks in fact very valuable.

[aaannndddyyy]

it is not a solution t oeverything, zrtp might also be handy, but only if you really do voice. If you analyze who you would want to authenticate: 1) old time friends: find them via some lookup service, authenticate them with a question only they should know, using a zero proof protocol like the one mentioned above. If you haven't seen them for long the voice may have changed and zrtp is not so useful. Since you do not allow for a million wrong answers, you'd be pretty save from bruteforcing.

2) Someone you just met and want to stay in touch with: Yimply exchange the tox id's (e.g. in form of qr codes) directly. This should be done by BOTH parties. The Friend Request mechanism is intrinsically unsafe too. though you could infer from the timing that it is unlikely someone else just added you too,

3) Someone you have never met. Well, so either it is a random stranger anyway and identetiy does not matter, except from that he stays the same person. Well there is not much to be done here, any potential MITM could simply directly add you. But if it is a person somehow publically known, then this person should somewhere publically announce his or her tox keys or his or her pgp keys, then by simply signing the tox id with his pgp key, this person could authenticate his/her tox id. So the trust part goes to hwere he announced his gpg keys. but that is not tox's task. Tox's taks is to provide secure communication once the tox id is known, and, ideally, provide a protocol for case 1. Then all cases (1-3) would be covered as well as possible, as far as i can see.

That said, your notices sound good to me. Mabe it should be more noob firendly. People want to be save and know what they have to do to stay save, without getting a lecture about the details of why and how.

My go at it looks like this: "Authentication is a sensitive issue. Most services on the internet rely on a cerntral authority htat you have to trust. We believe that this design is flawed, and we prefer not having to trust anybody. If you meet in person, both of you should exchange your tox id's directly. Then you can be sure you are talking to this very person via tox. If you use a lookup service, please be sure to authenticate the peers by clicking authenticate [supposedly this would trigger the zero-knowlege proof protocol] for people you know personally (and be sure to use a strong secret), or obtain a pgp-signed tox id from the person you want to communicate with. Do never trust services that lookup a tox id based on a name or phone number. Those can be false. However, the security risk is of the same nature as trusting facebook, skype or whatsapp. If you already trust those, tox cannot make it worse."

Probably still way too wordy. So it is to be seen just as a pointer to what I have in mind, not as something to be really used. Also, should it be on the website? Or should the clients display it when using DNS?

I also like your "[…] we recommend use of several independent channels, like telling the Tox id over the phone and at the same time sending it in a paper letter for verification, both received versions have to coincide perfectly for the key to be acceptable. Sorry for the ID being long, it must be long and every character verified, to be reliable." But for normal users, I think if you hear the voice on the phone it is already enough. Very few people would additionally send a letter. And the phone can also be replaced by tox itself. Then it is important to point out that just hearing the correct voice does not mean that there is no MITM, but that the correct voice needs to read out the correct id. That's my 2cts. and well, we'ree a bit offtopic for this ticket.... (it was only about length of tox id not mitm)

[x368]

As of being offtopic, I guess the length of the ID matters only when manual typing and manual verification are inevitable.

Making the verification procedure less tedious reduces the "length problem" a lot (even though having some "canonical" human-readable representation of a Tox ID remains important).

Hope also that our discussion will be found when people look for related topics.

Agreeing with your comments, nevertheless I would use a quite different wording for the "commonly known" communication services:

"However, the security risk is of the same nature as trusting facebook, skype or whatsapp. If you already trust those, tox cannot make it worse."

Instead:

"The security risk is of the same nature as trusting facebook, skype or whatsapp. This is not to be taken lightly. In fact, getting rid of this risk is the very reason for Tox existence."

Isn't this the case? Tox is the first and still the only (?) to avoid a dependency on registries while doing personal voip communication (besides mumble-over-tor which is hardly comparable). Why did we need the Tox protocol at all? That's why.

[LuccoJ]

@x368 Just FYI, Tox is not currently the only one to do that: RetroShare 0.6.0 supports VoIP and video, and it is also based on looking up contacts in a DHT (but instead of a "long Tox ID", it has a... much much longer PGP certificate to enter!).

[GrayHatter]

dup of #1222 but that's because that issue title sucks, taking suggestions.