Matrix.org/Riot.im has all the encryption you could wish for, a modern, useful interface, and a federated model in which everyone can run their own server and talk to everyone else, just like email.
Sunsetting Tor Messenger
61–70 of 71 posts
Re: Sunsetting Tor Messenger
#62I think about trying to hide the metadata of who is communicating... I wonder about a public stream of end-to-end encrypted messages. Anyone can add a message to the stream. Everyone reads all of the messages, and tries to decrypt all of them. There are lots of variants to this, lots of ways to optimize it, probably lots of ways to implement it. But that's the core idea. One variant is that what everyone downloads is…
I believe there is a Usenet newsgroup, somewhere under alt.binaries, that's effectively a numbers station: it's just GPG-encrypted (but not signed) blobs with no titles. Anyone can post, anyone can listen, everyone has to download everything to figure out which things they can personally decrypt. Sadly, googling related keywords doesn't seem to pull up the name of the newsgroup. I believe I read about it during a dis…
Re: Sunsetting Tor Messenger
#63Earlier quoted context omitted.
I believe there is a Usenet newsgroup, somewhere under alt.binaries, that's effectively a numbers station: it's just GPG-encrypted (but not signed) blobs with no titles. Anyone can post, anyone can listen, everyone has to download everything to figure out which things they can personally decrypt. Sadly, googling related keywords doesn't seem to pull up the name of the newsgroup. I believe I read about it during a dis…
I think you're thinking of Mixmaster: http://mixmaster.sourceforge.net/faq.shtml
Re: Sunsetting Tor Messenger
#64I find Tox[1] to be a reasonable messenger. [1] https://tox.chat/
Read that: https://github.com/TokTok/c-toxcore/issues/426 Note: The interesting part is not the vulnerability itself, that is relatively minor. The interesting part is where the tox developers explain that they don't really understand their code.
"You are fucked if you get your key stolen. There are so many more fun things you can do if you steal someones key that I simply didn't bother trying to handle that case because it would not provide any actual security."
This seems like a pretty flippant attitude in a thread where other collaborators have already built anticipation for your response. I suppose it's possible irungentoo noticed this flaw and explicitly thought "this is outside of the scope of our security model, so I'll just leave that in there by design," but it seems much more likely that they hadn't considered it at all and are simply rationalizing after the fact. After all, if you recognize the negative security implications of a specific design decision and choose not to address it you are not really writing "secure" software. I think "I didn't consider what might happen if a secret becomes compromised" is obviously a bad look for security software.
Re: Sunsetting Tor Messenger
#65We are building https://www.stealthy.im , decentralized, encrypted messaging with WebRTC. Would love your thoughts & feedback on how we could better meet your needs!
What is your thought on WebRTC exposing user IP addresses? https://www.ovpn.com/en/blog/webrtc-might-expose-your-ip-add...
Re: Sunsetting Tor Messenger
#66I think about trying to hide the metadata of who is communicating... I wonder about a public stream of end-to-end encrypted messages. Anyone can add a message to the stream. Everyone reads all of the messages, and tries to decrypt all of them. There are lots of variants to this, lots of ways to optimize it, probably lots of ways to implement it. But that's the core idea. One variant is that what everyone downloads is…
That sounds a lot like BitMessage. https://bitmessage.org/bitmessage.pdf
Re: Sunsetting Tor Messenger
#67I think about trying to hide the metadata of who is communicating... I wonder about a public stream of end-to-end encrypted messages. Anyone can add a message to the stream. Everyone reads all of the messages, and tries to decrypt all of them. There are lots of variants to this, lots of ways to optimize it, probably lots of ways to implement it. But that's the core idea. One variant is that what everyone downloads is…
The basic idea is to split a message into very small pieces, say individual bytes or even bits. And the sign each bit, and iirc add a sequence number. Then you end up with a triple: sequence number, data, signature. Then you generate random triplets - and distribute the lot: the recipient orders by sequence number and keeps the bits with valid signatures.
I'm not sure about how ordering was achieved, but it was a clever idea.
Ah, here's Wired's coverage of the Ronald Rivest's idea in 98:
https://www.wired.com/1998/03/a-work-around-for-crypto-expor...
Re: Sunsetting Tor Messenger
#68Retroshare now provides a Tor version: https://retroshareteam.wordpress.com/2018/03/13/release-note... > Running Retroshare over Tor has a number of definite advantages: it does not require firewall management (Tor does it for you); you do not need a DHT to find your friends (Tor does it for you), and whatever code is tied to ensuring security of your IP information is not needed anymore.
Is this some new feature of the protocol/network?
Re: Sunsetting Tor Messenger
#69I think about trying to hide the metadata of who is communicating... I wonder about a public stream of end-to-end encrypted messages. Anyone can add a message to the stream. Everyone reads all of the messages, and tries to decrypt all of them. There are lots of variants to this, lots of ways to optimize it, probably lots of ways to implement it. But that's the core idea. One variant is that what everyone downloads is…
Re: Sunsetting Tor Messenger
#70Earlier quoted context omitted.
I have been looking for info on why tor over tor is bad and would love to understand the technical reason why, can you share any links? All I have been able to find is related to uncertainty is it is good or not
This link discusses it: https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWT... The issue mentioned of reusing nodes doesn't seem like much of a concern considering how the onion routing works (even if the routes are all the same nodes). But the performance alone is probably terrible.
>It is not clear if this is safe. It has never been discussed.
why not discuss it now?