just trying lemmy

  • 2 Posts
  • 31 Comments
Joined 2 years ago
cake
Cake day: June 3rd, 2023

help-circle




  • 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.







  • Interesting :)

    A few quick questions & comments:

    1. 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?

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

    3. 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?

    4. What about nonces for GCM? How do you prevent replay attacks?

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








  • Green flags:

    • copyleft license (GPL or better AGPL) + they accept contributions without contributor license agreement
    • code written by many people who personally own the copyright
    • active community

    Yellow flags:

    • permissive license
    • business model which can’t be really be sustainable with a shit-free product

    Red flags:

    • VC funding (implies enshittification in future because of profit maximization)
    • proprietary license
    • project does not take contribution from the outside or asks to transfer copyright or sign some document (CLA)