An overview of the

Introduction to asymmetric encryption

Public-key cryptography (English: Asymmetric cryptography) is an algorithm of cryptography, it requires two keys, one is a Public key, the other is a private key; The public key is used for encryption and the private key for decryption. If the plaintext is encrypted using a public key, the original plaintext can only be decrypted using the corresponding private key. The public key used for encryption cannot be used for decryption. Because encryption and decryption need two different keys, it is called asymmetric encryption; Unlike symmetric encryption where encryption and decryption both use the same key. The public key can be made public and released freely. The private key can not be public, must be kept by the user strictly secret, never through any way to anyone, will not be disclosed to the trusted to communicate with the other party.

The above quote is from the public key encryption Wikipedia

The difference between asymmetric and symmetric encryption

  • The key value used for message decryption is different from the key value used for message encryption. Asymmetric encryption is private key encryption and public key decryption, and vice versa. Symmetric encryption encrypts and decrypts with the same key value.

  • Asymmetric encryption algorithms are thousands of times slower than symmetric encryption algorithms.

A digital signature

Digital Signature is a kind of function equivalent to seal and Signature in the real world in the field of Digital information. Digital signatures can detect tampering and spoofing.

In digital signature technology, there are two kinds of behavior:

  • Signature is generated
  • Signature verification

Signature generation is carried out by the initiator in the communication, and the process is as follows. The communication content is first hashed, then encrypted with the private key sent and finally signed.

Signature verification is performed by the receiver in the communication, and the process is shown below. Generally, the sender sends the message along with the signature to the receiver. The receiver first decrypts the signature using the sender’s public key and computes a digest. The message is then hashed to produce another digest. Finally, the two digests are judged to be equal. If they are equal, the received message has not been tampered with by a third party.

So how does the receiver get the sender’s public key? How does the receiver determine that the public key belongs to the sender? That’s what digital certificates do.

The digital certificate

Digital Certificate is a realization of the functions equivalent to id card in the real world in the field of Digital information. A digital Certificate contains the identity information of an individual or organization and its Public Key, so it is also called a public-key Certificate (PKC).Similar to the IDENTITY card is issued by the authoritative public security bureau, the public key Certificate is also issued by the authoritative Certificate Authority (CA). The authentication authority provides the recipient with the sender’s certificate, which contains the sender’s identity information and public key. To prevent the certificate from being tampered during certificate issuance, the authentication authority uses the IDENTITY information and public key as the message, uses the CA private key to sign the message, and then adds the identity information, public key, and signature to the certificate, as shown in the following figure.

  • Root certificate

When receiving the sender’s certificate, the receiver uses the CA public key to authenticate the certificate. In many cases, the CA public key is issued by another, more authoritative body. Certificates similar to the local public security bureau are issued by the municipal public security Bureau, which in turn are issued by the provincial public security Bureau. A Certificate has a Chain of Trust. Root Certificate is the source of Trust, that is, the origin of the Trust Chain.

The issuer of the Root Certificate is called the Root Certificate Authority (Root CA). The Root Certificate in an authentication domain is a self-signed Certificate issued by the Root CA. Installing a Certificate means trusting the CA authority.

Certificates can be divided into three types based on their position in the trust chain:

  • Root Certificate
  • Intermediate Certificate
  • Leaf Certificate

This raises a fundamental question: How do you ensure that the root certificate is trusted?

In fact, root certificates are installed with software. For example, a list of trusted root certificates is built-in during operating system installation.

Apple Development Certificate

First of all, the purpose of the certificate is to prove that you are indeed an Apple developer (after all, developers have to pay Apple Dad money). Let’s take a look at the MacOS trust chain for iOS developer certificates (via “keychain”) :

Apple Worldwide Developer Relations Certification Authority: Intermediate certificate -- iPhone Developer:(XXXXXXX) : leaf certificateCopy the code

Using the process

  • The developer generates the key pair locally and provides the developer’s identity information.
  • Sends the public key and identity information of the key pair to the CA.
  • The CA uses the CA private key to sign the developer’s public key and identity information.
  • The CA assembles the developer’s public key, identity information, and signature into a certificate for download.

Note: Download the certificate from Apple Member Center website to Mac and double click to install.

