you know matrix chat? it’s supposed to be end-to-end encrypted. the same goes for whatsapp and other chat applications.

(technical note: if alice wants to send a message to bob with end-to-end encryption, then alice signs the message with her private key and bob’s public key. then bob can read the message with alice’s public key and his private key. so bob knows that the message actually comes from alice, and nobody can read it but bob.)

here’s the problem: the public keys are all stored on someone else’s (3rd party) server. for whatsapp, they’re stored on whatsapp’s server. so if bob gets a message from alice, he has to read that message with alice’s public key, but he gets the key from whatsapp’s server. so whatsapp can do a man-in-the-middle attack quite easily by giving out a fake alice’s public key.

actual effective end-to-end communication is only possible if alice and bob exchange public keys in real life. this circumvents a 3rd party server. and this is what needs to be implemented in chat applications such as matrix chat. (you can pass the public key with a QR code or sth like that)

  • kbal@fedia.io
    19·
    3 days ago

    The “shower thought” version of this should be more like “I should verify my friend’s key fingerprint today.”

    (Signal calls it a “safety number.” If you want real security don’t use Whatsapp.)

  • slazer2au@lemmy.worldEnglish
    14·
    3 days ago

    here’s the problem: the public keys are all stored on someone else’s (3rd party) server. for whatsapp, they’re stored on whatsapp’s server. so if bob gets a message from alice, he has to read that message with alice’s public key, but he gets the key from whatsapp’s server. so whatsapp can do a man-in-the-middle attack quite easily by giving out a fake alice’s public key.

    Quite the misunderstanding here. The public and private keys don’t secure the message itself, they are a way of both parties arriving at the same secret for the message to use without sending the actual secret.

      • LurkingLuddite@piefed.socialEnglish
        5·
        3 days ago

        Not if the sender is signing it with the correct private key.

        Of course, that requires the app to do the correct thing, and if it’s coming from someone shady…

        Though if the app wanted to MITM their users’ private keys, they’d be FAR better off just writing the app to upload the private key to their servers, too. Much simpler and potentially more devastating if it scrapes up other keys, too.

        Then nobody shows up with a different key than what was set up, even if they had set it up manually.

  • gnufuu@lemmy.ca
    8·
    3 days ago

    actual effective end-to-end communication is only possible if alice and bob exchange public keys in real life

    You can’t always meet all your peers in real life. Some other trusted channel may have to do in some cases.

    • Aniki@feddit.orgOP
      1·
      3 days ago

      you can sometimes meet some of your peers in real life, which is better than never meeting any of your peers in real life. exchanging some public keys securely is better than never exchanging any public keys securely.

      • gnufuu@lemmy.ca
        5·
        3 days ago

        I agree that public keys need to be verified over a separate, secure channel. I also agree that meeting irl is to be preferred. My point is that using other channels for verification is still better than not verifying the keys at all.

      • Aniki@feddit.orgOP
        2·
        3 days ago

        also the possibility of meeting in real life and verifying mutual public keys deters public key servers from giving out fake public keys because they could more easily be verified if the two people ever meet in person in the future, and so the server would be blamed for a mismatch.

  • TheDarkQuark@lemmy.world
    4·
    3 days ago

    For anyone else like me who didn’t understand on a first read what OP is saying (it’s not you OP, it’s me; I am a single brain celled organism):

    Say Alice has generated keys pub_a and priv_a. Bob generated keys pub_b and priv_b and Bob has the unencrypted message msg_b.

    We assume:

    # Bob encrypts with Alice's public key
enc_b = pub_a(msg_b)

# Alice decrypts with her private key
priv_a(enc_b) = msg_b

    Now, let’s say WhatsApp has generated keys pub_w and priv_w.

    # WhatsApp reads the unencrypted message
enc_b1 = pub_w(msg_b)
msg_b = priv_w(enc_b2)

# And then re-encrypts it with Alice's public key
enc_b2 = pub_a(msg_b)
msg_b = priv_a(enc_b2)

    I just did a quick search, and found that you can verify the public key fingerprint. In WhatsApp, it is via the chat settings window -> Verify Security Code.

    I also found this white paper: https://www.whatsapp.com/security/WhatsApp-Key-Transparency-Whitepaper.pdf

    Although, I have to admit I didn’t read it yet (may be I’ll read it sometime later).

    Thinking about it, I agree that the best way would be sharing public keys over a different trusted channel unrelated to the main service.

  • mspencer712@programming.dev
    1·
    3 days ago

    Fun fact: you can actually do mitm-proof end to end encryption between a web server and a client: TLS client authentication. It’s tricky to set up, so this is more useful for e.g. small private web servers with tech savvy users. Any mitm would require cooperation of at least one party.

    In windows you manage certs with start / run / mmc, then add snap-in and pick certificates, local machine or current user. And then usually the browser requires you to whitelist the domain so it’ll be allowed to ask for a cert.

    You still have to coordinate to exchange cert identities (thumbprint ideally, CN if you really have to).