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

[ASmith-]

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 what is already there in calls to encrypt and decrypt the text string.

[odiferousmint]

Might as well add OTRv4 (or version 3 at the very least), similar to XMPP's XEP-0364: Current Off-the-Record Messaging Usage or something similar to XEP-0384: OMEMO Encryption! The latter does require AES-256-CBC with HMAC-SHA-256.

Regardless, I believe it is a good idea to add an optional layer of encryption (and more) that sits on top of Tor, if there currently one does not exist.

[sneak]

What is the threat model here?

[morganava]

What is the threat model here?

So in theory this would (help) mitigate any kind of machine-in-the-middle style attack affecting connecting to onion services. For instance if a malicious relay was logging traffic for eventual future decryption, then the plain-text (within the layered tor encryption) ricochet-refresh protocol would be trivial to decode and expose user messages if tor's encryption were ever broken in the future.

[webdingspowah]

Leaving debate about the possible utility or unnecessary redundancy of this aside, OTR lacks active development and the last version (3) is significantly out of date by current standards and has numerous limitations. If something like this were to be added, the most reasonable option would likely be MLS. Its feature set is rich enough to work well with what the new Gosling protocol and future versions of Ricochet could possibly allow. https://github.com/openmls/openmls https://github.com/awslabs/mls-rs https://github.com/cisco/mlspp

If unnecessary redundancy is a concern, liboqs wouldn't be redundant and would likely provide Ricochet with a unique feature set at the time of writing. It, however, is not a protocol implementation. https://github.com/open-quantum-safe/liboqs

It's worth noting that future versions of MLS and Tor may contain algorithms like those offered in liboqs.

[ASmith-]

Its a given the vast majority using ricochet refresh have ssl installed which has several strong crypto cipher suites built-in. Its a single line of code to encrypt and one line of code to decrypt using those cipher suites.