Let:
t= the plaintext (the text we want to send)p= the public key, whose secret key iss.s= the secret key, whose public key ispc= The cypher text (AKA the encrypted string)
The notation f(x,y) -> z means f is a function which takes in arguments
x and y, and returns z.
Define e(s,t) -> c as the encryption function.
Define d(c,p) -> t as the decryption function.
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.
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.
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.
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.