Sunsetting Tor Messenger(blog.torproject.org) |
Sunsetting Tor Messenger(blog.torproject.org) |
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 just enough of a message metadata identifier to see if they're the intended recipient (something about Bloom Filters or PGP Signatures or something, I dunno). Then, if you are the intended recipient, you request the message contents itself. To obscure which messages were for you, you also download some very large number of other messages.
Something about microtransaction fees to pay for all of it. Maybe something about distributed ledger. Mumble, mumble. Maybe messages only live for X days or something.
Thoughts?
Sadly, googling related keywords doesn't seem to pull up the name of the newsgroup. I believe I read about it during a discussion on a Tor onion-site forum, on "why people keep getting caught doing illegal things on Tor, and what real OPSEC looks like."
Would this not defeat the purpose? Once an individual was tied to a unique piece of data, they'd be tied to all data in the stream.
I think such a system would definitely require guaranteed expiration (impossible?). Or some sort of rotating keys or the metadata piece would still be uniquely identifying.
I like this idea, as a concept, but I have no idea how it would actually work in real life with bad actors who can and would download all messages as they appear.
I wonder if there's some way to enforce expiration?
For the "tied to a unique piece of data," that's why I want Bob to download lots of messages, hiding the fact that the person at 14.85.101.86 is the user with the recipient ID of ntULzh2AeEgPH9bKxrn3gUL. Bob should also be rotating his IDs all the time. Maybe they're single-use. And if Bob wants Alice to be able to send him messages, then he (out of band) has to give her a huge list of IDs he'll be watching for, in sequence. If they arrive out of sequence, he knows to be supremely suspicious. Also, yes, I recognize that key management is THE PROBLEM. And I'm essentially inventing dead drops. But in my defense, I'm trying to come up with a way to make it easy for a lot of people to use, thus making it easier for everyone to hide in plain sight.
For the "guaranteed expiration," I am actively assuming bad actors would download and archive all messages. I only propose a limited number of days to lessen the storage costs.
For the rotating keys, as I understand it, there's Perfect Forward Secrecy, but it's very chatty (think of it as "online"). There's also a weaker form of Perfect Forward Secrecy (think of it as "offline"), but the risk is that if the communication if broken at any moment, then you can't recover from within that channel - meaning you'd need to go back to the person out of band, and restore communication. I'm probably summarizing it very poorly, but my mental model for it is roughly, at the end of every message I send you, I tell you what new password I will use when I send you the next message. It's actually way smarter than that, as I understand it, but that gives me enough of a mental model to work with it as a lay person.
You could make the database so noisy that there's a proof-of-storage cost on anything over a day old.
No guarantee, but something.
Adversaries would want to store only those messages of interest, but that would require breaking the oblivious transfer system.
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...
(This is patented, or at least pending)
TAILS users can't use it because tor-over-tor is weird (ricochet uses its own tor process). but it looks like it's getting close.[2]
> 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?
https://via.hypothes.is/https://blog.torproject.org/sunsetti...
https://web.archive.org/web/https://blog.torproject.org/suns...
> Bonus points for installing and running Tor without elevated privileges.
Try https://github.com/TheTorProject/GetTorBrowser then use meek-amazon as a pluggable transport to get it working if your network censors Tor traffic.
You certainly should not need elevated privileges for Tor Browser but I realize that accessing their download site in the first place is the issue. I'd post a magnet link but doubt that follows the rules here.
Though occasionally everything slows down and you have to run a query to cleanup (https://github.com/matrix-org/synapse/issues/1760#issuecomme...)
That won't be enough for the average Tor Messenger user. Email's failings were the impetus behind both instant messaging and Tor. Users don't want/need federated models. Security aside, they want a convenient little app that will receive messages instantly while online but doesn't have to remain online 24/7.
Even more interestingly the EFF has stopped trying to recommend the best one and instead is encouraging the users to do their own reasearch (even redirects old urls[2])
If I'm trying to talk to someone anonymously, having to give them my phone number somewhat defeats that anonymity. Even having it installed is potentially dangerous; it scans your phone book and suggests other signal users (thereby outing you as a user in the first place).
My threat model includes:
- kids in my house
- Facebook selling my data to insurance companies
- future employers googling me
- etc
It does not include:
- NSA
- local police (in 2018)
I'll still try to give away as little as possible as while I trust local authorities now I've no reason to be sure I can trust them in 5, 10 or 20 years (see Turkey).
In my case Signal seems reasonable for some things and for now.
Personally I'm also annoying all crypto experts here by using Telegram for some communication and I might even use postcards for other communication (and there might even be communication channels I use but never talk about).
I realise this doesn't solve your issue with having to share your phone number with them, or people with your number seeing you use Signal, but if you want anon communication XMPP+OTR+burner accounts is still the way to go, AFAIK.
Would love your thoughts & feedback on how we could better meet your needs!
https://www.ovpn.com/en/blog/webrtc-might-expose-your-ip-add...
As far as I can see currently the only widely used, secure protocols are Matrix and XMPP with OMEMO.
The Github page has one: https://github.com/ricochet-im/ricochet/
> As far as I can see currently the only widely used, secure protocols are Matrix and XMPP with OMEMO.
secure != metadata free
That doesn't look very promising.
Please see this comment by Sarah, https://github.com/ricochet-im/ricochet/issues/555#issuecomm...
```
Hi, I don't speak for @special, but I think some context might be useful.
There is currently a bunch of (official|unofficial) work going on in the wider ecosystem - most of it related to factoring out the base library[1] to go to make it more useful as well as porting the main client to go[2].
There are also a few experiments regarding running on mobile[3] and using ricochet and these other libraries for other things besides traditional IM[4].
Most of this wider work has been updated within the last couple of weeks, ricochet is still actively being worked on & used - just not in the most visible places right now.
Some of the features you have pointed to are sitting waiting for someone to come along and design/write them. For most there is a lot of UX work that needs to be done in order for these features (layered crypto, hidden service auth, multiple profiles etc.) to be secure & useable.
In many cases, adding them to the new Go code might be preferable in terms of ease of implementation. That is partly why work is being put into the libraries there, to make new changes to ricochet as easy and as useful as possible. These libraries are also in development right now, and it may take a little while before everything comes together.
So the best thing people can do right now if they want to move these things along is to contribute to the discussions on the feature threads if they have ideas about how those features could work & to submit code/pull requests to the various code bases.
```
All I have been able to find is related to uncertainty is it is good or not
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.
I have much better experience with Matrix[1]/Riot[2].
Matrix is an open protocol with end-to-end encryption (still beta IIRC) and is federated (like IRC) rather than fully distributed.
Matrix is now a stable project with funding and riot has a future business plan to also continue develop.
https://github.com/irungentoo/toxcore/issues/1379
Also:
https://blog.tox.im/2016/04/01/litigation/
I rather support KeyBase or Wire (Open Source back-end exists and I think the clients are open source too!) as an alternative. I'm leaning cleanly toward Wire, though everyone I've suggested KeyBase to enjoys it. I like the free storage of KeyBase... sue me.
Edit:
Wire Github: https://github.com/wireapp
i hoping for a fix soon.
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.
I wonder if there's a cryptographically secure way to build a known "stream" of one-use tokens (addresses, if you will) based on known "public key." For metadata security, you only hand that public key out to those you trust.
Another thought is the ability to attempt decoding of every message (as you already alluded to). Encode some well-known bytes at the beginning of every message and see if your key can decode and match them. I'm not certain that protects against metadata snooping, since I don't understand the cryptography enough to know if that well-known text would always be the same for a target private key.
This is what Bitcoin's BIP-47[1] does, but you can hand that "public key" to anyone[2]. The communication layer in this case is the Bitcoin blockchain.
[1] https://github.com/bitcoin/bips/blob/master/bip-0047.mediawi...
>It is not clear if this is safe. It has never been discussed.
why not discuss it now?
The download is a zip file that can be extracted and run anywhere without installation.
Include the word 'linux' or 'osx' in the body of the message to get a binary for those platforms.
Nothing good can come from this.
Your employer will not applaud you for this.
You could end up getting fired or worse.