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?

  • kevincox@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    Great question. Modern encryption schemes are usually composed of a handful of primitives. If we consider something like HTTPS it uses both asymmetric and symmetric parts.

    Asymmetric encryption is the “magic” that you are missing. Asymmetric encryption algorithms create a keypair, one half of this is the “public key” which can be used to encrypt messages that can only be decrypted by the “private key”. This means that even if the public key is public (as the name suggests) the messages can’t be decrypted without the public key.

    You can think of this as giving someone an open padlock. They can put something inside a box and lock it using the padlock, but they can’t open it without your key.

    Using this you could come up with a very simple protocol for establishing a secure channel:

    1. The server sends you their public key, along with a certificate that proves that it belongs to them.
    2. The client then uses this public key to encrypt a key for symmetric encryption.
    3. The client sends this encrypted key to the server.
    4. The server decrypts the key.
    5. Now the client and server can both use the shared key to communicate.

    (Note: There are many missing features from this system, but I think it illustrates the point. Don’t design your own crypto.)

    • bloubz@lemmygrad.ml
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      I don’t think DH is accurately relating to this. DH key exchange is used to generate a shared secret to use symmetric cryptography by two entities from (generally temporary) private keys, which are not specifically associated with a public key (this is not a public/private key pair)

      To me, two examples of public/private key usage are RSA (asymmetric cryptography) and for example SSH authentication with a key pair. DH key exchange can be used in SSH to encrypt communication, before authentication even begins

  • slazer2au@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    6 months ago

    Why are they sharing private keys?

    The point of the system is you share public key so others can encrypt data and the you use your private key do decrypt it.

  • RegalPotoo@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    6 months 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
      ·
      6 months 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
        ·
        6 months 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