Popular encrypted messaging app Signal is facing criticism over a security issue in its desktop application. Researchers and app users are raising

As mentioned in the comments, plain text keys aren’t bad because they are necessary. You have to have at least one plain text key in order to be able to use encryption

  • Riskable@programming.devEnglish
    3·
    3 months ago

    This is a, “it’s turtles all the way down!” problem. An application has to be able to store its encryption keys somewhere. You can encrypt your encryption keys but then where do you store that key? Ultimately any application will need access to the plaintext key in order to function.

    On servers the best practice is to store the encryption keys somewhere that isn’t on the server itself. Such as a networked Hardware Security Module (HSM) but literally any location that isn’t physically on/in the server itself is good enough. Some Raspberry Pi attached to the network in the corner of the data center would be nearly as good because the attack you’re protecting against with this kind of encryption is someone walking out of the data center with your server (and then decrypting the data).

    With a device like a phone you can’t use a networked HSM since your phone will be carried around with you everywhere. You could store your encryption keys out on the Internet somewhere but that actually increases the attack surface. As such, the encryption keys get stored on the phone itself.

    Phone OSes include tools like encrypted storage locations for things like encryption keys but realistically they’re no more secure than storing the keys as plaintext in the application’s app-specific store (which is encrypted on Android by default; not sure about iOS). Only that app and the OS itself have access to that storage location so it’s basically exactly the same as the special “secure” storage features… Except easier to use and less likely to be targeted, exploited, and ultimately compromised because again, it’s a smaller attack surface.

    If an attacker gets physical access to your device you must assume they’ll have access to everything on it unless the data is encrypted and the key for that isn’t on the phone itself (e.g. it uses a hash generated from your thumbprint or your PIN). In that case your effective encryption key is your thumb(s) and/or PIN. Because the Signal app’s encryption keys are already encrypted on the filesystem.

    Going full circle: You can always further encrypt something or add an extra step to accessing encrypted data but that just adds inconvenience and doesn’t really buy you any more security (realistically). It’s turtles all the way down.

      • jet@hackertalks.comEnglish
        0·
        3 months ago

        The back end is open source, but sometimes they’ve lagged years behind releasing the source code. Other developers have stood up copies of the signal network. Session, for example.

        You can self host your own signal, but it’s not federated, so you’d have nobody to talk to

          • jet@hackertalks.comEnglish
            0·
            3 months ago

            It’s absolutely FOSS. It is not, however federated. But that is not a requirement to be free and open source software

            Think of it like this, Linux is free and open source software, even if I don’t give you a shell on my computer.

            You can use the code, however you want, in any project you want.

            • furikuri@programming.dev
              1·
              2 months ago

              The back end is open source, but sometimes they’ve lagged years behind releasing the source code.

              I think this is the more worrying part if true. The backend is licensed under the AGPL, so this would technically be a violation of their terms

              1. Remote Network Interaction; Use with the GNU General Public License.

              Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software

              Edit: For anyone else reading I looked into it a bit more and looks like the issue came to a head around 3 years ago, with this comment being made after a year of missing source code. The public repo has been pretty active since then, so the issue seems to be resolved