blueprint-freespeech / ricochet-refresh

Anonymous peer-to-peer instant messaging
https://www.ricochetrefresh.net
Other
157 stars 27 forks source link

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

Open ASmith- opened 1 year ago

ASmith- commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

What is the threat model here?

pospeselr commented 11 months ago

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.