Yo, don't you die on me! Lately I started testing Tox, it's actually usable, voice and video, and file transfers work, it looks neat. Question is (to quote Tolkien, whom I'm sure we all love and cherish): "Is it secret? Is it safe?" So we have this: Dnia sobota, 5 lipca 2014 22:36:50 stef pisze:

afaics there's a traffic analysis weakness in all messages, it discloses both public keys of the peers in public: https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.md#cry pto-request-packets

We also have a brave soul (not me) that attemted writing proper protocol documentation for Tox, and started diving into the code. The docs seem lacking, the only things we've been able to find are: https://github.com/irungentoo/toxcore/tree/master/docs https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artif... Not *that* helpful, but look at the Crypto section in the PDF: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tox uses crypto_box() from the NaCl crypto library for all the cryptography in Tox. Unless otherwise noted, all keys refer to keys generated with crypto_box_keypair(), all encryption is done with crypto_box() and all decryption with crypto_box_open(). For performance purposes the functions to precompute the shared secret and encrypt and decrypt messages with it are used extensively in Tox; however, this is not relevant to this document. The function crypto_box() provides fast public-key authenticated encryption. For exactly how it works read the NaCl docs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hmmm... So, the brave RFC-writing soul got some questions. Maybe somebody here has access to some answers? Questions being: - does the transport layer have encryption? (does the middle layer do that all or...?) - where is the documentation of the cryptography? - is there any hmac done at all? - what is the tox id for a seed with all 0? - how does the tox implementation handle different byte alignment? - how does the tox implementation handle different byte endiness? - how well stressed is the tox implementation? benchmarks? - where is the rest of the documentation? - where can I find a full view of how tox works from bottom to top? Anybody? -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147

OHAI, So, I assessed it vis-a-vis stef's rules already, otherwise I would not dive into it at all. ;) But yeah, let's have a look. Dnia wtorek, 3 lutego 2015 19:28:01 Markus Ottela pisze:

From the PoW of Stef's seven rules of thumb to detect snake oil:

*1. Not free software * https://github.com/irungentoo/toxcore/commit/dcc3921682c8bededfac7d76f4976fd 56b051c72 "/Licenced the code under the GPL for now./" (Free software? Good. But, "for now" ? Is it going to change?)

So, that's not going to change, IMHO. There are several developers and I don't think there was any ascribing of copyrights to any legal or physical person, so changin a license *from* GPL is not entirely straightforward. I ticked this one as "AOK".

*2. Runs in a browser * No.

AOK.

*3. Runs on a smartphone * https://wiki.tox.im/index.php/Multiple_Devices Has been suggested but not yet implemented.

https://wiki.tox.im/Antox Still, you don't have to use it. As in, I use a desktop client, not going to be using it on my mobile anyway. It doesn't *require* smartphone use, just like e-mail does not *require* a smartphone e-mail app (if you use one, well, that's your choice). inb4 "e-mail is not safe" -- puh-lease, that was just a way to illustrate a point. "AOK" for here too.

*4. The user doesn't generate, or exclusively own the private encryption keys* The user is in control,

ACK.

yet the source of randomness and crypto implementation are not explained properly. The wiki talks about public keys and PFS without explaining the relation between the two. https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.md

ACK. So, the PDF I linked to goes a *bit* further (just a wee bit). Go have a look at the "Crypto" section: https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artif... So, at least not a "we hold your keys -- FOR SAFETY!!1!" kind of snakeooil. Half of an "AOK" from me here.

*5. There is no threat model* "/With the rise of government monitoring programs/" implies it's designed to be secure against state surveillance. "Tox does not cloak IP addresses when communicating with other users" In disclaimer it is also just stated that "/Tox prevents message contents from being read or altered by third parties, or anyone else other than the intended recipient/", yet it doesn't even bother to evaluate the system against HSAs or MSAs.

True. One has to consider their own threat model and assess if Tox is the answer. Tox does *not* provide anonymity, it at least *tries* to provide OTR- like features (encryption, integrity, etc.).

Instead, the threat model seems to revolve around developer anonymity (https://wiki.tox.im/DevAnonymity). "/Potential harassment by the government and trolls/" seems to include people pointing out issues with the software as well.

Indeed. So again, half an "AOK".

*6. Uses marketing-terminology like "cyber", "military-grade"* It doesn't, although it does say "/leading-class encryption/", and the logo is yet another unnecessary lock.

I like the logo. "AOK" from me, especially taken into account they're not reimplementing the wheel but using NaCL instead.

*7. Neglects general sad state of host security * This. The developers think it is obvious for every user, that if the endpoint device is compromised, there is no security. This is horrible since average computer user is still mainly occupied with thoughts "I need a firewall" or "I might get a virus" -- not "The government might exploit unpatched OS or exploit a 0-day" or "The company behind my proprietary OS might be issued a subpoena to include a backdoor". It's not the job of Tox developers to patch OS, but it's their job to warn users there are attack vectors the developers are not in control of. They have refused to do so, which limits the users ability to make informed choices depending on their threat model.

Well, yes, and my beef with Tox is also that the private keys do not require a passpharse to unlock. So that's a no-no in my book. Still, this doesn't look like snakeoil; rather like a good idea with not-so- stellar execution, which *might* get better. Am I missing anything?

----

For some time I've wanted to evaluate TFC from these perspectives as well:

Could we have a *separate* thread for it? I'm really interested in having a more in-depth discussion of Tox and this could potentially hi-jack this thread. Much obliged. -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147

Dnia sobota, 5 lipca 2014 23:35:18 Lodewijk andré de la porte pisze:

I apologize for the wording in the following post. I feel entirely unmotivated to do anything but write down what I think of in a fairly-hack-and-slash-and-mash manner and I am sort of fatigued and sort of boosted on caffeine (which helps remedy sleepiness and increases focus but does nothing for the intellectual fatigue I'm experiencing after a good 8 hours of mind-bending geometric programming***, tips welcome).

2014-07-05 20:13 GMT+02:00 Cathal Garvey :

...

* P2P * Encrypted

Tor/network layer ish stuff

...

* Voice/Video/Chat/Files

Application layer stuff

...

* GPL'd

You could give me a steaming pile of NSA honeytrap codepies, as long as it's GPL I'll trust it with my life and love it feverishly. (joke)

If anyone ever steals this idea I'll point to this e-mail and claim it was originally mine and it stuck in your head until you thought it was yours**:

Just write the communications layer. Expose it through a socket on the local machine. Let's say the port will be 33742 (actually a good port number) (say "eel for tee too") and one can talk modern-JSON-over-an-HTTP-subset with it.

Platform dependent high-performance stuff like COM objects, maybe some RPC, etc. are optional.

This little daemon/server maintains the connection to whatever P2P network is currently thought to be neat. It may or may not also do DNS-ish stuff and (if that's the popular P2P thing) it can have a keyring with trusted peers (aka "friends").

Once you have that you can communicate in an abstracted form. You can send messages that will pop out on the other side to registered listeners (method of registration is pretty much irrelevant, but let's say it's either directly by subscribing to 33742 or by some other sockety means).

The service rendered is "you give me a destination (as per my spec) and a message and I will make sure it gets there without anyone really knowing if it was us". So it's like TOR, but a little more explicit and less proxy-like.

You might wonder, why not proxy like? I like it because I never know whether something is going through the proxy or not. I'd prefer the application saying "Golly, where is 33742?" than going "You know, I swear we had this proxy arrangement.... Oh well".

33742 will also* do trickle connections and arbitrarily decide that a certain application is getting snailservice today. A few (~5?) trickle connections will always be kept cheerfully active, ticking away a few kbps of random data, and the occasional fully crypted packet that looks just like random data. Add some sort of meshing thingy on top of it, and the requirement that snailservice packets should be snailserviced with at least an 80% chance and voila every frikkin packet has plausible deniability ("I got it over trickles/snailservice!").

Then, to make it attractive to actually use it, you write *SEVERAL DIFFERENT APPLICATIONS WITH SPECIFIC PURPOSES*, because you want to do *one thing, and do it right*. One of these things should be an IMAP server, because letter-secret is very nice indeed.

Why? * Performance * Simplicity * Stability * Security * Modularity * Ease of extension * Separation of concerns

The best part? The longer you think of it, the better the idea becomes.

* if it's good 337. ** or the idea spread from someone that had this or a variation going on. The point is that I claim this idea. It's not very original because really it's just Tor++ with some reasonable processing, but that's what we usually call an original idea so I'll just claim it anyway. (Antartica is mine too btw, really) *** If you do enough geometric programming you start to notice that perhaps "space", geometry and coordinates and things like that, are probably not at all as natural as they seem to be. Graphics programming gives a similar sense. Collisions just aren't .. ¿ natural? Crypto really makes mathematical sense, but geometry, man!

That all seems like MaidSAFE: http://maidsafe.net/ -- Pozdr rysiek

On Sat, Jul 5, 2014 at 5:35 PM, Lodewijk andré de la porte wrote:

Just write the communications layer. Expose it through a socket on the local machine. Let's say the port will be 33742 (actually a good port number) (say

This little daemon/server maintains the connection to whatever P2P network is currently thought to be neat. It may or may not also do DNS-ish stuff and (if that's the popular P2P thing) it can have a keyring with trusted peers (aka "friends").

Once you have that you can communicate in an abstracted form. You can send

Yes, I've always felt the level of interop among crypto darknets is arbitrarily far less than ideal. Everybody seems to want to make their own user protocol for umm, say, the simple act of sending a message. And with all these different vertical darknet silos, you'll never be able to seamlessly cross message your friends on some other nets you also happen to be running. Then even if you got a pluggable *user* protocol for messaging, surfing, storage ironed out and made, you still have the problem of *backend* dest (and src) addressing. ie: There are at least four, maybe six nets I know of that can present an IPv6 tunnel interface to the user. Making it dead simple to securely route all your traffic into the darknet[s], or the entire set of darknets based on CIDR block addressing into them. But no, right now they overlap and conflict :( And without IPv6, they use different native addressing schemes. This begs for a serious sitdown conference amongst darknets to see what better cooperative user and backend interfaces might be possible. Or at least create one grand DHT based middleware addressing shim between them and the user (and preferably one that presents IPv6 tun interface, you know... because every app on the planet can speak that these days. Which is a big adoption win.)

You could give me a steaming pile of NSA honeytrap codepies

Mmm, pies, me hungry.

2014-07-06 19:42 GMT+02:00 grarpamp :

IPv6

To be honest, too centralized and too arbitrary. It's odd to declare IP(v6) addresses bullocks that simply. It's in our systems and in our thinking. But really, universally unique addresses are just a dream. The only address I think makes sense is derived off a public key. Any other address should be network-topology-semantic, not assigned by committee. That way there's real identity (private-publickey) and real address/location (place dependent or similar address) One of these months I will continue work on a paper reg. semantic addressing and a true IP layer replacement. I feel bad having talked about it for *years* now, but life and inexperience haven't really allowed me to make a great paper out of it. One of these months.

Let me know if you want a collaborator. I have a few things to get off my queue too. On 7/6/14, 12:28 PM, Lodewijk andré de la porte wrote:

One of these months I will continue work on a paper reg. semantic addressing and a true IP layer replacement. I feel bad having talked about it for /years/ now, but life and inexperience haven't really allowed me to make a great paper out of it. One of these months.

One of these months I will also write about a federated protocol that feels a lot like twitter meets IRC meets Wordpress meets e-mail meets FidoNet. It's all really the same problem anyway, you know?

One of these months.

-- Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer