0 - https://stem.torproject.org/
1 - https://github.com/cretz/bine
Tor traffic is pretty visible and detectable. If you're firewalled somewhere, it's pretty obvious to anyone in the middle that you're using Tor. Tools like these clearly don't work against nation states like China, or even some corporate environments.
Transferring secrets in a plausibly deniable format is still a hard problem.
So you could use a VPN, or a chain of VPNs to hide the IP.
And to escape traffic analysis you could switch the entry VPN automatically (that would require quite a few VPNs for large files or many receivers).
Still, connecting to unknown IPs from a corporate network can be detected.
Then you could use some public service that stores data like Github (repos / gists / ...) and somehow communicate between your computer and a relay server through Github.
Still not foolproof, there could be timing attacks to detect when data is transmitted when the receiver requests the file, so introducing delays along the nodes would help.
Alice dumps an encrypted document into the NNTP network on one side of the world; Bob later downloads the entire newsgroup's contents (not just the stuff he wants—because there's no metadata to even determine that!) from his local NNTP server, and then attempts to decrypt everything he downloaded until he hits on something that works.
So, to get all the security features at the same time:
1. Using Tor to hide your IP,
2. Connect to a MixMaster node (using TLS), and
3. Send an encrypted NNTP message through it,
4. To an SMTP>NNTP gateway,
5. With the embedded NNTP message’s Recipient being alt.messages.anonymous.
Kinda complicated, but you could wrap all that up into a nice GUI program if you wanted.
Oh wait, they already did: http://aamdirect.sourceforge.net
MixMaster doesn’t do the Tor part for you, though. My suggestion would be to run AAM Direct in a https://tails.boum.org session, which will automatically force the connection through Tor without any configuration needed.
An additional boost to security would be for there to be .onion MixMaster nodes, so that the traffic doesn’t have to traverse the public internet (and thus probably force you to rely on the only-kind-of-secure SMTP STARTTLS extension for security between the Tor exit node and the MixMaster node.)
Of course, I suppose the design of TCP is part of this. It seems that there ought to be some more control of how aggressive it is about dropping connection rate. I keep hearing about multiplexed connections in newer protocols (QUIC etc.); would that translate into saturation of network connections?
Tor adds additional complexities, since intermediate nodes are even more likely to be congested than the average backbone router. I don't know if BBR improves things there.
I know Onion addresses are huge and the chance of someone scanning to upload is tiny, but I remember saying the same thing about IPv4. "There's 256^4 addresses, of course I can run an unsecured FTP. What could go wrong?"
I'd like to see some simple one-time-use password option. It doesn't even have to be enabled by default, just having it there would be a big step. HTTPS would be great, but I understand the difficulty of that hurdle.
(If Let's Encrypt is out there - .onion isn't a dirty word!)
This is why I suspect they emphasized sending the URL through a secure medium (since you are basically sharing a password):
> So long as you share the unguessable web address in a secure way (like pasting it in an encrypted messaging app), no one but you and the person you're sharing with can access your files.
And also why they feel comfortable describing the web address as "unguessable"
> I'd like to see some simple one-time-use password option.
That sounds like a nice feature, although I wonder how practical it would be. I often have to refresh web pages in Tor due to timeouts and stuff. If you burned your one time password and the connection timed out, you're SOL without the person running the server issuing you a new one. A good idea tho for people willing to make that usability tradeoff.
> By default, OnionShare addresses look http://[tor-address].onion/[slug], where the slug is two random words out of a list of words 7,776 words (technically, this is a 2-word diceware passphrase).
> The idea is that if an attacker could figure out the tor-address part of the address, they still can't download the files you're sharing, or upload files to your computer, without first knowing the slug. The slug is, essentially, a password.
Any distinguishable security property will have to come from elsewhere, such as the web server detecting a brute force scan and blocking the request. Tor can't do this so it has to rely on the address length alone, which now can be 56 characters of A-Z and numbers 2-7. I do not know how plausible it would be to scan the whole key space, but I suspect the tor project considered this when they increase the key size with version 3. In comparison scanning the whole IPv4 network takes around 45m for the zmap project.
Let's Encrypt developers have stated interest in .onion, see: https://community.letsencrypt.org/t/if-when-will-le-support-...
The additional considerations in regard to tor is that all traffic is already end-to-end encrypted with identity being served through the address. In regard to https there isn't much left, beyond enabling standards like http2 which explicitly require https and browser security features which are only enabled when visiting a https website.
I also agree with this. But I think the "delete once files are downloaded" kinda fulfills this. It does become insecure if someone else accesses it first, but then you know that someone else downloaded the data, right?
For the multiple sharing I think a password would be a really nice feature. You could have that done on the user side, but a good password implementation would be awesome.
Btw who works on tor replacement or improvement ?
I didn't look into onion addresses in some time so correct me if i'm wrong, but basically the address is a certificate: a locator and a key (both being the same thing but still). Links are authenticating by default, as if you bundled a letsencrypt certificate in the url. Some keywords to explore further: cjdns (same thing on osi level 3), capability-based security (tying an name [in the sense of URN] and a key), content-based addressing (can be seen as a variant when content is static, in tor the name points to a channel and not a blob so the content is the key).
Files are encrypted and then uploaded to Mozilla servers. Links automatically expire after some time.
That's not to say this service isn't useful, but it's not a drop-in alternative to OnionShare.
Solid selection by authors, not familiar with Keybase though
It's supposedly a way to put a stop to imitation, but unless adoption gets huge I'm not sure it'll work that way.
It generates a string, you store it on, for example, your twitter, facebook, github, HN account, almost anything with an editable profile. That way when 2 users are talking, one can be assured that the other is who they claim to be (either that or they have access to all of said person's accounts). It's kind of cool but it's impractical in a way that usage is pretty low (at least among people I know. Maybe it's got a big underground following I don't know about).
I have a keybase account and literally no one else I know does, so I've never used it.
If you want to look me up on Keybase I'm freedomben, and I'll be your friend :-)
Pandora's box cannot be shut. TOR and other projects will not be able to delete the information already gathered, backed up and parsed.
People are happy to tell everyone else what they ate, where they went, with whom and what they are thinking about at all times in exchange for nothing.
Society has made it clear that this erosion of privacy is a non issue.
ERROR - Value 'privacy' not found.
Sorry, the value you have chosen to uphold is no longer supported in the latest version of civilisation.
Please select another from the whitelist below.
Then someone wanting to access the hidden addy types that same private key in the url bar of a correspondingly twisted Tor Browser which would generate the hidden service pubkey and request the service at that addy.
Who wants to surf fwodjslkf...sdfjs.onion when you could be surfing amazon.onion?
It's also more democratic because if you don't like what you find there you can just publish your own amazon.onion.
The reason onion addresses are random looking is because they are a function of the hidden service's public key.
If you could generate a "private key" from the public key, anyone could use your "domain name". The reason tor doesn't require centralised domain name services is because we can trust that whoever owns the private key to the public key which we identify with the onion address, owns the onion address.
That's not what I wrote at all. I'm just talking about downgrading the onion addy generation to become a simple password authentication scheme. It's bad but no worse than logging into webmail without any 2FA.
If you really don't understand what I'm talking about I can put together a PoC. But it's extremely straightforward so I'd rather not if you can just re-read what I wrote and grok the idea.
0 - https://blog.asana.com/2011/09/6-sad-squid-snuggle-softly/
What you describe doesn't sound remotely feasible...
1. Set a hidden service private key to all zeros.
2. Derive the public key from that private key (plus whatever else you must do) to generate the corresponding onion address for that all-zeros private key.
3. Type that onion address into a Tor browser and see what you get back.
If what I just described is not even "remotely feasible," then one ought to be willing to type that addy into Tor browser running on their raw hardware and rest assured there is no possible way someone is running a (probably nefarious) service running at that address.
Are you willing to do that?
If not, what I'm talking about is just adding some leading, non-random, nonzero bits to that "all-zeros" private key.
It's not a secure design, but if all people want is to send files that are too big for email it's no worse than using password authentication to log in to, say, msn.com.