first

yall would wanna hurry up with this
I'm getting tired of these threads

Oh how cute, another web based 'secure' communication service.

>>35434175
Leave or hide the thread.

/r/ing the new logo in high resolution

you know a project has attentions when you can chain threads like this for days

>>35434195
Not web based

File: 1374440229356.jpg-(22 KB, 310x310, Alec_Trevelyan_by_Sean_Bean.jpg)

22 KB JPG

>>35434195
The web is not the internet.

sixth for reddit project

>>35434204
I don't think the logo has changed.

The variants in the last thread were only ideas.

Trying to build on OSX. Getting odd build errors
http://pastebin.com/1sjZDVjd

All in DHT_cryptosendfiletest.c

>>35434087
You also have to pay a license fee to the foundry that you're getting the font from, even though the software might be GPL.

>>35434195
it's not web based, and it's not a service

where did you get these ideas?

>>35434140 (OP)
>implying that sage does anything

>>35434254
>implying
This is the old one that they used in the first threads >>35432727
Now look at the OP and the website

>>35434284
>implying it doesn't

>>35434282
Not that fag. But how does this differ from Bitmessage?

>>35434293
How big do you want it?

I was assuming that the white and black one was someone trying something different, and the video one I made, but it looks too busy.

>>35434263
>http://pastebin.com/1sjZDVjd

i get those errors too

>>35434340
bitmessage is not a practical _instant_ messaging system, as you need to do a proof of work for posting a single message.

I don't think that you want to burn cpu in simply posting a message, do you?

>>35434353
As big as allowed on /g/, I forget

>>35434353
Upload an image with the EPS embedded in it.

>>35434340
Ideally, userfriendly, easy to use, no GTK-puked out GUI

So uh, I don't get it. It's an IM to replace a VOIP?

>>35434340
looks pretty nice tbh, but ultimately is an email-like client, where tox aims to do IM/voice/video

could be a good project to learn from though, esp being open source, too

>>35434340
bit message is
>not instant
>no voip
>no video

>>35434421
>So uh, I don't get it. It's an IM to replace a VOIP?
It's an IM to replace centralized XMPP (which google trashed), AIM/ICQ/.Mac (which is horrible), and Skype (which MS backdoored the security on)

>>35434421
voice and video is in the works. I think someones already got something resembling voice working as just a test

Question: how are we getting around ISP and router firewalls?

>>35434515
Seconding this, I have a bitch ISP
will the ports be at random?

>No usernames
No casual/normalfag will ever use this.

>>35434566
There will be a system for that. Until then, we're using keys

>>35434566
There is always the nick that you could choose

>>35434140 (OP)
So, wait, the users have to exchange a key in order to chat with others? Tell me how successful that was on the Nintendo DS.

>>35434599
Only need to wrap in a user friendly coat.

File: 1374441352379.png-(1.02 MB, 4018x5000, tox-large.png)

1.02 MB PNG

>>35434412
>>35434383
I just have this saved from these threads. If you want something different, see /gd/.

>>35434653
The quality on that is shit.

>>35434599
it was pretty successful for bitcoin

>>35434672
By computer savvy people for computer savvy people. Tox is not just for computer savvy people.

>>35434653
What the fuck did you do...
Christ. Someone make a SVG.

>>35434683
>implying that wont be done by the clients.

>>35434710
So we're not making a client?

>>35434687
>>35434653
>>35434668

vexx.us

>>35434140 (OP)
>reddit link
And I have such high hopes for this project... (not really)

File: 1374441748317.png-(135 KB, 4104x5000, tox-icon-lock.png)

135 KB PNG

>>35434204
>>35434653
Here you guys go

>>35434740
This can't be a 4chan operation only. It would scare people away.

>>35434740
It's easier to keep in touch with specific people in a public setting on there when we're all in different timezones.

>>35434750
>135 KB

Fuck me, that's some good compression.

>>35434740
nothing wrong with using reddit for this.

>>35434740
>implying they aren't an incredibly resourceful hivemind that will make our jobs easier

no need to be pretentious.

