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

Reprint: http://blog.csdn.net/a1232345/article/details/44594867 explanation of public key and private key

公钥: For outward release, accessible to anyone,
私钥: 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 via Ssh-keygen, and if he wants to access a remotehost, it only needs to add the public key to RemoteHost ~/.ssh/authorized_keys, and 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.客户端生成【随机数1】，客户端（通常是浏览器）先向服务器发出加密通信的请求，发送【随机数1】，向服务器端索要公钥；  2.服务器收到客户端请求后，生成【随机数2】，向客户端发出回应，回应信息包括【随机数2】，服务器证书(包含公钥)  3.客户端收到后，验证服务器证书的有效性，取出公钥，生成【随机数3】，使用公钥加密【随机数3】，发给服务器。  4.服务器回应， 至此，服务器和客户端都有3个随机数，使用3个随机数生成这次的会话秘钥(即对称秘钥)，二者开始使用对称加密通讯。服务器通知客户端：编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验(对称加密)。5.之后二者将通过对称加密来通讯。

Explanation: Why use 3 random numbers.

不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性，三个随机数通过一个密钥导出器最终导出一个对称密钥，增加随机性

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

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