• 7eter@feddit.de
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    7 months ago

    Signal stores your encryption key on their servers…

    That would surprise me. What’s your source for this?

      • ryannathans@aussie.zone
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        7 months ago

        master_key is never stored or sent to the SGX, only c2, the entropy bits. The user’s password is still required to generate the key.

      • LWD@lemm.ee
        link
        fedilink
        arrow-up
        3
        ·
        7 months ago

        So my takeaways from this link and other critiques has been:

        1.Signal doesn’t upload your messages anywhere, but things like your contacts (e.g. people you know the usernane/identifier, but not phone number of) can get backed up online

        One challenge has been that if we added support for something like usernames in Signal, those usernames wouldn’t get saved in your phone’s address book. Thus if you reinstalled Signal or got a new device, you would lose your entire social graph, because it’s not saved anywhere else.

        2. You can disable this backup and fully avert this issue. (You’ll lose registration lock if you do this.)

        3. Short PINs should be considered breakable, and if you’re on this subreddit you should probably use a relatively long password like BIP39 or some similar randomly assigned mnemonic.

        If an attacker is able to dump the memory space of a running Signal SGX enclave, they’ll be able to expose secret seed values as well as user password hashes. With those values in hand, attackers can run a basic offline dictionary attack to recover the user’s backup keys and passphrase. The difficulty of completing this attack depends entirely on the strength of a user’s password. If it’s a BIP39 phrase, you’ll be fine. If it’s a 4-digit PIN, as strongly encouraged by the UI of the Signal app, you will not be.

        4. SGX should probably also be considered breakable, although this does appear to be an effort to prevent data from leaking.

        The various attacks against SGX are many and varied, but largely have a common cause: SGX is designed to provide virtualized execution of programs on a complex general-purpose processor, and said processors have a lot of weird and unexplored behavior. If an attacker can get the processor to misbehave, this will in turn undermine the security of SGX.

        • jet@hackertalks.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          7 months ago

          One nit to pick, messages have to transit through the signal network. And they could be recorded during transit. Carnivore style

          • LWD@lemm.ee
            link
            fedilink
            arrow-up
            2
            ·
            7 months ago

            True, but that’s more or less out of the scope of this thread. I could go on for way longer about centralized versus federated services…