I think you should distinguish better between encryption and authentication; they're separate operations. Encryption allows me to turn a given plaintext into a ciphertext, which can only be turned back into the plaintext by the keyholder. The purpose of encryption is to prevent anyone without the key from learning the plaintext, even if they are able to see the ciphertext. Authentication ("signing") allows me to verify that the keyholder was the sender. Its purpose is to prevent anyone without the key from forging a message that would appear to be from the keyholder.
For instance, if I wanted to send you a message using some asymmetric system, I would *sign* it with *my* *private* key, and *encrypt* it with *your* *public* key. We can be confident that only you can decrypt it with your private key, because no one else has your private key. When you check the signature against my public key, you can be confident that I sent it, because no one else has my private key.
I see a couple places in the text where this distinction is muddied. You claim in the intro that the two definitions are mostly equivalent, but the first covers encryption, while the second describes authentication. Later on, in the last sentence of "In Keys We Trust", you use the terms encrypt/decrypt when what you're actually describing is authentication.
The situation with private keys is more complicated than "how much of the cryptography world just below the surface operates." Symmetric encryption tends to be more efficient, so you'll see protocols that begin with a short asymmetric conversation to establish a symmetric key, or shared secret, which they use for the real conversation. This is a form of "key exchange," a term which is possibly misused in "Swordfish" (that whole sentence is difficult to understand).
Finally, I'd point out that passwords aren't a very good metaphor for cryptographic keys, and misunderstanding this could be potentially harmful to your target audience. You type in your literal password anytime you want to log in somewhere, but you should never send your raw private or symmetric key merely to prove identity, and sending your public key is insufficient to prove identity (the whole point is that it's public, i.e. lots of people have it). Instead, you sign something with the key, so that the recipient/eavesdropper doesn't have your actual key and can't impersonate you later on.
@khird
Thanks so much for the detailed feedback! I should definitely include a caveat at the beginning of the post that I know just enough to be dangerous to my own security, haha.
I'll definitely incorporate distinguishing between encryption and authentication, as well as remove the phrase key exchange. Underscoring the difference between giving a password and keeping a private key secure is definitely important too.
In general, I'll look towards cleaning things up. I do want to avoid too much detail though, in order to avoid overwhelming a layperson.