When manually clicking *. Cer to install the certificate into macOS, Keychain Access traces its issuing CA to Apple Worldwide Developer Relations Certification Authority (Apple Worldwide Developer Relations Certification Authority), The AppleWWDRCA certificate public key is used to decrypt and verify the digital signature of the development certificate. Successful verification will mark This certificate as valid


The transfer between the local Git repository and the remote repository is encrypted using SSH, which is short for Secure Shell. SSH is a security protocol based on the application layer. SSH Provides security for remote login sessions and other network services.

SSH is secure because it uses public key encryption.

How to use SSH

  • The remote host receives the login request from the user and sends its public key to the user.
  • The user uses the public key to encrypt the login password and send it back.
  • Using its own private key, the remote host decrypts the login password and, if the password is correct, allows the user to log in.

The process itself is secure, but there is a risk that if someone intercepts a login request and then impersonates a remote host and sends a fake public key to the user, it will be difficult for the user to tell the difference. Unlike HTTPS, SSH public keys are not notarized by a certificate center (CA), that is, they are issued by themselves.

Imagine an attacker inserting himself between a user and a remote host (say, in a public wifi area), using a forged public key, to obtain the user’s login password. Use this password to log in to a remote host, and SSH’s security mechanism is gone. This risk is known as a “man-in-the-middle attack”.

If you log in to the host for the first time, the following message is displayed:

$SSH user@host The authenticity of host 'host (12.18.429.21)' can't be established. RSA key fingerprint is 98:2 e: d7: e0: DE: 9 f: ac: 67-28: c2: d: was that dwellest: behold d. you sure you want to continue connecting (yes/no)?Copy the code

Do you want to continue the connection?

The so-called “public key fingerprint” refers to the public key length is long (RSA algorithm is used in this case, the length is 1024 bits), so it is difficult to compare. Therefore, MD5 calculation is performed to convert the public key into a 128-bit fingerprint. Case is 98:2 e: d7: e0: DE: 9 f: ac: 67-28: c2: d: was that dwellest: behold d, compare again, would be easier.

A natural question is, how does the user know what the public key fingerprint of a remote host should be? The answer is no, remote hosts must post public key fingerprints on their web sites so users can check for themselves.

Suppose, after weighing the risks, the user decides to accept the public key of the remote host.

Are you sure you want to continue connecting (yes/no)? yes

The system displays a message indicating that the host has been approved.

Warning: Permanently added ‘host,12.18.429.21’ (RSA) to the list of known hosts.

You are then asked for a password.

Password: (enter password)

If the password is correct, you can log in.

When the public key of the remote host is accepted, it is saved in the file $HOME/.ssh/known_hosts. The next time you connect to the host, the system will recognize that its public key is already stored locally and will skip the warning and prompt for the password.

Each SSH user has his or her own known_hosts file, and the system also has one, usually /etc/ssh/ssh_known_hosts, that holds public keys of remote hosts that can be trusted by all users.

A public key to login

Log in with a password, which must be entered every time, which is very troublesome. Fortunately, SSH also provides public key login, eliminating the need to enter a password.

The principle of “public key login” is very simple. The user stores his public key on a remote host. At login, the remote host sends the user a random string, which the user encrypts with his private key, and sends back. The remote host decrypts the shell using the public key stored in advance. If successful, the user is proved to be trusted and is allowed to log in to the shell without requiring a password.

This method requires that users must provide their own public keys. If you don’t have one, you can just use ssh-keygen to generate one:

$ ssh-keygen

After running the above command, the system will display a series of prompts, you can press enter. One of the questions is whether to set a passphrase on the private key, which you can set here if you are concerned about the security of the private key.

After the command is executed, two new files and id_rsa are generated in the $HOME/. Ssh/ directory. The former is your public key and the latter is your private key.

To send the public key to the remote host, enter the following command:

$ ssh-copy-id user@host

Ok, from now on you login again, do not need to enter a password.


After a third-party login or a self-created account is logged in, a token is returned. Subsequent network requests only need to carry the token without a user name or password. Token here can be interpreted as a proof of the user name and password. With token, you can go to the server to obtain various resources of the user. So how does it work?

Token usage process

With token-based authentication, there is no need to store a user’s login record on the server. The general process is like this:

  1. The client requests login using the username and password
  2. The server receives a request to verify the user name and password
  3. After the authentication succeeds, the server issues a Token and sends the Token to the client
  4. After receiving the Token, the client can store it, for example, in a Cookie or Local Storage
  5. Each time a client requests resources from the server, it must carry a Token signed by the server
  6. The server receives the request and verifies the Token in the request. If the verification succeeds, it returns the requested data to the client

