Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use OpenSSL in linux. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Cryptographic hash

The download page for the OpenSSL source code contains a table with the latest version. Each version has two hash values, hash:160 bit SHA1 and 256bit SHA256. These values can be used to verify that the downloaded file matches the original file in the repository: the downloader recalculates the hash value of the downloaded file locally and then compares the result with the original file. Modern systems have utility programs to calculate this hash value. For example, Linux has md5sum and sha256sum. OpenSSL itself provides a similar command-line utility.

Hash values are used in many areas of computation. For example, a bitcoin block chain uses a SHA256 hash as the block identifier. Mining bitcoin is to generate a SHA256 hash below a specified threshold, that is, a hash with at least N leading zeros. (the value of N can rise or fall, depending on the mining productivity at a particular time). As a point of interest, today's mining machines are hardware clusters designed to generate SHA256 hashes in parallel. At one peak in 2018, bitcoin miners around the world generated about 75 million terahash per second-an incredible number.

Network protocols also use hashes (commonly referred to here as "checksum checksum") to support message integrity; that is, to ensure that the message received is the same as the message sent. The message sender calculates the checksum of the message and sends the result with the message. When the message arrives, the receiver recalculates the checksum. If the checksum sent is inconsistent with the recalculated checksum, there may be some problems with the message during transmission, or there may be a problem with the checksum sent, or both. In this case, the message and its checksum should be resent, or at least an error condition should be triggered. Low-level network protocols such as UDP ignore checksums. )

Other examples of hash are familiar to everyone. For example, a website requires the user to authenticate with a password, the user enters the password in the browser, and then they connect to the server through HTTPS, and the password is encrypted from the browser to the server. Once the password reaches the server, it is decrypted and the database table is queried.

What should be stored in this query table? Storing passwords is risky in itself. A much less risky way is to store a hash generated by the password, perhaps "adding some salt salt (extra bits) to improve the taste" before calculating the hash. Your password may be sent to the Web server, but the website can assure you that the password will not be stored there.

Hash values also appear in all areas of security. For example, a hash-based message authentication code hash-based message authentication code (HMAC) uses a hash value and a secret encryption key cryptographic key to authenticate messages sent over the network. HMAC code is lightweight and easy to use in programs, so it is very popular in Web services. An X509 digital certificate includes a hash called fingerprint fingerprint, which facilitates certificate verification. A trusted storage truststore stored in memory can be implemented as a lookup table with this fingerprint as a key-as a hash mapping hash map that supports constant lookup time. The fingerprint from the incoming certificate can be compared with the key in the trusted store to determine whether it matches.

What special properties should the cryptographic hash function cryptographic hash function have? It should be one-way one-way, which means it's hard to reverse. An encrypted hash function should be relatively easy to calculate, but calculating its inverse function (a function that maps hash values back to input bit strings) should be computationally difficult. Here is a description, using chf as the encrypted hash function and my password foobar as the sample input.

+-+ foobar- > | chf |-> hash value # # simple direct +-+

By contrast, reverse operation is not feasible:

+-+ hash value- > | chf inverse |-> foobar # # difficult +-+

For example, recall the SHA256 hash function. For an input bit string of arbitrary length N > 0, this function generates a 256-bit fixed-length hash value; therefore, the hash value does not even reflect the length N of the input bit string, let alone the value of each bit in the string. By the way, SHA256 is not vulnerable to the length scaling attack length extension attack. The only effective reverse engineering method is to reverse the calculated SHA256 hash value to the input bit string through a brute force search, which means that you need to try all possible input bit strings until you find a bit string that matches the target hash value. Such a search is not feasible on such a perfect encrypted hash function as SHA256.

Now, the last point to review is ordered in order. Encrypted hashes are statistically unique, not unconditionally unique, which means that it is impossible, but not impossible, for two different strings of input bits to produce the same hash-- this is called collision collision. The birthday question provides a good example of a counterintuitive collision. The anti-collision collision resistance of various hash algorithms has been widely studied. For example, MD5 (128bit hash) crashes after about 221hashes. For SHA1 (160bit hash), it starts to crash after about 261 hashes.

At present, there is not a good estimation of the anti-collision ability of SHA256. This fact is not surprising. SHA256 has 2256 different hash ranges, and the decimal representation of this number is as many as 78 bits! So, will the SHA256 hash collide? Of course it's possible, but it's highly unlikely.

In the following command-line example, two input files are used as bit string sources: hashIn1.txt and hashIn2.txt. The first file contains abc, and the second file contains 1a2b3c.

These files contain text for ease of reading, but binary files can also be used instead.

