Anyone looked this over? I only just discovered it, but it seems nice: * P2P * Encrypted * Voice/Video/Chat/Files * GPL'd https://github.com/irungentoo/toxcore It's written mostly in C(++) with a dash of assembly, which worries me security wise.. -- T: @onetruecathal, @IndieBBDNA P: +353876363185 W: http://indiebiotech.com
On Sat, Jul 5, 2014 at 2:13 PM, Cathal Garvey <cathalgarvey@cathalgarvey.me> wrote:
There's some sort of old and hopefully irrelevant spat here: http://www.tox-chat.com/
Hey. Am 05.07.2014 20:13, schrieb Cathal Garvey:
https://github.com/irungentoo/toxcore
It's written mostly in C(++) with a dash of assembly, which worries me security wise..
There's no assembly (that I could find). Github just mis-classifies Makefile.inc as assembly. It does depend of libvpx though which uses assembly liberally. Last time I tried to play around with it, it was far from usable. Not sure how much progress was made in the meantime. felix
On Sat, Jul 05, 2014 at 07:13:11PM +0100, Cathal Garvey wrote:
Anyone looked this over? I only just discovered it, but it seems nice:
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... -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
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
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... "/Licenced the code under the GPL for now./" (Free software? Good. But, "for now" ? Is it going to change?) *2. Runs in a browser * No. *3. Runs on a smartphone * https://wiki.tox.im/index.php/Multiple_Devices Has been suggested but not yet implemented. *4. The user doesn't generate, or exclusively own the private encryption keys* The user is in control, 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 *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. 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. *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. *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. ---- For some time I've wanted to evaluate TFC from these perspectives as well: * 1. Not free software * It is, and it will always be. *2. Runs in a browser *It doesn't, and never will. *3. Runs on a smartphone *Only the handler of encrypted messages might in future run on smartphone (or proprietary OS), the TCB's never will. *4. The user doesn't generate, or exclusively own the private encryption keys *The user does, and the user is also in control of the circuit that generates the encryption keys. *5. There is no threat model *The whitepaper has a five-page dissection about different attack vectors, what TFC is secure against and what it is not. *6. Uses marketing-terminology like "cyber", "military-grade"* It never has and it never will. * 7. Neglects general sad state of host security* This was the starting point. Key-exfiltration-wise, it is immune against post exploitation of TCB-modules. On 03.02.2015 18:13, rysiek wrote:
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?
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
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 <cathalgarvey@cathalgarvey.me>:
* 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!
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 <cathalgarvey@cathalgarvey.me>:
* 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
2014-07-06 9:56 GMT+02:00 rysiek <rysiek@hackerspace.pl>:
That all seems like MaidSAFE: http://maidsafe.net/
Maidsafe is trying to be the cloud but P2P. At Bitcoin2014 I asked as to why they wanted a blockchain/consistency, that guy didn't know (nice guy though), left my e-mail address and didn't hear back. It definitely rings a similar bell, it sure did with me when I heard about it. I've even pointed to it when saying how things could also be. Overall I'm underwhelmed by the design and I think it tries to do too much. I think It's not fundamental/simple enough. I think Blockchain style consensus is expensive and not required. Only reason I can think off is that they want premined coins or something. There's a whole flux of not-really-working-yet ideas that use the blockchain for no reason other than having premined coins and some P2P framework. It's interesting and good to see that blockchain-tech is such a key for people's creativity. And it's a shame that it's probably not the right tool for the job in most cases. (Consensus is overrated! Who needs it? You just need things to work the way you want them for you. What do you care how it looks to people you never deal with?)
On Sat, Jul 5, 2014 at 5:35 PM, Lodewijk andré de la porte <l@odewijk.nl> 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.
Dnia niedziela, 6 lipca 2014 13:42:55 grarpamp pisze:
On Sat, Jul 5, 2014 at 5:35 PM, Lodewijk andré de la porte <l@odewijk.nl> 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.)
Absolutely. Without serious and seamless interoperability, we have no way of actually getting people to use these solutions. "Nobody's there" × tens of solutions/networks. This is, by the way, a huge problem in the free and open decentralised/federated crowd. Consider this e-mail exchange: http://lists.w3.org/Archives/Public/public-fedsocweb/2013May/0058.html -- Pozdr rysiek
2014-07-06 19:42 GMT+02:00 grarpamp <grarpamp@gmail.com>:
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.
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.
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
On Sat, 2014-07-05 at 19:13 +0100, Cathal Garvey wrote:
Anyone looked this over? I only just discovered it, but it seems nice: * P2P * Encrypted * Voice/Video/Chat/Files * GPL'd
https://github.com/irungentoo/toxcore
It's written mostly in C(++) with a dash of assembly, which worries me security wise..
Tried this out with a friend last night. I'm disappointed so far, even given this is an alpha. Maybe I'm using the wrong client (Venom) but I don't see any way to do video or voice chat. I'm keeping it to send files encrypted as I'm not sure if Pidgin's OTR encrypts file transfers as well (guessing not) as well as keep testing it to try and find bugs. -- Shawn K. Quinn <skquinn@rushpost.com>
participants (9)
-
Cathal Garvey -
Felix Eckhofer -
grarpamp -
Lodewijk andré de la porte -
Markus Ottela -
rysiek -
Shawn K. Quinn -
stef -
Stephen D. Williams