plausible deniability feature - OMEMO End-to-End Encryption (OTR, Double Ratchet Algorithm, ...)

[adrelanos]

https://conversations.im/omemo/ (for example implemented in gajim-omemo) would provide plausible deniability (similar to OTR). It would also provider stronger encryption and verifiability then the current implementation of Tor onion services.

[adrelanos]

OMEMO is just a synonym to get plausible deniability and extra encryption besides the transport layer. No need to be adamant about OMEMO. OTR would be an alternative, if it supported file transfer, which it does not. Perhaps Double Ratchet Algorithm (which Signal and unMessage are using) or some other (perhaps better suited) algorithm could reach the same goal.

[micahflee]

The problem with providing an extra layer of encryption is that the client is Tor Browser, not another OnionShare. If we wanted to add OMEMO or OTR on top of OnionShare, we'd have to either require people to use OnionShare in a different mode to connect to it, or add stuff into Tor Browser so it can understand.

Of course, a much simpler way of including an extra, much stronger layer of encryption would be to use HTTPS. Tor Browser understands HTTPS already. Since OnionShare is basically sending a single message -- downloading a zip file -- there's no need for ratcheting or anything like that.

Each time you start the server, OnionShare could generate a new key and self-signed certificate, and use a strong ciphersuite. The only problem is that it will throw a certificate warning that the user must click through, which is why I haven't implemented this in the past already. Although, I'd be into including HTTPS as a setting that's disabled by default. I'd use it.

About plausible deniability: I'm curious what type of scenarios you have in mind. OnionShare might already have this property. It uses ephemeral onion keys that are one-time-use and only in memory until you stop the server. (Of course, the fingerprint of this key is in the URL, and maybe you shared the URL in a way that's not deniable, like in a PGP-signed email.)

[adrelanos]

Micah Lee:

The problem with providing an extra layer of encryption is that the client is Tor Browser, not another OnionShare. If we wanted to add OMEMO or OTR on top of OnionShare, we'd have to either require people to use OnionShare in a different mode to connect to it, or add stuff into Tor Browser so it can understand.

That both sounds nice.

About plausible deniability: I'm curious what type of scenarios you have in mind.

None particularly. Just best practices.

[micahflee]

I don't think OnionShare needs a new plausible deniability feature, since it already is ephemeral and doesn't leave traces of what you shared, or your onion key, or anything like that on your computer after use.

But I do like the idea of supporting HTTPS, so I just opened an issue for that #479.