SSH HTTPS public key, secret key, symmetric encryption, asymmetric encryption, summary understanding

Des:

Digital Encryption Standard. Obsolete Standard.
Single key algorithm is the sender of the information using key A for data encryption, the receiver of the information uses the same key a for data decryption.

The single key algorithm is a symmetric algorithm.
The algorithm is good at adding/solving speed, the key volume is short, symmetric encryption is used

Dsa:

Digital Signature algorithm. Based on discrete logarithms computation.
for signing

Rsa:

RSA is an asymmetric encryption and decryption algorithm.
Both RSA and DSA are non-symmetric encryption algorithms. The security of RSA is based on the decomposition of a very difficult large integer (the product of two primes); the security of DSA

is based on the problem of discrete logarithm of integer finite field. Basically, the RSA algorithm with the same key length can be considered to be equal to the DSA algorithm security.

The public key is used for encryption, it is made public to everyone, the private key is used for decryption, only the recipient of the cipher holds it.

DSA is used for signing, and RSA can be used for signing and encryption.

*Refer: *

DES _ Baidu Encyclopedia

RSA,DSA and other encryption and decryption algorithm Introduction _ More and more good _ Sina Blog

The difference between DSA and RSA-ad007520-itpub Blog

Explanation of public key and private key

Public key: For outward release, accessible to anyone,
Private key: To save yourself, do not give others

The two situations are often confused and must be understood.

Case 1: Public key for "encryption", private key for "decryption"
If the encryption key is public, this is used for the client to upload the encrypted data to the private key owner, which is known as the public key encryption (narrowly defined).
For example, internet banking customers send encrypted data to the account operations of the bank's website. HTTPS, and so on.

Case 2: Public key for "decryption", private key for "encryption"
If the decryption key is public, the information that is encrypted with the private key can be decrypted with the public key for the client to verify that the data or file published by the party holding the private key is complete and accurate, and that the recipient is sure that the message comes from someone with a private key, which is called a digital signature, and the public key is a digital certificate. For example, the installation program downloaded from the Internet, usually with the digital signature of the program creator, proves that the program is indeed published by the author (company) and not by a third party and has not been tampered with (authentication/authentication).

Refer

Public key Encryption-Wikipedia, the free encyclopedia

Principles of digital certificates

Signature:

hash value after encryption
Here the main explanation of the signature, the signature is in the back of the information plus a section of content, you can prove that the information has not been modified, how can it achieve this effect? The general is to do a hash of the information to get a hash value, note that the process is irreversible, that is, the hash value can not be derived from the original information content. When the message is sent out, the hash value is encrypted and sent out as a signature and message.

Fingerprint:

fingerprint algorithm is a hash algorithm , such as MD5 algorithm;
Note that in order to be secure, the certificate's fingerprint and fingerprint algorithm are encrypted and released with the certificate when the certificate is issued by the issuing authority, in case someone modifies the fingerprint and then forges the corresponding digital certificate. Here comes the question again, what is the fingerprint and fingerprint algorithm used to encrypt the certificate? They are encrypted with the private key of the certificate publisher. The fingerprint and fingerprint algorithm can be decrypted with the public key of the certificate publisher, which means that the certificate publisher has his own certificate in addition to the certificate issued by the issuing authority. Where does the certificate authority's certificate come from??? The certificate publisher's digital certificate (typically generated by himself) is installed in the operating system by Microsoft (or other operating system development agencies) when our operating system is just installed (e.g., Windows XP). Companies such as Microsoft will choose some reputable security agencies according to the evaluation of some good reputation and through a certain number of security certification issued by the certification authority, the certificate issued by default installed in the operating system, and set to the operating system trusted digital certificate. These certificate publishers own the private key corresponding to his own digital certificate, and he uses the private key to encrypt the thumbprint of all the certificates he publishes as a digital signature.

Refer
What is a digital signature?

Public Key Login Error

Log in with a password, you must enter the password every time, very troublesome. Fortunately, SSH also provides a public key login, which eliminates the steps to enter a password.
The so-called "public key Login" principle is simple, that is, the user stores their own public key on the remote host. When logged in, the remote host sends a random string to the user, which is encrypted with his or her private key and then sent back. The remote host decrypts with a pre-stored public key and, if successful, proves that the user is trustworthy, allowing the login shell to be logged in and no longer requiring a password.
This approach requires the user to provide their own public key. If there is no ready-made, you can generate one directly with Ssh-keygen:

$ ssh-keygen

Refer

SSH principle and application (i): Telnet-Nanyi's blog

localhost: client,
RemoteHost: Server
Key access : localhost generates a public key pair through Ssh-keygen, and if he wants to access a remotehost, it only needs to add the public key to RemoteHost ~/.ssh/authorized_keys. Next, when localhost logs in via SSH [email protected], RemoteHost generates a random number and sends a series of values to localhost via the public key in the Autrorized_keys. LocalHost will decrypt the number of values sent through its own private key (of course, only the values generated by the corresponding public key will be decrypted normally), and then localhost will send the decrypted value back, RemoteHost, if the returned value is found to be a random number originally generated, The localhost will be allowed access. Of course, if the RSA key generated by localhost requires a password, the password will be entered next.

Refer

SSH Key Access

SSH Fundamentals and password-free login

From the client side, SSH provides two levels of security validation:

The first level is password-based security authentication:

(1) The remote host receives the user's login request and sends its own public key to the user.

(2) The user uses this public key to encrypt the login password and send it back.

(3) The remote host with its own private key, decrypt the login password, if the password is correct, consent to user login.

Cons: If someone pretends to be a server, it will give you the fake server public key, and finally get your response password, this is the man-in-the-middle attack.

The second level is key-based security validation:

