Feature request, Add a optional encrypted AES-256 cipher text ability

There is a growing need for communications applications to provide a optional layer of encryption capability to their text messages. Any system that is capable and able to connect to the internet already has the openssl library files installed which can be also used to encrypt and decrypt AES-256 text messages without needing to add those external utilities.

Merely use the systems already installed openssl binary in optional calls to decrypt a message to a users text string locally on the receivers and senders systems, any intercepts in the Tor network would only show a AES-256 encrypted text.

Tor hidden services are already end to end encrypted. This is what DarkMX uses. Any additional encryption on top of it would be unnecessary. If DarkMX didn't use Tor hidden services and instead connected to servers on the internet then encryption would be needed.

Here's a simplified example.

End to end encrypted
DarkMX User 1 -> Relay1 -> Relay2 -> Relay3 -> <- Relay4 <- Relay5 <- Relay6 <- DarkMX User 2

May or may not be encrypted
Tor Browser -> Relay1 -> Relay2 -> ExitRelay -> www.example.com

In this second example, the Tor exit relay can see your traffic unless you use encryption which most websites these days do.

There's multiple lapses with Tor that users had depended on against State sponsored attackers and came up short. Bad States setting up hundreds of their own Tor guard servers, Tor exit servers like I have seen Israel do to trick users into thinking those are just normal tor servers forming part of their tor network. Meanwhile they try and discern who, what, where users are located and who they are connected to tor are.

Off the record is a fast AES-128 keyed encryption that is often optionally used in chat rooms, and messages regardless if its over the tor network or not.

More information https://profanity-im.github.io/guide/0100/otr.html

You can examine the traffic coming out of darkmx if you use an external client and spy on the connection to the local socks proxy.

It's well encrypted.  Why wouldn't it be?  Not like it's hard to do.

Since everyone has a ed25519 public key, there's probably a diffie-hellman key exchange followed by a signature over the shared connection key, which can then be fed into one of many stream ciphers.

But, for the record, Tor already does exactly this in the protocol, so it is redundant and completely unneeded for any apps to do another layer above.  Connections between hidden services already are secured by the hidden service's public key which is used for e2e and to guarantee mitm can't happen.  The only compromises in Tor have been due to timing attacks to reveal location, and this isn't related to the topic at hand.

I discovered multiple pushed Tor relays were situated inside Israel, far too many to not be a State Sponsored Man in the Middle Tor Server Attackers. I began noticing time and again relays in Israel was coming up in the chain of completed chain of Tor relay servers. Deciding that was highly unlikely to be a coincidence from such a tiny Apartheid State I wisely added a ban on all Israeli IP linked Tor Servers.

Generally those that complain the loudest about no need for additional layers of strong encryption are working for the wrong and generally seen as very bad people. Hasbara, Mockingbird troops, MI6, and of course those alphabet soup cubical folks.