>>35434770
It's essentially black and white, but an svg would probably be much smaller. Just upload one to pomf.se

>>35434770
It's two fucking colours.

>>35434770
>Only 1 color and alpha

Do you even know how that shit works?

>>35434770
>all white and black
>good compression

>>35434770
it's a quite primitive graphic

>>35434788
>>35434791
>>35434793
>>35434794
>>35434796

Are you guys serious?

>>35434740
>le sekrit klub

>>35434793
Hey faggot, leave my friend anon alone. He doesn't know this things, he can't really into computers, okay? Just show some fucking tact, goddamit...

>>35434140 (OP)

Is it being done with Tor in mind?

Shor's algorithm

>>35434829
plugins, my friend.

File: 1374442124113.jpg-(43 KB, 250x250, 37142543[1].jpg)

43 KB JPG

>>35434827

Ahahahah,
Oh man I just read that in Freddy Soto's voice... regardless.

>>35434829
if it can be made to support a socks proxy, then it will be able to go through tor

>>35434829
tor and udp don't mix well afaik

>>35434891
I don't know who that guy is. Glad I made you laugh. :*

>>35434169
>>>/youtube/

Well guys, we could you know, invite /int/ to help with the translations of https://raw.github.com/stal888/ProjectTox-Website/master/index.en.json

https://github.com/irungentoo/ProjectTox-Core/issues/37


We should probably consider doing this. Handling the friendlist and the messenger in the same file sounds like a very bad idea.

How is VOIP right now? I was just made to install skype by my lame friends. It was horrible. Has the ability to talk to another user been tested and confirmed to work yet?

>>35434733
>vexx.us
Shit, how many TLDs were bought because of this project?

File: 1374442647537.jpg-(40 KB, 320x240, DESTROY.jpg)

40 KB JPG

>>35434653
>>35434750

>>35435046
>vexx.us
> Vector saved as PDF
Fucking really?

>>35435046
I count 3
projecttox.org
tox.im

and now vexx.us

Holy fucking shit can you guys not provide a good fucking Logo

>>35435014
you will need to wait quite a long time before having a workable program

>>35435114
go ask on /gd/

File: 1374442948282.png-(265 KB, 334x393, EMBARRASSING.png)

265 KB PNG

>http://vexx.us/Images/
Shit Quality

>>35435153
I have at least one friend on linux who would be happy to compile a command line program with VOIP capabilities.

Has the messenger been tested on anything besides LAN yet?

>>35434140 (OP)
virus

>>35434970
We know, and we agreed to use other boards already.
/mu/ is really helping with the sounds, /lit/ rephrased the website already I think, and /int/ will help later.

>>35435240
>implying macs get viruses

File: 1374443373504.png-(37 KB, 364x308, 1319645542597.png)

37 KB PNG

>>35435263

>>35434729

competition =/= standard

STOP spamming this shit please
leave

Will there be any central server?

File: 1374443518751.png-(95 KB, 300x381, 137349603990615758858.png)

95 KB PNG

>>35435308
huehuehue master trole

>>35435332
I would almost think there would have to be, unless you know your buddies ip address.

>>35435332
Completely decentralized.

>>35435371
How is that possible?

>>35435371
How would that work though?

Even if I knew my buddies long ass public key, how would the client find him?

>>35435392
Through mathematics and calculus.

File: 1374443858003.png-(121 KB, 2000x838, 2000px-DHT_en.svg.png)

121 KB PNG

>>35435392
DHT.

>>35435417
ISP firewalls and router firewalls would block this though.

Even torrents have a central server.

>>35435444
>Even torrents have a central server.
Not usually. The only reason to have a 'central' server is for peer lookup. Magnet links don't have a central server and perform just as well.

Will there be a login screen for this program?

>>35435466

Has this been tested without using LAN?

>>35435444
This is true and is an issue, there are ways around it though. Torrents have the ability be run completely trackerless.

>>35435466
Magnet links still connect to trackers you fucking retard.

>>35435490
>Torrents have the ability be run completely trackerless.
> Magnet links still connect to trackers you fucking retard.
You just contradicted yourself.

