determine key features of anon msg system

runar-org / messenger

Cryptographic messaging platform that generates links to encrypted messages hiding privacy of sender, and recipient.

https://sendlab.app

GNU General Public License v2.0

8 stars 0 forks source link

determine key features of anon msg system #1

Closed kaburkett closed 4 years ago

kaburkett commented 6 years ago

Want to create a list of key features for this interesting project. @abaga129 @rocke97 @smithandrewl @Snepsts

kaburkett commented 6 years ago

Documentation repo can be found here: https://github.com/kaburkett/Runar-docs Project work card can be found here: https://github.com/kaburkett/Runar/projects/1#card-13233689

abaga129 commented 6 years ago

I would say a big thing to decide is if there will be a server involved or will it be peer to peer. If there is a server handling the messages and encryption then that puts a lot of responsibility on whoever is hosting the server and also means that the user is placing a lot of trust in the server owner.

kaburkett commented 6 years ago

@abaga129 I agree, server based is no good, I like the idea of blockchain... but I don't like the messages to live forever because I feel that a critical piece of the puzzle is expiration of messages. It's true that encryption protects content of the messages when the secret is hidden, but, there is an appeal to not needing to safeguard a secret key. Here's an image that explains it all

Snepsts commented 6 years ago

How will p2p connections be established? Do they trade ip and port numbers?

What protocol do we want to use to hand messages between connectees?

agunther97 commented 6 years ago

Not to reference the demon but WhatsApp has a end-to-end encryption flow that might be a decent idea starting point https://faq.whatsapp.com/en/android/28030015/

kaburkett commented 6 years ago

construction of a messaging platform that requires complete anonymity does rely on the premise that you know nothing about the recipient, only that you have a way of passing the link and password to them.. key difference should be

sender sets key to encrypt and decrypt message
after expiration window or after retrieving, message is removed from datastore
password/encryption key is NEVER stored ANYWHERE

I propose using the following for first iteration of this here message platform:

sqlite db - > generation script in runar-node repo
python api - > put in runar-node repo
react ui - > in this repo

kaburkett commented 6 years ago

Since we never store the key and encrypt everything on the front end based on the user key input, I believe it's safe to place trust in whomever runs the server/service. The only thing that needs to be ironed out is verifying the removal of messages when a node is ran by an untrusted party, but we can figure this out in a future version when people are interested in running their own nodes