Premise: The client creates a pair of public key + keys while placing the public key on the server.

1. The client software will make a request to the server and request security verification with your key;

1. After the server receives the request, look for your public key on the server and compare it to the public key that you sent over. If the two keys are consistent, the server encrypts a "random string" with the public key and sends it to the client software;
   3. After the client software receives the "encrypted-random string", it can be decrypted with your private key, and then send the "random string" to the server

The second level does not require a password to be sent over the network compared to the first level. The second level not only encrypts all transmitted data, but the "man in the middle" approach is also impossible (because he does not have your private key). However, the entire login process may take up to 10 seconds, but not 10 seconds longer than the way you enter the password.

Refer

SSH Fundamentals and password-free login

The principle of public key authentication

The so-called public key authentication, actually uses a pair of encrypted string, one is called public key, anyone can see its content for encryption, and the other is called the key (private key), only the owner can see, for decryption. Ciphertext encrypted with a public key can be easily decrypted using a key, but it is difficult to guess the key based on the public key.

SSH's public key authentication is the use of this feature. Both the server and the client each have their own public key and key. For illustrative purposes, these symbols are used below.

AC Client Public key
Bc Client Key
As Server public key
Bs Server Key
Before authentication, the client needs a way to log the public key Ac to the server.

The certification process consists of two steps.

Session key generation
The client requests a connection to the server, and the server sends the as to the client.
The server generates the session ID, which is set to P and sent to the client.
The client generates the session key, set to Q, and calculates r = P XOR Q.
The client encrypts r with AS and sends the result to the server.
The server decrypts with Bs and obtains R.
The server carries out the operation of R XOR P and obtains Q.
Both the server and the client are aware of the session key Q, and subsequent transmissions will be encrypted by Q.
Certification
The server generates a random number x and uses AC encryption to generate the result S (x), which is sent to the client
Client uses Bc decryption S (x) to get X
Client calculates the MD5 value of Q + x N (q+x), Q is the session key obtained in the previous step
Server calculates q + x's MD5 value m (q+x)
The client sends N (Q+X) to the server
Server comparison m (q+x) and N (q+x), both of which are certified successful

Refer

SSH Public key authentication principle

Asymmetric encryption

• The server establishes the public key: each time the SSHD service is started, the service will actively go to find/etc/ssh/ssh_host* files, if the system has just been installed, because there is no such public key, so sshd will take the initiative to calculate the required public key, but also to calculate the server's own private key

• Client Active Online Request: If the client wants to go online to an SSH server, it needs to be online using the appropriate client program, including SSH, Putty and other client program connections

• The server transmits the public key to the client: After receiving the client's request, the server transmits the public key obtained by the first step to the client (this should be the plaintext, anyway the public key is intended to be used by everyone)

• The client logs and computes its own public private key compared to the public key data of the server: If the client connects to this server for the first time, the server's public key is logged to ~/.ssh/known_hosts in the client's user home directory. If the public key of the server has been recorded, then the client will be compared to the previous record that was received. If this public key is accepted, the client's own public private key is calculated

• Return the client's public key to the server side: the user transmits his or her public key to the server. At this point, the server: With the server's private key and the client's public key, and the client is: With the server's public key and the client's own private key, you will see that the online server and the client's key system (public key + private key) is not the same, so it is called asymmetric encryption system

• Start two-way encryption: (1) Server to client: When the server transmits data, the user's public key is encrypted and sent out. After the client receives, it decrypts (2) the client to the server with its own private key: When the client transmits the data, the server's public key is encrypted and sent out. After the server is received, the private key of the server is decrypted so that communication security can be ensured.

Refer

SSH protocol and OpenSSH-Share your knowledge ...-51CTO technology Blog

SSL/TLS protocol

The basic idea of the SSL/TLS protocol is to use public key cryptography, that is, the client requests the public key to the server, then encrypts the information with the public key, and the server receives the ciphertext and decrypts it with its private key.

The basic process for the SSL/TLS protocol (which is HTTPS) is this:

1. The client generates a "random number 1", the client (usually the browser) sends a request for encrypted communication to the server, sends a "random number 1" to the server and requests the public key; 2. After the server receives the client request, generates a "random number 2", which responds to the client, including "random number 2". Server certificate (including public key) 3. After the client receives, verifies the validity of the server certificate, takes out the public key, generates a "random number 3", encrypts the "random number 3" with the public key, and sends it to the server. 4. Server response, at this point, the server and the client have 3 random numbers, using 3 random numbers to generate the session key (that is, the symmetric secret key), both began to use symmetric encrypted communication. Server Notification Client: Encoding change notification, indicating that subsequent information will be sent with mutually agreed encryption methods and keys. The server handshake end notification indicates that the server's handshake phase has ended. This is also the hash value of all the content that was sent earlier, and is used for client-side validation (symmetric encryption). 5. The two will then communicate through symmetric encryption.

Explanation: Why use 3 random numbers.

A random number is required for both the client and the server, so that the generated key will not be the same every time. Because the SSL protocol certificate is static, it is necessary to introduce a random factor to ensure the randomness of the negotiated key, three random numbers through a key exporter to finally export a symmetric key, increase the randomness

Before a lot of the HTTPS principle (including the following HTTPS), there are only 1 random numbers, why? Because after all is the principle, and did not clear the details;
In a nutshell, asymmetric encryption, which is used at first, is a safe way to pass a symmetric secret key, after all, the speed of symmetric encryption is fast.

Refer

Overview of the operating mechanism of SSL/TLS protocol

HTTPS Asymmetric + symmetric

Refer

Diagram HTTPS no network left

SSH HTTPS public key, secret key, symmetric encryption, asymmetric encryption, summary understanding