If anyone would like to try the chat interface my address is ricochet:qn6uo4cmsrfv4kzq
Of course, if the Tor connection is live, and you are doing anything at all illegal on that connection, your endpoint is now linked to your real identity, so you are not quite as protected as you could be. If you're keeping a chat client like this live, you need to be careful how else you use the connection.
from first glance i was curious about this aspect. if a connection exists, the end points are known or unknown? if they are known and there is a db of endpoints to realids then these know endpoints are no longer anonymous...
i get that the content is unknowable due to encryption - that's fine. the endpoint identification though, seems pretty cool if this is truly anonymous.
my current understanding is even though an IP Address might not be connected to me personally, all the routers in between me and the destination server know that my IP wants to connect to dest IP . Thus there was some communication between my IP & dest IP at some time, and is in a log if routers keep logs (or any other device that is physically connected to the same physical path that my packets took)
Sounds like TOR hidden services don't create breadcrumbs like this then.
But as I2P is the ideal network, I2P-Messenger is far from the ideal client. Most of the code is a mess of if else statements and there are no other features than being able to chat 1on1 with another I2P-Messenger instance.
Had a good OS X client. Seems it has been abandoned though.
If you want your software to never change, then sure, a proof of correctness is enough. But I've yet to see a piece of software that is both relevant and never has to adapt to new requirements.
The level of blasé disregard for basic secure coding makes me think it is on purpose. More attention to security has been put into Postfix and OpenSSH than any of these encrypted but in no way provably secure chat systems.
What language would you use?
The requirements are that it be low-level enough that you can zero keys from memory and needs to be able to be ported to every major OS, including iOS and Android.
The red herring that gets trotted out is timing and side channel attacks, crypto itself can still be done in nacl. But everything else, GUI interaction, network interaction and parsing of external data should be done in a safe language.
The same argument has been said for Java (but turned out to have worse problems in practice), Ruby (where if you every wrote something in Rails you've been vulnerable halv a dozen times by now) and PHP (and any commentary here should be unnecessary).
Sure, all the obscure languages you mention which never had even one project with a fraction of the usage base of Apache or Postfix may have no known security problems, but that's not a something to boast about. If you really want these languages to succeed, build a project with the potential user base of Nginx or Linux. Just don't complain about other's language choices, especially not when those are well known and well understood ones.
And for two large companies to be working on something as large as Servo, even before the language went 1.0, there must be something good about it.
In fact, Java can be faster than C for a long running application, because you avoid problems like memory fragmentation. Garbage collection can compact used objects into smaller sets of memory, improving cache utilization.
As for timing attacks, it's very very hard to write sidechannel resistant code in any language, I don't believe Java is particularly harder. C/C++ is not as deterministic as you would think.
They seem to be using more standard libraries than Tox.
Also, Tor hidden services are not necessarily designed for the case of a single address coming online and offline repeatedly. I don't think there are specific known exploits for that case other than the timing issues, but the other thing that comes to mind is cycling through too many guard nodes over time.
Of course, this doesn't completely address the issue. It would still be theoretically possible to check for connections to the server, and determine online/offline status just from whether the messages are going out immediately after being sent in. Even generating fake data might not be enough to completely reduce that theoretically possible to the realm of technically impossible. It's still a risk to keep in mind. You can also never truly rule out that the service itself is compromised by an entity who wants your (meta or otherwise) data. You're safest disposing of your identity regularly, to disconnect previous conversations from new ones, if you're concerned about metadata analysis, which is considerably less elegant of a solution.
Of course, if your identity is anonymous, you don't truly have to worry about the metadata analysis, unless the person on the other end is compromised by a malicious agent, and knows details about you that could deanonymize you....
As soon as the thing needs to work with participants joining/leaving at will you'd need some kind of supernode or hidden server and that's a vulnerability.
If someone is looking for another address to add just to test this
gpg --verify doc.sig doc
Should the central server be the only missing component of a reliable, secure-paranoid, mobile IM system, I would be happy donating some dollars.
The general idea is that you'd fetch tokens from the server that allow people to send pushes to you, then distribute them to trusted contacts over an secure channel. Contacts would then be able to send you pushes from any endpoint of choice. Somewhat less metadata than existing solutions, and an opportunity for client diversity.
So honest is this app to explicitly state that I need to keep it foreground to receive new message from XMPP server.
They also have attitude of "oh we are smart, you just don't get it", which is not the way anyone should think about cryptography.
It is not usable too. Tried sending request to ricochet:qn6uo4cmsrfv4kzq
It refused to move beyond Request:Pending connection
Man i hate these security software soooo much.