Abstract: There is a rule mentioned in many security specifications and security articles: first encrypt and then sign is not safe, you should sign first and then encrypt. What is the rationale behind this rule? Is it necessarily insecure to encrypt first and then sign? This article answers them one by one for you.
Sign first and then encrypt means to sign the message first, and then encrypt the signature value of the message and the message together. If the method of first encrypting and then signing is adopted, the receiver can only know that the message was sent by the signer, but it cannot determine whether the signer is the creator of the message. For example, if an authentication credential is encrypted first and then signed, the message may be intercepted by a third party during the sending process and the signature value of the ciphertext of the authentication credential will be changed to its own signature, and then sent to the receiver. It is possible for a third party to gain access through authentication in this way without knowing the authentication credentials.
This kind of problem can be avoided by adopting the method of signing first and then encrypting, because it can only be signed if the plaintext of the message is known.
Although there are differences in the descriptions of different specifications, the core point of view is “sign first and then encrypt”. But what is the applicable scenario of this specification? Is “encrypt first and then sign” necessarily insecure? Need to dig a little deeper.
If “encrypt first and then sign” is used, the processing process of the message sender Alice and the message receiver Bob is as follows:
The plaintext message sent by Alice is first signed by Alice’s private key, and then the plaintext of the message and the message signature are encrypted with Bob’s public key, and the ciphertext is transmitted to Bob through the network. Because Bob uses the private key to decrypt and restore the plaintext and signature of the message, and the private key is only held by Bob, which can ensure that the plaintext of the message will not be leaked to the third party Eve, and then Bob uses Alice’s public key to verify whether the plaintext of the message is consistent with the signature, because Alice’s signature can only be verified by Alice’s public key, which ensures that the message must come from Alice, is undeniable, and has not been tampered with by the third party Mallory. If the plaintext of the message cannot be obtained, the message signature cannot be calculated, and Bob’s private key must be used to restore the plaintext of the message, so as to prevent tampering attacks by man-in-the-middle during network transmission.
If “encrypt first and then sign”, what kind of attack risk will there be? Let’s first look at the processing flow of “encrypt first and then sign”:
The plaintext of the message is encrypted with Bob’s public key, so it is impossible to leak it to a third party. The signature is also available, which can prevent tampering. If you don’t look carefully, there seems to be no problem. Continue to look at the picture below:
If there is a middleman Mallory who can intercept Alice and Bob’s message, without tampering with the message plaintext and ciphertext, use Mallory’s private key to sign the message ciphertext, and replace Alice’s original signature, and finally the tampered message transmission To the receiver Bob, Bob can still successfully decrypt the plaintext, and at the same time successfully verify the signature with Mallory’s public key, and finally this message will be considered by Bob as a legitimate message sent by Mallory.
Is “encrypt first, then sign” necessarily insecure?
From the demo above, it seems that “encrypt first, then sign” must be insecure, is it so? The prerequisites for the success of Mallory’s replacement signature attack against “encrypt first and then sign” are 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 to verify the identity of the sender.
As long as any one of the above premises is broken, “encrypt first and then sign” is also safe:
1. Bob uses a fixed public key to verify the signature, instead of finding the corresponding public key based on the content of the signature, or does not use multiple public keys to try to verify the signature. That is, after Mallory replaces the signature, Bob still uses Alice’s public key to verify the signature, and he can definitely find that the request has been tampered with.
2. Bob uses the public key + application layer attributes to identify the identity of the sender. Suppose Alice carries her own user ID in the message plaintext, and Bob verifies whether the public key and user ID match. Even if Mallory replaces the signature, it cannot be attacked.
Therefore, whether “encrypt first and then sign” is safe depends on how the business application is designed, and it cannot be absolutely regarded as unsafe.
This article is shared from HUAWEI CLOUD community “Thoughts on “Sign first and then encrypt””, the original author: Canon.