Symmetric encryption

Features: symmetric encryption is characterized by encryption and decryption through the same key.

For example, we need to encrypt a set of numbers

A set of numbers: 12345

Key: 10

Algorithm: original number multiplied by key

Encrypted result: 123450

The decryptor also gets the original number 12345 by dividing 123450 by 10. Of course, neither the algorithm nor the key is so simple.

Disadvantages: one of the inconveniences of symmetric encryption is the distribution of the key, because when a sends an encrypted letter to B, B must know the key to read the letter, but how to transfer the key? If you pass the key through an unencrypted letter, it's easy to intercept.

Common pairing encryption algorithms: DES, 3DES, RC5

Asymmetric encryption

Non pairing encryption has a pair of keys, private keys and public keys. When one is used for encryption, the other must be used for decryption. In this way, the problem of key distribution is solved. The public key can be distributed at will. The public key is known to all. Only the private key holder can have the private key.

When a needs to send a letter to B, it encrypts the letter with B's public key, and then sends it to B. only B has a private key, so only B can read the letter. In this way, even if other people know the public key, they can't see the content of the letter.

But asymmetric encryption has a disadvantage, that is, it needs complex calculation, which costs a lot of CPU, and the key of asymmetric encryption is usually very long, 1024 bit or 2048 bit. So generally, asymmetric encryption algorithm is not used to encrypt data, only encryption key (symmetric encryption key). The actual encryption process is still symmetric encryption.

Common pairing encryption algorithms: Diffie Hellman, RSA

RSA algorithm is a very common algorithm. For hardware decoding, des symmetric algorithm is 1000 times faster than RSA.

In exchange 2007, when using new exchangecertificate to request a certificate, you can use the parameter keysize, which specifies the size (bits) of the RSA public key associated with the certificate to be created.

Acceptable values are 4096, 2048, and 1024. The default is 2048.

As can be seen in the figure below, the public key of the certificate uses RSA algorithm, and the length of the public key is 1024 bits for encryption

Hash

Hash is used to ensure that a piece of data is not changed and the integrity of data. Because the possibility of duplicate value obtained by hash is very small, it can be considered that the result obtained by hashing a piece of data is a unique result, and there will be no other data hash value and it will be duplicate.

For example, if a sends a letter to B, then in order to ensure that the letter will not be changed, a will hash the data of the letter and send the hash result together with the letter to B. after B receives the letter, it will hash the data of the letter. If the result is the same as a, it means that the letter has not been changed.

A good hash algorithm, when there is a change in a piece of data, will cause a big change in the hash value.

Common hash algorithms: MD5 (message digest), Sha or SHA1 (secure hash algorithm)

A certificate is also a file, a piece of data. In order to maintain the integrity of the certificate, the certificate also has a hash value.

Open the certificate, we can see the hash algorithm and hash value of the certificate. We can also use get exchangecertificate to get the thumbprint

Microsoft provides a small tool to verify the MD5 and SHA1 hash values of files. See kb889768 for details

MS CA can choose hash algorithm when applying for certificate

digital signature

We can add our own digital signature to an email. If you receive an email with a digital signature, the digital signature indicates that the email really comes from the sender and the content of the email has not been changed.

The digital signature encrypts the hash value of the message with its own private key, and then sends it to the recipient.

Asymmetric encryption is still used here, because only one person has a private key. When he encrypts with the private key and the corresponding public key can be decrypted, this email can prove that it really comes from the sender. Because asymmetric encryption consumes a lot of resources, we can't encrypt the body of the message. We just need to encrypt the hash code of the body.

When user B receives the e-mail with digital signature sent by A, B first finds the public key of A, and then tries to use the public key A to solve the encrypted hash value in the e-mail. If the solution is opened, it is proved that the e-mail is indeed sent from A. Then hash the message body. If the result is consistent with the hash value in the message, it means that the message has not been changed.

Image: digitally signed message

Figure: the signed certificate and the encrypted certificate cannot be the same. The signed certificate uses its own private key, while the encrypted certificate uses the public key of the other party.

