There’s a server, a client, and a hacker in a network. For encryption, the client and the server need to share their private keys. Wouldn’t the hacker be able to grab those during their transmission and decrypt further messages as they please?

  • RegalPotoo@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    You’ve missed a key detail in how asymmetric encryption works:

    • For asymmetric encryption algorithms, you essentially have two keys - a “private” key, and a “public” key
    • If you know the private key it is trivial to calculate the public key, but the reverse isn’t true - just given the public key, it is essentially impossible to calculate the private key in a reasonable amount of time
    • If you encrypt something with the public key you must use the private key to decrypt it, and if you encrypt with the private key you can only use the public key for decryption
    • This means that my server can advertise a public key, and you can use that to encrypt the traffic so that only the server that knows the private key can decrypt it
    • lad@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      I used to know that and still struggle to understand how a handshake wouldn’t allow MitM. Later I found out that it requires a third party with a trusted and known certificate for signing handshake exchange messages in order to ensure there’s no man in the middle: https://stackoverflow.com/a/10496684

      • RegalPotoo@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 year ago

        A big “It Depends” on that - plenty of applications of asymmetric crypto where you just hard-code the servers public key into the client and call it a day, and GPG has its own PKI scheme that is just kinda weird.

        You also don’t have to use Diffie-Hellman - early versions of SSL just sent the ephemeral key (the symmetric key used for the actual AES session) directly. This works, but using DH also gives you “forward secrecy” - even if a malicious third party has captured the entire encrypted session, then later steals (or factors) your private key they still won’t be able to read the encrypted traffic because they can’t recover the ephemeral key because it wasn’t sent over the wire in the first place