Do you use Signal for chatting securely with friends and loved ones? Us too! We endorse it wholeheartedly, and rely on it for nearly all our communication.

But the vibes are deteriorating here in the US, and we should have a communications contingency plan for if Signal goes down.

  • N.E.P.T.R@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    2
    ·
    11 minutes ago

    OpenPGP for encryption through autocrypt is a BIG NO for me. OpenPGP is inherently flawed, read any reasonable cryptographer’s opinions on it. DeltaChat is a significant security downgrade from Signal. I would much rather use SimpleX or Briar.

  • Calmarius@lemmy.ml
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 hour ago

    You can move to any other service, but once it becomes popular enough to draw attention they might also get blocked as well. If it’s centralized, then the central servers can be blocked and it’s not longer working. If it’s decentralized and peer to peer, then the bootstrap nodes can be blocked and it’s no longer working.

    Even if it’s self hosted and not advertised, the adversary can run active probes to detect banned services and block it if it detects any.

    The only thing that can work reliably is something that can be concealed and can’t easily be detected.

    A simple HTTPS website that runs a small blog, forum or an image board, can have a lot of bot traffic, and human traffic that makes the traffic analysis hard, it also provides plausible deniability if someone asks why you visit that site often, you can say that you are playing games or browse images there. Such website can have a secret interface that can be used as an interaction point for secure chatting (in a store and forward manner), which responds only if the requests are cryptographically signed by the participants, otherwise the server can play dumb and show a 404 error. Therefore an active prober can’t easily detect that the website hosts that interface the first place, because they cannot produce a signed request unless they manage to compromise one of the participants.

    Threat analysis:

    • Obviously if the endpoints are compromised, all bets are off.
    • The certificate authority (CA) that issued the certificate for the website can be compelled to issue certificates for man-in-the-middle (MITM) observation and then the MITM-er can detect the secret interface. But nowadays this is difficult to pull off due to certificate transparency (CT), TLS clients can be configured to not accept the cert if it’s not logged by a CT provider, and domain owners can get an immediate alert if someone else issues a fraudulent and logged cert for their domains.

    Someone should make an app that works this way. Only one tech savvy person of the given group need to set this up (preferably someone who alredy have a website), then others in the group can be invited into it and can use it without much friction.

  • artyom@piefed.social
    link
    fedilink
    English
    arrow-up
    10
    ·
    4 hours ago

    If you’re in a country that is shutting down servers, then your contingency plan should involve serverless p2p apps like Quiet or Keet.

  • Cyberflunk@lemmy.world
    link
    fedilink
    arrow-up
    15
    ·
    edit-2
    2 hours ago

    ~~ i wouldn’t follow this advice threema is swiss based, requires no account, e2e, etc. simplex had a newer stack, i’m not sure about its bonafides briar is tor based and has a bt backup deltachat will leak metadata everywhere, and encryption is opportunistic, not default ~~

    Edit: I am clearly full of shit, and I apologize.

    Also - strikeout doesn’t work

      • Cyberflunk@lemmy.world
        link
        fedilink
        arrow-up
        11
        ·
        6 hours ago

        oh fuck…

        uh… nevermind?

        Threema has  been through two private equity acquisitions now. In 2020, the original cofounders sold to AFINUM (German PE firm) but retained leadership and a significant share. Then the founders left the company entirely in 2024. Just announced in January 2026: Comitis Capital (Hamburg-based PE) is acquiring Threema from AFINUM. The deal is expected to close this month.  This is what’s called a secondary buyout - one PE firm flipping to another. The concerning pattern: ∙ 2020: Founders sell majority to AFINUM ∙ 2024: Founders exit completely ∙ 2026: Flipped to another PE firm Threema claims “our core values, corporate mission, and management remain unchanged”  - which is the standard line in these acquisitions. They emphasize that technical infrastructure and data centers will remain in Switzerland , but the company is now fully owned by German investors with zero founder involvement. Why this matters: PE firms optimize for exit value. Two buyouts in 5 years with founders completely out suggests the product is now a financial asset, not a mission-driven project. Compare to Signal, which is a 501©(3) nonprofit. One commenter on the news put it bluntly: “I so liked this product… simpleX is now the only clean option in the market.”  If you want something without VC/PE ownership risk, SimpleX and Session are both structurally different - Session is backed by a foundation, SimpleX is open source with a different funding model. Delta Chat also dodges this since there’s no company to acquire.​​​​​​​​​​​​​​​​

        • HumbleExaggeration@feddit.org
          link
          fedilink
          arrow-up
          3
          ·
          3 hours ago

          How well does matrix hold up in comparison to Session or SimpleX? Maybe i have been living under a rock, but i did not hear much about them.

      • Cyberflunk@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        5 hours ago

        https://eprint.iacr.org/2024/918.pdf

        Header Metadata Analysis from ETH Zurich Paper Header Classification System (Section 4.2) The paper describes Delta Chat’s four-tier header classification: Delta Chat internally categorises headers into four types: ∙ Unprotected: these headers must appear as IMF headers, e.g. Date and Chat-Version ∙ Hidden: these headers can be large and therefore must not appear as IMF headers, e.g. Chat-User-Avatar ∙ Protected: these headers are encrypted whenever the message is encrypted, e.g. Chat-Group-Name ∙ Secured: these headers should only be present in the signed and encrypted payload. The Chat-Verified and Secure-Join-Fingerprint headers are explicitly marked as secured. In addition, Delta Chat treats the Autocrypt-Gossip header as secured. The Core Vulnerability The e-mail parser removes or ignores secured headers that appear in the unencrypted part. However, perhaps counter-intuitively, a protected header can appear as an unencrypted IMF header even if the e-mail is signed and encrypted. This design choice is necessary for headers like Subject and From, which are generally required for well-formed e-mails, but is incorrect for other protected headers, such as Chat-Group-Member-Removed, which should only appear in the possibly encrypted e-mail body. Header Overwriting Issues The situation is more complicated when the same protected header appears in both encrypted and unencrypted parts. Delta Chat parses the unencrypted headers before the encrypted headers, preferring a new header over an already parsed one if the header is considered as “known” or starts with Chat-. Therefore, the encrypted header generally takes precedence over the unencrypted header. However, because of several oversights in Delta Chat’s e-mail parser implementation, there are cases where the unencrypted header could overwrite the encrypted header, including Secure-Join, Secure-Join-Auth and Secure-Join-Group, which are not included in the list of known headers. Moreover, Secure-Join-Auth should have been treated as secured instead of protected, as it never appears unencrypted in honest executions. Message-ID and From Header Vulnerabilities In addition, the Message-ID header and the From header are in effect susceptible to overwriting. The Message-ID header, while not susceptible to overwriting per se, can be overwritten by the unprotected X-Microsoft-Original-Message-ID header, which was used in older versions of Delta Chat and remains for compatibility. For the From header, Delta Chat decided not to reject an e-mail whose encrypted From header is different from its unencrypted From header. Table 1: Vulnerable Headers

        Header Type Overwriting
        Chat-Group-Avatar hidden no
        Chat-Group-Member-Removed protected no
        From protected yes
        Message-ID protected yes
        Secure-Join protected yes
        Secure-Join-Auth protected yes

        Metadata Leakage in Group IDs (Section 4.2) An eavesdropping attacker can easily distinguish Autocrypt traffic by checking the Autocrypt header. The attacker can also distinguish messages from different groups, since the group ID is a part of the plaintext Message-ID header. Privacy Attack via Key Tainting (Appendix E) An attacker that can only observe and modify partial network traffic, e.g. a malicious e-mail server, may “taint” Autocrypt keys in order to learn more about the social graph of the target. The attacker can do this by adding unhashed subpackets to OpenPGP keys in Autocrypt headers found in network messages, which is possible since these fields are not protected by signatures nor contribute to the key fingerprint. Mitigations Applied in v1.44 From the Delta Chat blog post on the fixes: Starting with version v1.44 Delta Chat extends protection to several important headers: ∙ Delta Chat now protects the From header ∙ Reduced metadata by not including the chat group ID into the Message-ID ∙ The Chat-Group-ID is now contained in the encrypted part of a message Recommended Fix from Researchers An immediate fix to the attack would disallow headers starting with Chat- to appear in the unencrypted part if the message is encrypted. However, it takes more careful checks to completely eliminate such attacks. In general, if a protected header appears in the plaintext part of an encrypted message, then Delta Chat should regard the message as invalid.​​​​​​​​​​​​​​​​

  • Blip6338@lemmy.ca
    link
    fedilink
    arrow-up
    7
    ·
    7 hours ago

    The reticulum project with the Sideband client is probably a lot more censorship resistant than DeltaChat or Meshtastic.

  • Señor Mono@feddit.org
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    7 hours ago

    If the vibes keep on deteriorating and there would be a crackdown on messengers and signaling infrastructure a messenger is the last of your worries.

    And if Signal gets specifically targeted, there will be warning signs and time to shift away.

      • Señor Mono@feddit.org
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        12 minutes ago

        Nope. That’s not how Signal and E2E encrypted messaging works.

        If a government asks Signal for user data they get an almost empty sheet of paper. Search for " what data does signal collect" to confirm that.

        If - on the other side - your smartphone is compromised or unlocked there is almost nothing Signal can do to prevent governments from looking into your data. Also it reads like some agents simply joined a group chat. Again: nothing Signal could prevent.