certificate

Why use certificates?

For example, when B transmits data to a, B first encrypts the data with a's public key, and then sends it to a. a decrypts it with its private key.

But there is a problem. C is a villain. He claims to be a, and then sends the public key of false a to B. B encrypts the data with the public key of false a, and then sends it to false A. there is no doubt that C gets the data.

Now the problem is how to prevent C from claiming to be a. the solution is to use certificate.

B trusts the certification authority D and D to prove that a is indeed a and D issues a certificate to a. the name of a and its public key are listed in the certificate. B sees the certificate of a and finds that it trusts the certification authority. Then it can use the public key shown in the certificate to encrypt the data and send it to a.

Because C can't pass the certification authority D's verification, it can't get the certificate, so it can't impersonate a.

Figure: certificate is used to ensure the identity of the remote computer

Certificate creation process

1. First, there is an application to generate a pair of keys: public key and private key.

In exchange 2003, we use the wizard in IIS to apply for a certificate. The wizard creates a public key and a private key. In exchange 2007, we use new exchange certificate to apply for certificates, which also creates public and private keys.

2. Send information to certification authority (CA)

The certification authority needs some information to verify your identity, or the identity of the website, and it also needs the public key you generate. The CA does not need your private key. After verification, it is proved that you are indeed the real identity, or the name of your website is real, you can issue the certificate.

3. The CA signs the certificate and issues the certificate, so that all clients who trust the CA will think your certificate is valid and can use the above public key.

In exchange 2007, a common mistake is to run new exchangecertificate on the hub or other machines. When obtaining the certificate from the Ca, import the certificate import exchangecertificate on the edge. At this time, the private key will be lost. The reason is that edge is not the same computer that ran the new exchange certificate command

Figure: the process of applying for a certificate creates a public key and a private key

How SSL works

SSL (secure socket layer) is developed by Netscape for encrypted communication between browser and web server. When you visit an HTTPS site, SSL protocol works.

TLS (transport level / Layer Security) is developed based on SSL. We can understand that TLS is the SSL used to encrypt SMTP communication. SSL can be used to encrypt HTTP, POP3, IMAP, nttp and LDAP and many other protocols.

• When you enter the URL that begins with HTTPS in your browser, an SSL request is made to the web server.
• The server sends its own certificate to the client (remember that the certificate contains the public key)
• The client browser verifies the certificate (see if it is a trusted certificate, whether it has expired, whether it has been revoked, and whether the name on the certificate is the same as the one it accesses?)
• The client browser generates a random session key and encrypts it with the server's public key.
• Client browser sends encrypted session key to web server
• The web server decrypts the session key with its own private key
• In this way, both the client and the server know the session key
• Later calls are encrypted with session key

This is also the process when services such as POP3 are encrypted.

Figure: HTTPS is SSL encrypted HTTP communication

TLS is developed on the basis of SSL 3.0. It is worth noting that although the two processes are similar, they are not compatible. Of course, the process of communication is not so simple. Please refer to the article for the process of handshake, encryption and hash

View communication without SSL encryption

If there is no SSL encryption, the mail communication is easy to be intercepted. We can use some sniffers to get the communication content

HTTP: Base64

SMTP: Base64

POP3: Plain Text

IMAP: Plain Text

Figure: if POP3 is not encrypted, what the sniffer catches is clear text. The user name and password can be seen directly.

Figure: SMTP plaintext delivery is Base64 encoded.

The auth login description is basic authentication, and the password is sent in clear text. We can find a base 64 encoded website to convert the base 64 encoding into clear text.

For example, visit http://www.hcidata.co.uk/base64.htm

 

Figure: input Base64 code vxnlcm5hbwu6 to convert it to ASCII code: Username:

TLS encrypted SMTP

After installing the certificate on the default SMTP virtual directory, you can use the encrypted connection. After Telnet, you will find the TLS and starttls commands.

Encrypt Mapi RPC

RPC Protocol is used to communicate with outlook and exchange in the domain. RPC has a default encryption mechanism. We can select encrypted communication in outlook account properties.