Comment on Lawsuit Alleges That WhatsApp Has No End-to-End Encryption

• just_another_person@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

  🤣🤣🤣😂

  Bruv, before Signal launched they posted an entire whitepaper detailing their protocol, the working mechanisms of the system, and source code. So to reply to your 3 points:

  1. No, this is stupid and easily verified by watching network traffic from any device. Signal is secretly sending plaintext messages anywhere.
  2. No, it’s not impossible to tell this at all. That’s what source code is. The executable code. Not only have NUMEROUS security audits been done on Signal by everyone from Academia, to for-profit security researchers and governments, you can easily verify that what you’re running on your phone is the same source code as what is published publicly because the fingerprint hashes for builds are also published. This means the same fingerprint you’d get building it yourself from source should also be the same as what is publicly published.
  3. See my point above, but also when two users exchange keys on Signal (or in any other cryptographic sense), these keys are constantly verified. If changed, the session becomes invalid. Verifying these keys between two users is a feature of Signal, but moreover, the basics of cryptography functioning can, and have been proven, during the independent audits of Signal. Go read any of the numerous papers dating back to 2016.

  If you don’t understand how any of this works, it’s just best not to comment.

  source

  • RIotingPacifist@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

    1. Why would any message be plaintext?

    2. Fair you could have just said they have reproducible builds or linked to the docs: github.com/signalapp/Signal-Android/…/README.md

    3. Again you are missing the point of the attack

    If you don’t understand how any of this works, it’s just best not to comment.

    Back at you, even if you are right that signal is secure, the attack is not what you think it is.

    source

    • just_another_person@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

      What in the world are you talking about here, bud? Your comments are making zero sense.

      Look, seriously, if my comment is being upvoted, it’s because I responded to yours, and people understand what I am saying in response.

      You, unfortunately, clearly do not understand what I’m saying because you do not grasp how any of this works.

      source

      • RIotingPacifist@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

        seriously, if my comment is being upvoted, it’s because I responded to yours, and people understand what I am saying in response.

        Lmao, sure buddy pat yourself on the back because you got upvotes.

        You’re talking about E2E encryption as if it prevents side-channel attacks, but sure morons will upvotes because they also don’t understand real world security.

        The only useful thing you’ve pointed out in your deluge of spam, is that Signal builds are reproducible which does protect against the attack described (as long as there isn’t a backdoor in the published code)

        source

        • -> View More Comments
  • pressanykeynow@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

    What if the malicious actor is not Signal but Google or the hardware manufacturer?

    Can we check that the encryption key generated by the device is not stored somewhere on the device? Same for the OS.

    Can we check that the app running in memory is the same that is available for reproducible build checks?

    Can we check that your and my apps at the moment are the same as the one security researchers tested?

    source

    • just_another_person@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

      The clients (apps) enforce key symmetry for your own keys, server identity, and the exchanged with the other person part of a conversation. Constantly. There is no way to MITM that.

      The clients are open source, and audited regularly, and yes, builds are binary reproduceable and fingerprinted on release.

      That’s not to say someone can’t build a malicious copy that does dumb stuff and put it in your phone to replace the other copy, but the server would catch and reject it if it’s fingerprints don’t match the previously known good copy, or a public version.

      Now you’re just coming up with weird things to justify the paranoia. None of this has anything to do with Signal itself, which is as secure as it gets.

      source

      • pressanykeynow@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

        None of this has anything to do with Signal itself, which is as secure as it gets.

        Didn’t I say that at the start of my questions? What’s your point?

        server would catch and reject it if it’s fingerprints don’t match the previously known good copy, or a public version

        If I understand you correctly, you mean that Signal app checks itself and sends the result to the server that can then deny access to it? Is that what Signal does and what makes it difficult to spoof this fingerprint?

        I don’t think you answered any of my questions though since they weren’t about Signal.

        Now you’re just coming up with weird things to justify the paranoia

        I’m just asking questions about security I don’t know answers to, I’m not stating that’s how things are.

        source

        • -> View More Comments
• EisFrei@lemmy.world ⁨3⁩ ⁨weeks⁩ ago

  1. Why would meta have access to signal’s memory?
  2. That’s why code audits have been done multiple times.
  3. Reproducible builds. Signal has those since 2016

  source

  • protogen420@lemmy.blahaj.zone ⁨3⁩ ⁨weeks⁩ ago

    about the 3rd, is the end apk file downloaded by a useer on the playstore reproducible? could google add stuff to the apk before the user downloading it? do users ever bother checking if the apk hash matches the one from the reproducible build?

    source

    • 9bananas@feddit.org ⁨3⁩ ⁨weeks⁩ ago

      no, that’s why it’s called fingerprinting:

      it’s a kind of mathematical function that takes the entire code as input and outputs a unique result.

      the result is just some string of symbols (which really just represent a unique string of 1’s and 0’s).

      this unique string of characters is, as mentioned, unique for any given input.

      this string can then be compared to any arbitrary other string, and if they match, then you know it’s the same code.

      so in the case of signal anybody can download the source, compile it, and verify that it matches the fingerprint of the compiled code on their own device.

      that’s why it can’t be faked: you compare the already compiled code.

      if even a single digit of the code is out of place, it’s not going to result in the same string, and thus immediately get flagged as a mismatch.

      it’s mathematically impossible to fake.

      source

      • AlfredoJohn@sh.itjust.works ⁨3⁩ ⁨weeks⁩ ago

        While I agree with you I did just want to point out one thing.

        This:

        it’s mathematically impossible to fake.

        Is not entirely true persay, every hashing function does have collisions that can occur. But the likely hood that someone baked an exploit in that kept the application functioning while adding their backdoor all the while somehow creating a hash collision with the original fingerprint is practically zero and honestly if someone did pull that off, fucking hats off because that has to be some sort of math and coding wizard beyond most. I should also point out that the file size would most likely/have to be different so there should be other methods of detecting the compromised build regardless.

        Sorry I know that was very pedantic of me but I did want to call that out because its technically possible but the actual likely hood has to be so miniscule its almost irrelevant along with the fact that other tells would surely exist.

        source