OnionShare 2 adds anonymous dropboxes

I wonder if you could use this to make an OnionSync. Like Syncthing but perhaps simpler to use because of global addressing and no need to configure between nodes. (Though I've only briefly looked at Syncthing.

Is there any kind of standard that 'defines' what a plausibly deniable format is?

You are probably talking about detecting Tor relay nodes IP addresses that the sender connects to or patterns in the traffic.

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.

Isn't that exactly the problem Tor's pluggable transports are designed to solve?

TCP often fails to saturate network links because it treats packet loss as congestion. TCP-BBR tries to model the network more accurately, treating latency as congestion: https://cloud.google.com/blog/products/gcp/tcp-bbr-congestio...

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.

Is there any way to use it without it being painfully slow?

For what it's worth, there is some degree of password protection: the OnionShare links include a slug that must be included in order for files to be shared. Quoting the article,

> 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.

> I'd like to see some simple one-time-use password option.

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.

This is no more "security through obscurity" than say Amazon S3 signed URLs or SSH keys. They are long enough that your odds of guessing it correctly are way small. Is it possible? Sure, but so would be guessing somebody's SSH private key.

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.

I wonder if scrambled distributed chunks over torrent would be useful.

Btw who works on tor replacement or improvement ?

Just to clarify, HTTPS would not be of any use if the sole verification you make is technical (eg like letsencrypt which verifies that you indeed control the endpoint, vs say <commercial CA> that may verify IRL that you are the social entity you say you are). tldr: if you trust the onion address to be correct, the connection is already end-to-end encrypted to the only person that generated and thus controls the endpoint.

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).

From a security perspective, if I give a person a know https url and a password, it is indistinguishable from a know https url with the password appended in the path. There is even a standard where you can write https://username:password@example.com/

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.

Onions broadcast themselves to the directory to they can be accessed

This is not metadata analysis resistant, so Mozilla could still technically see who is sending files to who (unless you use Firefox Send in Tor Browser - not sure how well that works).

That's not to say this service isn't useful, but it's not a drop-in alternative to OnionShare.

I think it's actually more similar to magic-wormhole, https://github.com/warner/magic-wormhole

Firefox is apparently working towards integrating Tor into a private browsing mode type of thing, so perhaps someday soon that won't be necessary [0].

[0] https://news.ycombinator.com/item?id=17205441

Keybase is basically a communication platform that's secure, but allows the users to verify that they are who they say they are. It's basically like "I am foo, and I identify myself like this, and you are bar, and you identify yourself like that, we now know that we are who we say we are, and now we're having an e2e encrypted conversation.

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.

The domain is the author's name (see the sidebar on the right).

Most people will not see the logical conclusion of this whole ordeal and will think you are merely being pessimistic.

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.

To name a few professional that need to talk work with each others: journalists, lawyers, medical personal, security, and government. If just a small amount of the sensitive information that get transported through data brokers like facebook and google get moved to more secure end-to-end then I see a major win for projects like this. Take for example a psychologist seeking a second opinion on a recorded video of a patient, which as I understand is a rather standard practice. If I was the patient then I wish they used tools like this rather than a password protected google drive, which for practical reasons I assume many non-technical psychologist use.

Uh, what?

What you describe doesn't sound remotely feasible...

You can't do that because that's not the way encryption works.

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.