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?
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?
You’ve missed a key detail in how asymmetric encryption works:
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
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
Yes, that’s why https needs certificates (and sometimes shows a broken lock) and why you need to accept the fingerprint when first connecting to a server via ssh.
Accepting ssh key fingerprints on first ssh is a bad practice. Ssh ca’s and or sshfp are around and have been for decades. Accepting random host keys is like trusting random self signed ssl certificates.
Use ssh ca’s for user and host keys so you can revoke and rekey hosts without having to update authorized keys. And then you can revoke access to hosts for users as well and much more.
I didn’t believe this is true… In public/private key crypto there is no such thing as “private” and “public”. They’re just a key pair. You choose to make one public by sharing it and the other private by not sharing it.
It depends on the cryptosystem. The private and public halves of the pair are often not symmetrical and often have overlap.
The parent is likely confused because in most situations the “private key file” will also contain all of the public key. Whether by necessity or for convenience.
Just a nitpick:
The public key and the private key are just two big prime numbers. The “trivial to compute” part only works once more information has been shared over the network, like it happens during key exchange. If you were to swap the prime number before initiating any contact it would work the same way.