>>35435485
Yeah, an early test build of the text chat part has been out for about a week now.

>>35435490
What will Tox do to work around it?

>>35435308
No.

>>35435508
No I didn't. You obviously just don't understand how bittorent and magnet links work.

Here's a typical magnet link:

magnet:?xt=urn:btih:335990d615594b9be409ccfeb95864e24ec702c7&dn=Ubuntu+12.10+Quantal+Quetzal+%2832+bits%29&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Ftracker.ccc.de%3A80&tr=udp%3A%2F%2Fopen.demonii.com%3A1337

Notice that is contains a bunch of urls for trackers.

>>35435046
They're like $10/yr, stop being poor.

>>35435114
/gd/ is mostly in charge of that, and it's high school dropouts and armchair designers shitting on every good design and praising crap like the current logo all thread.

>>35435528
And you said that torrents don't need them.

>>35435444
UDP hole punching.

>>35435550
Because they _can_ run without them. That doesn't mean magnets magically do that to torrents.

>>35434204
>>>/gd/

>>35435555
Who is the 3rd party host?

>>35435528
magnet:?xt=urn:btih:335990d615594b9be409ccfeb95864e24ec702c7&dn=Ubuntu+12.10+Quantal+Quetzal+%2832+bits%29

It also works without it.

Doesn't matter though, read this
https://github.com/irungentoo/ProjectTox-Core/wiki/DHT

>>35435612
you.

>>35435622
top lel

>>35435622
So how does client B connect to me, client A?

>>35435660
Through itself.

>>35435723
But how does it overcome the yucky problems with NAT's? Are you assuming we'll have the globally reachable IPs?

>>35434683
Not all the druggies on silkroad are computer savvy... It's not hard to copy paste.

>>35435808
I'm saying no 'commoner' will do that. It's much easier to add Likes2BoneMen as a friend than get their key from them somehow and paste it into a box just to send them pictures of your penis ( I assume Tox will support sending files )

Oh, by the way, remember to use only unicode fonts.
Translations will use «œ», «À», «Ç», «Ê», «È», «É», etc etc...

>>35435836
>Step A: Make a central server
>Step B: Make accounts on this server that just hold your public key
>Step C: Write a small extension to TOX to check this server based on usernames
>Step D: ??????
>Step E: Profit

>>35435861
>Make a central server
That's not what this project is about. This project doesn't want a central server.

>>35435869
It wouldn't be official, just a registrar. All it does is hold the decentralized public keys.

It's kind of like a DNS.

>>35435890
And that is a honeypot for ne'er-do-wells to get everyone's public keys.

>>35435182
I only just added saving and loading of keys. I.E. having the same identity on restarting the client. You still have to add all your friends again on each startup, and the test client is just that, a test client. You message by typing /m 0 message if your friends friendnumber is 0. That gets annoying after a while. The voice support is being worked on but it's not merged into the main repo, if you really desperately want to use it, ask in IRC. However, it's not just command line, it's user unfriendly command line, because it's just a test client, not meant for users, even command line users. If you want good encrypted voice chat, use Mumble for now. Everything is fully encrypted and the quality is fucking great compared to skype and the rest. You'll need a server though. I have one that doesn't see much use if you want to use it.

>>35435904
So?

Public keys let you send messages, yeah but that's kind of the point of a registrar. They can have their own rules and regulations.

>>35435920
And that totally undermines this project.

>>35435930
Not really. Anyone could set up their own one, like email hosts, and it's totally optional. All the actual messaging is decentralized.

>>35434140 (OP)
>Oh My

>Sorry, this tree took too long to generate.

HOW DO I MAKE IT NOT DO THIS? I just want the damn program.

>>35435930
No it doesn't. Not in any sense.

Nothing goes through the registrar. The registrar is not even official. It's just a big collection of keys that you can associate with usernames if you so desire.

They do not get your private keys, just your public ones. You are not forced to sign up. It is literally equivalent to handing your buddy a public key, just with middleman translating it from simple text.