Using the Linux sha256sum utility to process these two files on the command line (% is the prompt) produces the following hash value (hexadecimal):

Sha256sum hashIn1.txt9e83e05bbf9b5db17ac0deec3b7ce6cba983f6dc50531c7a919f28d5fb3696c3 hashIn1.txt sha256sum hashIn2.txt3eaac518777682bf4e8840dd012c0b104c2e16009083877675f00e995906ed13 hashIn2.txt

The result corresponding to the OpenSSL hash is the same as expected:

% openssl dgst-sha256 hashIn1.txtSHA256 (hashIn1.txt) = 9e83e05bbf9b5db17ac0deec3b7ce6cba983f6dc50531c7a919f28d5fb3696c3% openssl dgst-sha256 hashIn2.txtSHA256 (hashIn2.txt) = 3eaac518777682bf4e8840dd012c0b104c2e16009083877675f00e995906ed13

This study of cryptographic hash function lays a foundation for us to carefully study the relationship between digital signature and key pair.

Digital signature

As the name implies, a digital signature digital signature can be attached to a document or other electronic artifact artifact (such as a program) to prove its authenticity. Therefore, this signature is similar to a handwritten signature on a paper document. Verifying the digital signature is to confirm two things: first, the guaranteed artifact does not change after the signature is attached, because it is based in part on the cryptographic hash value of the file. Second, the signature belongs to one person (for example, Alice), and only she can obtain the private key in a pair of keys. By the way, it has become a common practice for programmers to digitally sign code (source or compiled code).

Let's look at how digital signatures are created. As mentioned earlier, there is no digital signature without public and private key pairs. When using OpenSSL to create these keys, there are two separate commands: one is to create the private key, and the other is to extract the matching public key from the private key. These key pairs are encoded in base64, and their size can be specified in the process.

The private key private key consists of numeric values, of which two values (a modular modulus and an exponential exponent) make up the public key. Although the private key file contains the public key public key, the extracted public key does not reveal the value of the corresponding private key.

Therefore, the generated file with the private key contains the complete key pair. It is practical to extract the public key into your own file because the two keys have different uses, and this extraction minimizes the risk that the private key may be accidentally exposed.

Next, the private key of this pair of keys is used to generate a hash of the target artifact, such as e-mail, thereby creating a signature. At the other end, the recipient's system uses the public key of the pair of keys to verify the signature attached to the artifact.

Now let me give you an example. First, use OpenSSL to generate a 2048-bit RSA key pair:

Openssl genpkey-out privkey.pem-algorithm rsa 2048

