Public Key Encryption

Let:

• t = the plaintext (the text we want to send)
• p = the public key, whose secret key is s.
• s = the secret key, whose public key is p
• c = The cypher text (AKA the encrypted string)

Notation

The notation f(x,y) -> z means f is a function which takes in arguments x and y, and returns z.

Functions

Define e(s,t) -> c as the encryption function.
Define d(c,p) -> t as the decryption function.

Workflow

This public key encryption workflow is specific to interacting with trusted authorities that also have a copy of your secret key. In this workflow, the public key serves as an identifier for looking up the corresponding secret key. There are separate public key encryption workflows for when you wish to encrypt a message for an entity that does not have a your secret key.

This workflow is commonly used by REST APIs that provide its users with public/secret keys.

Key generation

The public key p and the secret key s are generated as a pair. p is safe to share across insecure channels such as HTTP or email. s, however, should never be shared with anyone.

The general idea is that p is used to encrypt messages. Then the encrypted message and p are sent together. Then the secret key s corresponding with p will be used to decrypt messages. The central authority will have a copy of s, and will retrieve s based upon p.

Encryption

The process behind public encryption is to supply our encryption function e with the plaintext we want to send (t) and public key (p). This encryption function will result in the unreadable cypher text c that we are theoretically safe to send across insecure channels (such as HTTP, email, etc).

We can now send c together with p in an email, in an HTTP request, etc.

Concerns

If we send an email with c and p together, is that enough to get back t? Theoretically, no. Since s is never sent across, an attacker that has access to both c and p should theoretically not be able to retrieve the original t.