>>35435920
it's not impossible to advertise your nickname in the dht (we will need to expand the capabilities of the current implementation, but it's possible to support a search feature)

>>35435979
Then why not build that into the core itself? Instead of hashing the key, hash the username and prompt the user to share their private key.

>>35435996
because it's not unique?

Guys, about the usernames. How about you make two options;
A) A decentralized database which updates upon starting the client
B) A central database for those who don't want to store the database locally or for mobile clients where the devices simply don't have enough space for the database/updating the database can be costly

Upon installing the client, the user will be presented with the option of connecting to the central database.

>>35435996
The core is as simple as possible. All it does is key exchange and messaging.

I'm actually opposed to it handling friend requests and friend lists. That should be up to the implementation of the core.

Ideally, the core should only do "Send message/video packet / Audio packet / File Piece to public key SOME_KEY." Nothing else.

>>35436015
Usernames should be unique, like any other service.

>>35435869
We discussed it in the IRC. We're going to have it so anyone can set up their own server to host their public key on, and you have the OPTION of typing in name@domain.com instead of their public key to add someone. It will query the server for the public key, and then display the key, display a 5 word phrase generated from the key, and ask you to check it's correct, and if it is, you click accept. That way you can tell your friends to add you as moot@4chan.com and the 5 word verification phrase should be "correct horse battery staple bitch" which is a lot easier to remember than a public key, and you don't need to type it in, it's just a check to verify the server you queried hasn't been modified to display someone elses public key.

>>35436027
>That should be up to the implementation of the core.
So, conceivably, there could be multiple implementations that could be incompatible with others and fragment the userbase?

>>35436032
how do you enforce uniqueness?

>>35436056
If you try to take the name "Gentoo5ever", the client attempts to ping "Gentoo5ever", or see if any of the nodes knows of this name. If it does, reject the user input and tell them to try again.

>>35436046
something like webfinger ?

