Request for comments on a encrypted messaging protocol I'm developing

Design protocol by Givlucas · Pull Request #8 · MariposaOrg/mariposa

Hey everyone! I'm looking for some comments / discussion on a peer to peer encrypted messaging protocol I'm developing called Mariposa.

It functions on top of TOR, using hidden services to hole punch through firewalls and to provide anonymity.

3 comments

Interesting :)
A few quick questions & comments:
I don't quite understand "If all users accept the introduction, a list of contacts is sent for each contact pair. These contacts are not used for messaging to prevent more than two parties from having encryption keys." (line 66) What exactly are the "contacts"? Is it the same data as defined on line 8? Where do the encryption keys come from? Do initiators of introduction reveal encryption keys of their existing contacts?
After an introduction there's the problem that newly introduced people cannot setup secret keys in a very clean way. Because this secret keys can be computed if an attacker gets hold of the introducer, has recorded traffic and is in possession of a large enough quantum computer (which you assume in your threat model). You therefore would need some sort of 'upgrade' mechanism which would allow either two people to meet in person to 'upgrade' their secure channel. Or you could add a asymmetric key-agreement or key-exchange on top (probably post-quantum algorithm).
I don't quite get the combination of "HTTPS", "Tor", "symmetric crypto because of quantum computers". Why HTTPS if Tor already provides confidentiality? HTTPS implies certificates, no? What about them?
What about nonces for GCM? How do you prevent replay attacks?
If you want to truly understand your protocol and get confident about it, I recommend studying something like this: https://tamarin-prover.com/ This allows you to model your protocol more formally, state your security claims and check if the protocol satisfies this claims :)
- Hey! Thanks for taking a look! The contacts shared by the initiator were intended to be generated randomly. I completely missed how a captured or malice initiator could impact other users. I suppose I figured it would be unlikely an adversary would be able to get a initiators keys and capture the correct traffic on the TOR network to decrypt the other users after they generate a fresh set of keys
  The combination of TOR and HTTPS encryption is mostly just a bonus to slow down attackers rather then a real security mechanism. As for the HTTPS cets, I assumed the ones passed by the server could be trusted by default since it wasn't for security, and all incoming data would be encrypted.
  The reason I'm focusing on symmetric encryption as the only security mechanism is due to its particular resistance against quantum attacks. From what I could tell, even post quantum encryption schemes, have the possibility of being cracked in the future.
  I might do away with introduction entirely if I cant find a good way to pass they keys without relying on asymmetric keys.
  I really appreciate the review, a second set of eyes is always invaluable. Ill check out Tamarin as well :).
  
  Maybe you could also consider to extend an existing good PQC protocol (for example https://signal.org/docs/specifications/pqxdh/) by adding a shared secret. The shared secret could flow into the key derivation functions which are used to derive the symmetric encryption keys. This way you would have quite strong guarantees (forward secrecy) as long as nobody can break the PQC algorithm and still some guarantee of confidentiality when somebody breaks asymmetric primitives. In the protocol you outlined now, there's no forward secrecy. Meaning that once a key is compromised, all past and future messages can be decrypted.