Absrtact: a rule is mentioned in many security specifications and articles: it is not safe to encrypt before signing, so we should sign before encrypting. What is the principle behind this rule? Is it not safe to encrypt before signing? This article answers for you one by one.

Signature before encryption means to sign the message first, and then encrypt the signature value of the message together with the message. If encryption before signature is adopted, the receiver can only know that the message is sent by the signer, but can not determine whether the signer is the creator of the message. For example, when sending an authentication credential, the message may be intercepted by a third party in the process of sending, and the signature value of the authentication credential ciphertext is modified to its own signature, and then sent to the receiver. It is possible for the third party to obtain permission through authentication in this way without knowing the authentication credentials.

This kind of problem can be avoided by using the method of signature before encryption, because the message can only be signed when the plaintext is known.

Although different specifications have different descriptions, the core idea is “signature before encryption”. But what is the applicable scenario of this specification? Is “encryption before signature” not necessarily secure? We need to dig deeper.

If “Encrypt before sign” is used, the process of Alice and Bob is as follows:

The plaintext message sent by Alice is first signed by Alice’s private key, then the plaintext message and the message signature are encrypted by Bob’s public key, and the ciphertext is transmitted to Bob through the network. Bob uses the private key to decrypt and restore the message plaintext and signature, and only Bob holds the private key, which can ensure that the message plaintext will not be disclosed to Eve. Then bob uses Alice’s public key to verify whether the message plaintext and signature are consistent, because Alice’s signature can only be verified by Alice’s public key, which can ensure that the message must come from Alice and cannot be repudiated, And it has not been tampered by Mallory, a third party. In the case of not getting the message plaintext, we can not calculate the message signature, and restore the message plaintext must use Bob’s private key, which can prevent the middleman from tampering in the process of network transmission.

If “Encrypt before sign”, what kind of attack risk will exist? Let’s take a look at the processing flow of “Encrypt before sign”

The message plaintext is encrypted with Bob’s public key, which can’t be leaked to a third party. The signature is also available, which can be tampered with. If you don’t look carefully, it seems that there is no problem. Let’s continue with this picture

If there is a middleman Mallory who can intercept the messages of Alice and Bob, Mallory’s private key is used to sign the message ciphertext without tampering with the plaintext and ciphertext of the message, and Alice’s original signature is replaced. Finally, the tampered message is transmitted to Bob, the receiver, and Bob can decrypt the plaintext successfully. At the same time, Mallory’s public key is used to verify the signature, Eventually, this message will be considered by Bob as a legitimate message sent by Mallory.

**“Encrypt before sign” is not safe**

From the above demonstration, “Encrypt before sign” does not seem to be secure, is it? The prerequisite for successful substitution signature attack of middleman Mallory against “Encrypt before sign” is as follows:

1. The receiver Bob finds the corresponding Mallory public key according to the certificate ID in the signature content to verify the signature.

2. The receiver Bob only uses the public key signature to identify the sender.

As long as any of the above premises is broken, “Encrypt before sign” is also safe

1. Bob uses a fixed public key to verify the signature, instead of finding the corresponding public key according to the content of the signature, or does not use multiple public keys to verify the signature. That is to say, after Mallory replaces the signature, Bob still uses Alice’s public key to verify the signature, and it is sure to find that the request has been tampered.

2. Bob uses the public key and application layer attributes to identify the sender. Assuming that Alice carries her user ID in the message plaintext, Bob verifies whether the public key and user ID match. Even Mallory’s replacement signature cannot be attacked.

Therefore, whether “encryption before signature” is secure depends on how the business application is designed. It can not be absolutely considered as insecure.

This article is shared from Huawei cloud community “thinking about” signing before encrypting “, original author: canon.

**Click follow to learn about Huawei’s new cloud technology for the first time~**