In this example, we can omit the-algorithm rsa flag because genpkey defaults to the RSA type. The name of the file (privkey.pem) is arbitrary, but the privacy enhanced mail Privacy Enhanced Mail (PEM) extension .pem is the customary extension for the default PEM format. (OpenSSL has commands to convert between formats if necessary. If a larger key size is required (for example, 4096), the last parameter 2048 can be changed to 4096. These sizes are always the power of two.

Here is a snippet of the resulting privkey.pem file, which is base64 encoded:

-BEGIN PRIVATE KEY-MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBANnlAh5jSKgcNj/ZJF4J4WdhkljP2R+TXVGuKVRtPkGAiLWE4BDbgsyKVLfs2EdjKL1U+/qtfhYsqhkK...-END PRIVATE KEY-

The next command extracts the public key of the pair from the private key:

Openssl rsa-in privkey.pem-outform PEM-pubout-out pubkey.pem

The resulting pubkey.pem file is small and can be fully displayed here:

-BEGIN PUBLIC KEY-MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZ5QIeI0ioHDY/2SReCeFnYZJYz9kfk11RrilUbT5BgIi1hOAQ24LMilS37NhHYyi9VPv6rX4WLKoZCmkeYaWk/TR54nbH1E/AkniwRoXpeh6VncwWMuMsL5qPWGY8fuuTE27GhwqBiKQGBOmU+MYlZonOO0xnAKpAvysMy7G7qQIDAQAB-END PUBLIC KEY-

Now, with the key pair, the digital signature is easy-- in this case, the source file client.c is the artifact to be signed:

Openssl dgst-sha256-sign privkey.pem-out sign.sha256 client.c

The summary of the client.c source file is SHA256, and the private key is in the privkey.pem file created earlier. The resulting binary signature file is sign.sha256, which is an arbitrary name. To get a readable version of the file (such as base64), the subsequent command is:

Openssl enc-base64-in sign.sha256-out sign.sha256.base64

The file sign.sha256.base64 now contains the following:

KKSlWKIk34fQ1g91XKHOGFRmjc0ZHPEyyjP6! lJ05SfjpAJxAPm075VNfFwysvqRGmL0jkpqGmL0jkp2TdwnDTwt756Ej4X3OwAVeYM7i5DCcjVsQf5Jingh7JycHKlMomp Jd3kUWUkZ8roomLk0ZwzzzhKJu6LM5KWtLLhJ2pVc=

Alternatively, the executable client can also be signed, and the resulting base64-encoded signature will be different as expected:

VMVImPgVLKHxVBapJ8DgLNJUKb98GbXgehRPD8o0ImADhLqlEKVy0HKRm/51m9IXxRAN7DoL4Q3uuVmWWi749Vampong/uT5qjgVNTnRt9jON112fzchgEoMb8CHNsCTXIMdyaPtnJZdLALw6rwMM55MoLamSc6M/MV1OrJnk/g=

The final step in this process is to verify the digital signature with the public key. As an important step in verification, the hash value used to sign the artifact (in this case, the executable client program) should be recalculated, because the verification process should indicate whether the artifact has changed after signing.

There are two OpenSSL commands for this purpose. The first command is to decode the base64 signature.

Openssl enc-base64-d-in sign.sha256.base64-out sign.sha256

The second is to verify the signature:

Openssl dgst-sha256-verify pubkey.pem-signature sign.sha256 client

The output of the second command should look like this:

Verified OK

To understand what happens when validation fails, a short but useful exercise is to replace the executable client file in the last OpenSSL command with the source file client.c, and then try to verify it. Another exercise is to change the client program, no matter how slight, and then try again.

Digital certificate

The digital certificate digital certificate brings together the parts analyzed so far: hashes, key pairs, digital signatures, and encryption / decryption. The first step in a production certificate is to create a certificate signing request certificate signing request (CSR) and then send it to the certificate authority certificate authority (CA). In the case of OpenSSL, to do this, run:

Openssl req-out myserver.csr-new-newkey rsa:4096-nodes-keyout myserverkey.pem

This example generates an CSR document and stores it in the file myserver.csr (base64 text). The purpose here is: the CSR document requires CA to guarantee the identity associated with the specified domain name, which is what CA calls the common name common name (CN).

Although an existing key pair can be used, this command also generates a new key pair. Note that the use of server in names such as myserver.csr and myserverkey.pem implies a typical use of digital certificates: as an identity guarantee for Web servers associated with domain names such as www.google.com.

However, using the same command creates a CSR regardless of how the digital certificate is used. It also starts an interactive question / answer session that prompts for information about the domain name to connect to the requester's digital certificate. This interactive session can be done by providing basic information in the command and continuing the line with a backslash. -the subj flag provides the required information.

% openssl req-new\-newkey rsa:2048-nodes-keyout privkeyDC.pem\-out myserver.csr\-subj "/ C=US/ST=Illinois/L=Chicago/O=Faulty Consulting/OU=IT/CN=myserver.com"

The resulting CSR file can be checked and validated before being sent to CA. This process creates a digital certificate with the desired format (such as X509), signature, validity, and so on.

Openssl req-text-in myserver.csr-noout-verify

This is a fragment of the output:

Verify OKCertificate Request:Data:Version: 0 (0x0) Subject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.comSubject Public Key Info:Public Key Algorithm: rsaEncryptionPublic-Key: (2048 bit) Modulus:00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73: … Exponent: 65537 (0x10001) Attributes:a0:00Signature Algorithm: sha256WithRSAEncryption... Self-signed certificate

In the process of developing a HTTPS website, it is convenient to have a digital certificate on hand that does not have to go through the CA process. During the authentication phase of the HTTPS handshake, the self-signed certificate self-signed certificate can meet the requirements, although any modern browser will warn that such certificates are worthless. To continue this example, the OpenSSL command for the self-signed certificate (valid for one year, using the RSA public key) is as follows:

Openssl req-x509-sha256-nodes-days 365-newkey rsa:4096-keyout myserver.pem-out myserver.crt

The following OpenSSL command renders a readable version of the generated certificate:

Openssl x509-in myserver.crt-text-noout

This is part of the output of the self-signed certificate:

Certificate:Data:Version: 3 (0x2) Serial Number: 13951598013130016090 (0xc19e087965a9055a) Signature Algorithm: sha256WithRSAEncryptionIssuer: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT, CN=myserver.comValidityNot Before: Apr 11 17:22:18 2019 GMTNot After: Apr 10 17:22:18 2020 GMTSubject: C=US, ST=Illinois, L=Chicago, O=Faulty Consulting, OU=IT CN=myserver.comSubject Public Key Info:Public Key Algorithm: rsaEncryptionPublic-Key: (4096 bit) Modulus:00:ba:36:fb:57:17:65:bc:40:30:96:1b:6e:de:73:...Exponent: 65537 (0x10001) X509v3 extensions:X509v3 Subject Key Identifier:3A:32:EF:3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91X509v3 Authority Key Identifier:keyid:3A:32:EF: 3D:EB:DF:65:E5:A8:96:D7:D7:16:2C:1B:29:AF:46:C4:91 X509v3 Basic Constraints: CA:TRUESignature Algorithm: sha256WithRSAEncryption 3a:eb:8d:09:53:3b:5c:2e:48:ed:14:ce:f9:20:01:4e:90:c9:...

As mentioned earlier, the RSA private key contains values that are used to generate the public key. However, a given public key does not disclose the matching private key. For an introduction to the underlying mathematical theory, see https://simple.wikipedia.org/wiki/RSA_algorithm.

There is an important correspondence between the digital certificate and the key pair used to generate the certificate, even if the certificate is self-signed:

Digital certificates contain exponents and modular values that make up the public key. These values are part of the key pair in the originally generated PEM file, which in this case is the file myserver.pem.

Index exponent

It is almost always 65537 (as in this case), so it can be ignored.

Key pair

Modular modulus

Should match the modulus of the digital certificate.

The modulus is a large value, and hashing can be done to make it easier to read. Here are two OpenSSL commands that check the same modulus to confirm that the digital certificate is based on the key pair in the PEM file.

% openssl x509-noout-modulus-in myserver.crt | stdin in openssl sha1 # # certificate = 364d21d5e53a59d482395b1885aa2c3a5d2e3769% openssl rsa-noout-modulus-in myserver.pem | stdin in openssl sha1 # # key = 364d21d5e53a59d482395b1885aa2c3a5d2e3769

The resulting hash matches, confirming that the digital certificate is based on the specified key pair.

Back to the issue of key distribution

Let's go back to the question raised at the end of the first part: the TLS handshake between the client program and the Google Web server. There are many handshake protocols, and even the Diffie-Hellman version used in the client example has different ways. Nevertheless, the client example follows a common pattern.

First, during the TLS handshake, the client program and the Web server agree on the cipher suite cipher suite, including the algorithm to be used. In this case, the suite is ECDHE-RSA-AES128-GCM-SHA256.

The two elements of concern now are the RSA key pair algorithm and the AES128 block cipher, which are used to encrypt and decrypt messages with a successful handshake. With regard to encryption / decryption, there are two schools of this process: symmetric symmetric and asymmetric asymmetric. In symmetric schools, encryption and decryption use the same key, which first leads to the key distribution problem key distribution problem. How to securely distribute the key to both parties? In an asymmetric school, one key is used for encryption (in this case, the RSA public key), but the other key is used for decryption (in this case, the RSA private key from the same pair of keys).

The client program has the public key of the Google Web server that authenticates the certificate, while the Web server has the private key from the same pair of keys. Therefore, the client program can send encrypted information to the Web server, and the Web server can decrypt the communication separately.

In the case of TLS, the symmetrical approach has two significant advantages:

In the interaction between the client program and the Google Web server, authentication is one-way. The Google Web server sends three certificates to the client program, but the client program does not send the certificate to the Web server, so the Web server does not have a public key from the client and cannot encrypt the message sent to the client.

Symmetric encryption / decryption using AES128 is nearly a thousand times faster than asymmetric encryption / decryption using RSA keys.

The TLS handshake skillfully combines the two encryption / decryption methods. During the handshake, the client program generates random bits, called pre-master secret pre-master secret (PMS). Then, the client program encrypts the PMS with the server's public key and sends the encrypted PMS to the server, and the server decrypts the PMS information with the private key of the RSA key pair:

+-+ encrypted PMS +-+ client PMS--- > | server's public key |-> | server's private key |-- > server PMS +-+- -+

At the end of this process, the client program and the Google Web server now have the same PMS bits. Each party uses these bits to generate a master password master secret and immediately generates a symmetric encryption / decryption key called the session key session key. There are now two different but equivalent session keys, one for each side of the connection. In the case of client, the session key is of class AES128. Once the session key is generated on both sides of the client program and the Google Web server, the session key on each side will keep the conversation secret. If either party (for example, the client program) or the other party (in this case, the Google Web server) requests to restart the handshake, a handshake protocol (such as Diffie-Hellman) allows the entire PMS process to be repeated.

This is the end of this article on "how linux uses OpenSSL". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.