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.

  • lucas_givens@lemmy.worldOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    29 days ago

    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 :).

    • teri@discuss.tchncs.de
      link
      fedilink
      arrow-up
      2
      ·
      28 days ago

      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.

      • lucas_givens@lemmy.worldOP
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 days ago

        Forward secrecy only guarantees that past communications are secure right? I couldn’t find anything on protecting future sessions

        • teri@discuss.tchncs.de
          link
          fedilink
          arrow-up
          1
          ·
          2 days ago

          Honestly I’m not sure what the definition says. But in case of the original axolotl/signal protocol the ‘ratchet’ construction in my understanding allows to recover from a key compromise given that the attacker is passive (read only). Let’s say you have to hand your phone to the police, they disappear with it for a moment and get a copy of all the keys you use for the axolotl protocol. As long as they don’t manage to manipulate network traffic but only intercept everything your chat session will ‘recover’ once a new (EC)DH agreement is completed with your chat partner. This might not happen immediately though in case your chat partner is offline.

          This property (securing future messages) can only be achieved with asymmetric cryptography. Securing past messages can in principle be achieved with symmetric cryptography: You could imagine a ratchet mechanism where each chat partner computes a new key by transforming the old key with a entropy-preserving and hard-to-invert function (such as sha3) and then deleting the old key (and also best deleting old messages).

          P.S. Just did some reading: https://signal.org/docs/specifications/doubleratchet/

          Forward security: Output keys from the past appear random to an adversary who learns the KDF key at some point in time.
          
          Break-in recovery: Future output keys appear random to an adversary who learns the KDF key at some point in time, provided that future inputs have added sufficient entropy.
          

          So what I meant is not called forward secrecy but break-in recovery. Confusing terms.