1. 6
  1.  

  2. 11

    I’m not entirely sure if I follow what the threat model is here. “Failure of key rotation results in lack of non-repudiation of communications and indeterminate potential for impersonation and man-in-the-middle attacks” seems hyperbolic at best. It just transfers the key during a migration, which seems like copying your existing pgp key to a new computer. I don’t see the problem really, and it also seems like a good trade-off (constant “key has changed” notifications don’t exactly make things more secure).

    So unless I missed something … Signal Outrage Article #518. The Signal people must have a fun time dealing with this stuff.

    Expecting similar alerts to be sent out to my existing chat threads upon phone changeover, I messaged a few of my more recent chats.

    As I read it they sent it after the key changed? Ehm…

    1. 3

      I think the point here is: should you be able to notice when your chat partner adds/removes devices to their account or not?

      If it’s easy to silently add a device, an attacker who has a few minutes of access to your phone can scan a QR code and eavesdrop on all conversations.

      1. 2

        A Signal identity can only be associated with a single phone at a time.

      2. 2

        Wasn’t very clear to me either, what I got from it:

        1. “Transferring” the key during a migration process There’s some options which can make your Signal experience more secure, and makes transferring the key not possible:
        • disabling Signal PIN (results in complete data loss when re-registering Signal on a new phone, “unless you manually back up and restore”). you would then have to manually backup conversations with a passphrase to get them on a new device
        • the actual key material transfer process requires both devices to be on the same network (at least for me)

        This issue is debatable, e2e with multiple devices is hard to pull off, and not many protocols/applications manage to do it in a usable way (Matrix/Element is the one I know which is the most usable while still secure).

        1. Uninstalling Signal on iOS/Android and then reinstalling

        I assume this happens with iCloud Backup(?)/Google Backup(?) active on the mobile devices, and results in the data/chat history/safety number restoring out of the blue.

        If it happens also when not doing device migration, it does sound like a problem. Seems to me, if this is the case, that Apple/Google may be able to access your Signal conversations and impersonate you.

        I’m hoping someone with more information on the issue(s) might explain better (Moxie, are you here?)

        1. 2

          If it happens also when not doing device migration, it does sound like a problem.

          Yeah, that would be a problem, potentially a huge one (depending on details), but unless I misunderstood something this isn’t the issue at all. All it seems like is “Signal does a cp of my key when I ask it to”, and having the key remain on your local phone after uninstallation has exactly the same threat model as having it on your phone when installing.

          Actually, there is perhaps a tiny potential threat in that last one since keys may be recovered from discarded phones; although you’d expect that anyone would wipe their phone before reselling, and you do need to confirm your phone number again on reinstall in any case IIRC. It’s a very tiny problem at best.

          And since clearing data does seem to remove the key, it doesn’t seem stored remotely on iCloud or whatnot. But “key is stored remotely” is an entirely different thing than what this article is about anyway.

          1. 1

            A stolen key from a discarded phone would not allow an attacker to decrypt past communications due to the signal protocol’s forward secrecy scheme.

            1. 1

              Decryption was never an issue in this article. It’s about impersonation.

      3. 1

        is it true that they have stopped releasing code?

        1. 4

          They started publishing again in April. Moxie commented about why there was such a big gap in public releases.

          1. 1

            I wonder if this is a violation of the AGPL. “reluctance to immediately publish the exact anti-spam measures” is certainly not a justification for withholding code under the license.

            1. 9

              They own the copyright for their code; one can’t violate a license to oneself.

              1. 1

                I guess they don’t accept outside contributions under the AGPL then

                1. 4

                  Right, they require a CLA.