Safely use CryptSignAndEncryptMessage?

Question

I am developing an application that sends messages which I want to encrypt and sign. The CryptoApi offers a function called CryptSignAndEncryptMessage. The description says, what this function actually does:

The CryptSignAndEncryptMessage function creates a hash of the specified content, signs the hash, encrypts the content, hashes the encrypted contents and the signed hash, and then encodes both the encrypted content and the signed hash. The result is the same as if the hash were first signed and then encrypted.

If I understood correctly, this solution could be susceptible to an attack called surreptitious forwarding?

Surreptitious forwarding uses the naive "sign and encrypt" approach to allow B to forward a message of A, destined to B, to a third party C and make C think the message was from B, destined to C (although it was from A to B, and just forwarded by B). This is possible because B can decrypt the signed message and re-encrypt it for C. However, although a message can be forwarded "illegally", the actual message content cannot be changed.

Does this in turn mean, if I include the receiver in the signed data, I am not susceptible to this attack?

Answer 1

If I understood correctly, this solution could be susceptible to an attack called surreptitious forwarding?

If CryptSignAndEncryptMessage is implemented in the naive way, then it would seem that it is vulnerable to a forwarding attack. Microsoft has not published the exact details (AFAIK), so it is difficult to tell for sure.

Does this in turn mean, if I include the receiver in the signed data, I am not susceptible to this attack?

There is a published recommendation done by a few very respectable cryptographers. It is in Section 7 of On the Security of Joint Signature and Encryption, and is along similar lines to what you propose. Specifically, they recommend:

1. Whenever encrypting something, include the identity of the sender $ID_S$ together with the encrypted message.
2. Whenever signing something, include the identity of the receiver $ID_R$ together with the signed message.
3. On the receiving side, whenever either the identity of the sender or of the receiver do not match what is expected, output $\bot$.