Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ASmith- opened this issue Aug 16, 2022 · 5 comments
Open
Labels
enhancement New feature or request

Comments

@ASmith-
Copy link

ASmith- commented Aug 16, 2022

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
Copy link

odiferousmint commented Oct 30, 2022

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
Copy link

sneak commented Jan 3, 2023

What is the threat model here?

@morganava
Copy link
Collaborator

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.

@morganava morganava added the enhancement New feature or request label Oct 15, 2023
@webdingspowah
Copy link

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-
Copy link
Author

ASmith- commented Jul 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants