AsymmetricCryptography : An extension for asymmetric cryptography

Extensions
,
30

That’s not true. An example flow for two users to exchange messages would go something like this:

  1. User A generates a keypair and publishes the public key via CloudDB
  2. User B generates a keypair and publishes the public key via CloudDB
  3. User A retrieves the public key of User B and uses it to encrypt a message
  4. User A publishes the encrypted message via CloudDB
  5. User B receives the message, such as through the DataChanged event, and decrypts the message using their private key.

Neither user reveals their private key in this scenario. The public keys are all that are necessary to establish the secure channel. For example, my PGP public key (which you could use to send me encrypted messages), is available here. The private key only ever lives on my machine (plus backup disks), and has a passphrase so that even if someone got a hold of the keychain they would need to know the passphrase in order to decrypt the messages (or brute force the private key, which is theoretically possible but practically infeasible as far as we know).

Note that my scenario above doesn’t cover signing the message. For example, another User E might want to pretend to be User A and send User B a message encrypted using User B’s public key. Usually to counter this, User A includes a digital signature signed with User A’s private key, which can be verified using User A’s public key. This way, User B can confirm that User A was the original sender. Since User E doesn’t have user A’s private key, they can’t forge a message signed using that key. If you were to reveal the private key, you would have no way of knowing if someone is reading your messages or masquerading as you.

This exchange is essentially how SSL works. The server has a private key and its public key is included in the certificate sent to your browser. Your browser creates a temporary key pair and exchanges the public key with the server. The browser and server then negotiate a symmetric key pair over this asymmetrically-secured connection (see my previous note about speed), usually using Diffie-Hellman. If the server’s private key is ever revealed, an adversary could decrypt the exchange of symmetric keys and then decrypt all communications to that server, which would reveal passwords, banking information, etc.

6 Likes