This token must be passed to the server on every request and should be stored in the request header.

Implement token mechanism

There are many ways to implement Token verification. There are some standard methods, such as JWT. The JWT standard Token has three parts:

  • header
  • payload
  • signature

The first part is called the header, the second part is called the payload, and the third part is the signature.


The header of the JWT carries two pieces of information:

  • Declare type, in this case JWT
  • Algorithms that declare encryption usually use HMAC SHA256 directly

{ ‘typ’: ‘JWT’, ‘alg’: ‘HS256’ }

Base64 encryption of the header, which can be decrypted symmetrically, forms the first part.



The payload is where the useful information is stored.

  • A declaration of registration in a standard
  • Public statement
  • Private declaration

Declarations registered in the standard (recommended but not mandatory) :

  • Iss: JWT issuer
  • Sub: The user JWT is targeting
  • Aud: The side receiving the JWT
  • Exp: indicates the expiration time of the JWT. The expiration time must be greater than the issue time
  • NBF: defines the time before the JWT is unavailable.
  • Iat: issue time of JWT
  • Jti: Unique IDENTIFIER of the JWT. It is used as a one-time token to avoid replay attacks.

A public statement:

Public declarations can add any information, usually about the user or other information necessary for the business. However, it is not recommended to add sensitive information because this part can be decrypted on the client side.

Private declaration:

Private declarations are defined by both providers and consumers. Sensitive information is generally not recommended because Base64 is symmetrically decrypted, meaning that part of the information can be classified as plaintext information.

Define a payload:

{ “sub”: “1234567890”, “name”: “John Doe”, “admin”: true }

It is then base64 encrypted to get the second part of the Jwt.



The third part of the JWT is a visa information, which consists of three parts:

  • Header (Base64)
  • Payload (base64)
  • secret

This part is used by the base64-encrypted header and the Base64-encrypted payload. A string of concatenated strings, then salted secret with the encryption method declared in the header, which forms the third part of the JWT.

// javascript 
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload); 
var signature = HMACSHA256(encodedString, 'secret'); 
// TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Copy the code

Note: Secret is stored on the server side, JWT generation is also on the server side, secret is used for JWT signing and JWT authentication, so it is your server side private key and should not be disclosed in any scenario. Once the client is aware of this Secret, it means that the client can issue the JWT itself.

The token is signed by the private key and verified by the public key.

The server validates the token and returns the corresponding resource if it succeeds. Here’s how it works:

  • How does JWT protect data?

It is important to understand that the purpose of using JWT is not to encrypt data. JWT is used to ensure that the data being sent is created by a trusted source.

Data in JWT is only encoded and signed, not encrypted.

The purpose of encoding data is to transform the structure of the data, and the purpose of signing the data is to ensure that the receiver can verify the source of the data. Of course, encoding and signing do not protect data. The purpose of JWT is to verify the reliability of the source of the data, not to protect the data and prevent unauthorized access.

JWT simply encodes and signs the data, not encrypts it. Therefore, JWT does not guarantee data security.

  • Check JWT

The JWT used is signed by the HS256 algorithm and the key is known only to the server. When a user calls the API with a JWT attached request, the application can perform the same signature algorithm for header and payload. The application can then verify that the signature it creates matches the signature attached to the JWT (the signature matches the JWT signature created by the server). If the signatures are consistent, then the JWT is valid, indicating that the API request came from a trusted source. If the signatures are inconsistent, the JWT is invalid, and the request could be a potential attack on the application server. By validating JWT, trust can be established between the application and the user.


Network requests are generally divided into HTTP request and HTTPS request. HTTP transmission is plaintext transmission, and it is easy to be intercepted and peeped during transmission. However, HTTPS is a secure hypertext transmission protocol with SSL/TLS layer (Secure Sockets Layer) added on the basis of HTTP. The content of its transmission is encrypted, so it is a secure transmission; HTTP and HTTPS use different ports, the former is 80, the latter is 443;

HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer) Is used for Secure HTTP data transmission. HTTPS is based on SSL,

Asymmetric encryption algorithms (public and private keys) exchange symmetric keys + digital certificate authentication (to verify whether the public key is forged) + encryption and decryption of subsequent transmitted data using symmetric keys = security