( https://code.google.com/p/webfinger/ )

>>35435972

github is currently fucked

>>35435972
add /tree to the end of the URL. So:
github.com/irungentoo/ProjectTox-Core/tree

>>35436092
Son of a bitch, THANK you anon.

>>35436071
in a p2p system with a dht is really really bad to have something like that, as it's quite easy to monopolize a lot of username, just waiting that the user is offline

>>35435996
because that doesn't work faggot. if two people picked the same username they'd have access to the same account. that's retarded. even if you associated with a private key in the network, who decides who gets it? If two people register at the same time, some of the network will say person a has the username, some of the network will say it belongs to person b. Things aren't simple in a distributed network, it's not a central server.

>>35436052
Nope. All the friends list really does is store a big list of public keys.

And I misspoke - I mean implementations /around/ the core. Again, in my mind, it's best if the core only does "Send whatever to PUBLIC_KEY." Friends lists and such can then be implemented in a platform-specific way, but they're really just lists of keys, maybe with some metadata added on.

This allows platform-specific storage - For example, you might put it in an SQL database for IOS, but it might be better to use a .ini file for Windows.

>>35436138
Shouldn't the core also handle exchanging the keys, so the clients Person A is using doesn't have to worry about whether or not the client Person B is using returns the private key in some different way?

Trying to do decentralized usernames is retarded. It would be easier to just make a protocol to allow people to host username servers to work similar to email addresses, so

username@usernameserver.tld

Would query usernameserver.tld for the username.

>>35436138
>or example, you might put it in an SQL database for IOS, but it might be better to use a .ini file for Windows.
Or you could just use SQLite everywhere and not be a retard.

>>35436184
>It would be easier to just make a protocol to allow people to host username servers
>host servers

Most normal people don't have time for learning server administration.

>>35436184
like webfinger does: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-15 .

>>35436170
The core does that. It's just up to the clients to do the storage.

>>35436203
It's possible, but I think we'd get more adoption if we went the other way.

>>35436228
I could write it myself. In fact, I think I'll get on that.

I'll eventually need donations for hosting, but whatever.

>>35436203
This. Let's keep things nice and unified.

>>35436228
It wouldn't be for end users, it would be for, for example, corporate networks, or other such services.

>>35436228
having a service where you host your public key so you have username@domain is quite easy and safe, as you cannot hijack the account.

>>35436228
Most normal people don't host their own email servers, either.

The username servers would be completely optional services provided by interested parties.

>>35436251
>It's possible, but I think we'd get more adoption if we went the other way.
FUCKING, WHY? It's not like users are going to be manually editing the friends list database.

>>35436256
I'll concede that point. SQLite would be a very good solution.

However, it's currently done with an array of FRIEND structs. That's... not a good solution. Even worse, the friendlist is kept inside of the messenger.c file, which is supposed to be for the text-only messenger.

That's something we need to fix badly.

>>35436288
See:

>>35436307


After thinking, yeah, you're right. SQLite would be a good solution.

Just... Anything but what we have now.

>>35436307
just expose some callback functions for handling the friend list (and move the implementation in the client).

So in the initial friend request, why does Alice send her private key to Bob?

>>35436502
she does not.

Also, the chat protocol and NaCL do not guarantee non-repudiability, so there is nothing to stop man-in-the-middle attacks between people chatting

>>35436570
My knowledge in cryptography is pretty limited, but wouldn't you need both people's private keys in order to man-in-the-middle attack this?

>>35436570
how the MITM would work? You cannot forge the message.

>>35436661
(if you don't have the PK, obviously)

>>35436661
if the MITM is between you and your friend exchanging keys, they can replace the keys with their own, and relay the messages between you. If you exchange the keys in person they can't do that though.

>>35436720
that's why you add the public key of your friend with an out of band mechanism. Quite hard to replace the key.

>>35436661
>>35436651
Quick scenario then. Pretend I am Mallory sitting with complete control over Alice's network. Alice tries to send a friend request to Bob. Mallory intercepts the "01" packet and duplicates it with some keys generated on-the-fly. Mallory then forward the new request on to Bob. Bob then accepts a friend request from someone he thinks is Alice, but is actually Mallory. At this point, Mallory doesn't even need to control Alice's network, as when Alice tries to communicate with Bob she will actually be contacting Mallory. Mallory can then simply forward messages between the two and decrypt the messages because the only thing Bob and Alice sees are some keys and cannot verify who actually owns what keys.

>>35436761
that pretty quickly eliminates the "Configuration-free" goal as it now puts key management back onto the users, which is a pain in the ass.

>>35436570
We could always just make it so users have to sign their outgoing messages.

>>35436893
Signed with what? A self-signed SSL certificate? Or are you going to make people drop $30/year for real certs?

>>35436931
>We're already using public key encryption
>You ask what we'd use to sign the messages
Please tell me you're joking.

>>35436807
You can use distributed verification or nonces to prevent this, though.

>>35435013
>>35435013
>>35435013
>>35435013
>>35435013

SOMEONE MAKE A THREAD ON /int/

Ask them if they would be interested in helping as they can, i.e. translating https://raw.github.com/stal888/ProjectTox-Website/master/index.en.json

Explain the project in simple terms.

>>35435014

Yes, and it works well.

>>35437037
Which part of the program do I make? I want to test it!

>>35436976
Alice signing her own messages doesn't help if Mallory is already pretending to be Alice. Mallory just signs the messages sent to Bob using her own key, which Bob thinks is Alice anyways. If you are doing some sort of signing, then the authority who signed the certificate must be a trusted third party.

>>35437007
Distributed verification is going to wreck the privacy of the network, and a nonce doesn't help if you are sending it in the "01" packet unencrypted.

>>35437063

It's not on the github yet, the audio developer posted the code for testing on the irc channel.

>>35436807
from https://github.com/irungentoo/ProjectTox-Core/wiki/Crypto if I understood correctly, Alice has the public key of Bob.

So in your scenario, Bob could talk to Mallory, but Mallory cannot forward the message to Alice (as she has Bob's public key). So Alice will know that something is off because she has not received anything from Bob.

>>35437135
(correct me if I'm wrong please)

>>35436807
could you open an issue in the github tracker? This is interesting.

>>35437097
>and a nonce doesn't help
The point of the nonce is to validate the legitimacy of the request. It prevents replay attacks entirely. If you really want to send '01' unencrypted to get a friend invite, then you don't need to MITM to do it yourself anyway. A distributed verification lets pears know partial information and require the input of N peers to decrypt a message (this could be very good to perform a handshake, and is essentially immune to MITM. It also prevents any one peer to go rogue).

>>35437159

THIS

Guys, go on GITHUB and open as many issues as you can, as many suggestions as you can, as any ideas as you have...

If there, it WILL be looked and considered. If you post it in threads and on the irc, it may just be lost. The community opinion and ideas is too important to be ignored.

Go to github, guys.

Also, if we star and fork the project a lot, we might make it to the "trendy projects" on github and gather more attention and help.

>>35437024
We don't really need translators right now

>>35437135
If Alice and Bob are already friends, then yes, it is secure. However, the process by which Alice and Bob add each other to their friends list (exchange keys) is insecure and can be exploited in a man-in-the-middle attack. There is no mechanism in Project Tox (or the NaCL encryption library) to verify that the person on the other end is actually who they say they are.

Mallory can put some spyware on either Bob or Alice's computer to accomplish this. Hell, I can fork the Github repo, build a compromised client, and then distribute the binaries on /g/ for maximum lulz.

People are known in the network by their public keys.

Just make encryption two pass, where the user signs with their private key first, and then the recipients public key so that the recipient has to decrypt using the public key of the other user in addition to their own private key.

>>35437135
>but Mallory cannot forward the message to Alice
Why? Mallory has the encrypted message, and if he gets access to bob's public key, he'll also be able to decrypt the message. Just because Mallory can decrypt the message doesn't mean the encrypted representation magically disappears.

>>35437227
Just fucking require BOTH users to add people rather than allowing one-way friend adds.

>>35437226

It's for the website, not for Tox itself.

With a better website, we get more developers.

https://github.com/stal888/ProjectTox-Website

Languages until now:

English
German
Polish
Dutch
Portuguese
Sweden
Italian

>>35437190
I don't need to replay to do man-in-the-middle attacks. You guys are just using a random integer as a nonce and not a time-stamp, so I can delay the outbound message as long as I fucking please and it will still work. Not that it would matter anyways, as I have both Bob and Alice's keys so decrypting the message would take much less time than the total network latency anyways.

>>35437217
I would rather distribute compromised clients on /b/ for the lulz.

>>35437227
The current mechanism as far as I understood, is fragile on the side of the the guy that receive the request.

One side has always the public key of the other for creating the friend request.

So yeah, Bob can be decieved as he can recieve a request from another person (no need to MITM).

But a MITM that trasparently shuttle bidirectionally the messages is not possible, as Alice _has_ the public key of Bob. (Bob does not).

>>35437260
The protocol is already like that, and that's why it's broken. Alice receives a friend request from Bob, and she can't verify that is Bob. Bob simultaneously receives a friend request from Alice, but cannot verify that it is actually Alice.

>>35437304
If both users have to manually add each other's public key to their friends list, then it becomes rudimentary to prevent a MITM if you use something like: >>35437233

>>35437233
That's just Diffie-Hellman, which SSH uses, and which is still vulnerable to MITM attacks.

>>35437227
>>35437135
>>35436807

https://github.com/irungentoo/ProjectTox-Core/issues/82

I won't be always checking the thread and gathering issues and suggestions.

Please, use Github, people.

>>35437263
Well okay, which languages are needed most right now?
I'll work with you on this

>>35437240
because Alice will attempt to decrypt the message with Bob's public key?

>>35437322
so you are suggesting a side-band passing of the public keys to verify the identity of the owner of said keys? Again, this makes the project very much NOT "Configuration-free" and a pain in the ass to set up.

>>35437345
>because Alice will attempt to decrypt the message with whom she believes to be Bob's public key, but is actually Mallory's public key?

FTFY

>>35437344

Any languages.

Even the obscure ones.

Really, the more widespread Tox is the better, so anything is welcomed.

If any priority is to be given, though, we'd base ourselves on this: https://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers#World_Factbook_.E2.80.93_CIA.5B1.5D

But that's not too important to focus.

>>35437354
Do you have a better idea ?

In the end, you _need_ to add or accept people in one way or another in your friend list.

How do I make a new translation?
You should mention that the portuguese translation is a brazillian one. I'd like to make the portuguese from Portugal version. (I know this sounds awkward, but the languages are a bit different, it's not just about accent, and brazillian translations don't "sound" right.)

>>35437384
Is there a write up already made to help people know what they're doing when translating this stuff?

>>35437376
no, because if you look at the Crypto document, you will notice that one side know the public key of the other. (the other that receive the request does not know)

So it's only the recieving side that is subject to identity forgery.

>>35437403

You copy paste this and translate the thing between quotation marks: https://github.com/stal888/ProjectTox-Website/blob/master/index.en.json

We are using the following codes: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

I don't think they separate pt-br of pt-pt (or whatever).

If you really feel the need, just do it and I'll talk to stal.

>>35437412

No, I don't think so.

We simply give this as a mock-up: https://github.com/stal888/ProjectTox-Website/blob/master/index.en.json and people translate the things in red.

>>35434140 (OP)
>>35434140 (OP)
I HAVE A QUESTION.

I have followed the entire process, to the point where I have said "make Messenger_test"

It finished. Now... how do I test it. What command do I use?

>>35437397
You must implement some way to verify yourself as the owner of a particular public key (chat ID string). How you would do this securely and still make the system distributed p2p, I do not know.

>>35437416
Yes, but you are missing the bigger picture. If two people are going to communicate, then they both must be the receiver at some point during the conversation, therefore the attack will work both ways equally well.

>>35434246
Best villain, best film.

>>35437416
But I agree that we should remove the friend request feature which can be dangerous and use out of band key exchange. (That we can make it user friendly)

>>35437440
Hold on, there is an archive of /int/ posts
Someone made such a thread there yesterday...I'll find the archive and we can copy/paste it again.

>>35437448
>>35437448
Please answer this, I really want to try it, I just don't understand wht to do once the instructions are gone.

>>35437427
It's not really a need, I'm just trying to help here.
Anyway, think of it as the difference between American English and British English (but "bigger")

>>35437477

But it failed hard.

Nobody helped, did they?

Let's try to make one more creative, better explaining Tox in layman terms, etc,

>>35437483

Go ahead!

>>35437492
We got a bunch of people who expressed interest but I don't know if they left any contact details.

>>35437505

oh, I see...

Well, it only takes some minutes to translate those sentences

Is this going to be easy to use? How are users going to look up the person they want to chat with?

>>35437460
yeah, the unique system is an out of band mechanism (for example something like webfinger so you can have a url -> public key mapping ?)

Sorry, but I still don't understand how you can MITM on the side of the person that _know_ the public key of the other person.

>>35437513
>Is this going to be easy to use?
It's supposed to be easy to use.

>>35437448
>>35437448
>>35437448
G-guys...

Please answer this question.

>>35437537
Ask on the IRC.

>>35437516
Ok, I will try and make this as clear as possible, step by step. Assume that Mallory has complete control over Alice's network, and Alice and Bob want to chat to each other using Tox. Here is the exploit:

1. Alice sends a friend request to Bob
2. Mallory intercepts the friend request from Alice
3. Mallory sends a friend request to Bob purporting to be Alice
4. Bob accepts the friend request from Mallory thinking it is Alice
5. Mallory then finishes Alice's friend request by sending a forged return friend request packet supposedly from Bob.

Now, when Alice wants to send Bob a message, they set up their session keys like normal, but they are actually exchanging keys with Mallory instead. In this manner, Mallory will now recieve messages from both Bob and Alice, and can manipulate them, save them, or simply forward them like normal and both Bob and Alice will not notice. This has the added benefit (thanks to DHT) that Mallory now no longer has to maintain the ability to intercept packets on Alice's network, as Alice genuinely thinks, for all intents and purposes, that Mallory *IS* Bob.

>>35437536
>How are users going to look up the person they want to chat with?

>>35437669
See: https://github.com/irungentoo/ProjectTox-Core/issues/82

>>35437669
Hi, there is a problem with this

The message alice attempts to send to bob will be encrypted, Mallory will not be able to decrypt it, therefore she will not know what unique message alice sent to bob. Mallory will have to forge something

Bob will see it's not the predetermined message and ignore the request

I'm aware this requires a lot of out of band comms

but if your paranoid enough to worry about that, then you have those channels

>>35437669
why don't alice and bob just fuck?

>>35437700
That's the main problem I see with this project, no normalfag will use this ever.

>>35437716
we're working on centralised username services

tinfoilers can exchange keys in person, others can use username services

>>35437711
>>35437701
But if I'm going to all the bullshit of setting up secure side-channel communications, then why wouldn't I just use those side-channels to talk to my friends in the first place?

Basically the security model of Tox is going against its own design principles to be easy-to-use and configuration-free and is thus doomed to never be used by more than a handful of people.

>>35437669
There is nothing like that from the protocol page.

(One side at least has the public key of the friend).

Additionally, for detecting a MITM the first message could be some kind of confirmation phrase that must be checked with an out of band mechanism.

>>35437730
Oh good, centralized services that I can DDoS so that nobody can add each other as friends anymore.

>>35437732
>>35437730
see this

>>35437735
see >>35437732

>>35437746
Yeah well it's not our fault normal fucks can't be bothered to self sign certs so we can do decentralised username to pub key mappings

>>35437732
but _even_ in skype you need to add your friend in the list.

So the current mechanism in tox is not _that_ different you know?

>There are many so called Skype replacements and all of them are either hard to configure for the normal user or suffer from being much too centralized.

HEY GUIZE LETS BUILD CENTRALIZED NAMESERVERS

>>35437730
Why would someone use this when they can just make a Jabber account and use Jitsi?
Anything other than Jitsi being written in Java?
I'm not knocking this project, I'm just curious.

>>35437746
no need to be centralized.

See webfinger for example.

>>35437775
encryption

>>35437773
optional

>>35437785
and can be decentralized without effort if it's done correctly

>>35437792
But if it's decentralized then it can no longer be trusted

>>35437775
I couldn't get my friends to use Shitsi, it didn't even start on my PC when I tried it.

>>35437784
Jitsi lets you use text and voice encryption.

>>35435763

Not that anon, but I guess people will have to learn to forward ports on their routers. I know that kind of defeats the aim of run and message, but I don't see an alternative.

>>35437827
Sounds like an operator error...

>>35437828
encryption by default

>>35437839
it uses udp so does automatic nat traversal

>>35437846
Jitsi has that option...

>>35437808
uh yes?

I mean, if I said to my friend: add my username hurrdurr@derp.com and derp.com has a service that return the public key of hurrdurr, we are good to go.

>>35437855
as well as that there are some bootstrap dht servers that can help with nat traversal

>>35437861
Unless you can get Yahoo, Google, and Microsoft to support such a service, you are not going to have anybody using it.

>>35437842
Well, it just crashed when I tried to open it.

>>35437884
we can achieve something very similar: whatever domain with the service -> third party login with oauth2 -> register public key -> recieve unique url

>>35437930
All of that shit so that I can send secure chat messages someone? Holy fucking shit what the fuck are you smoking? Nobody will do any of that ever.

>>35437950
how is it any different to the skype service?

>>35437950
you can streamline the registration quite easily for the people that _want_ a human readable handle.

But hey, propose something better and more easy to use.

If you guys want too get the site translated, do this:
>Make a big "HELP US TRANSLATE THIS SITE INTO YOUR LANGUAGE!" button on the main site
>Give instructions on how to translate
>Get people to send the files to a specific email
It's that simple

>>35437968
you need to register a msn live account and then, oh crap, it's already too hard.

>>35437263
French translation, version 1.0:
http://pastebin.com/kdbjk1CX