Is this a secure Digital Signature + Encryption method?

Question

I am trying to wrap my head around Digital Signatures and how RSA Encryption supports them. And which order to do them along with what specifically to encrypt.

So say we have Alice and Bob and a Secret message M

Alice has: Bob's Public Key(B_pk), Alice's secret key (A_sk), Alice's Public Key (A_pk)

Bob Has: Bob's Public Key(B_pk), Bobs's secret key (B_sk), Alice's Public Key (A_pk)

1. Alice generates a SHA256 hash of the message M. SHA256(M)

2. Encrypt the resulting hash with Alice's secret key using RSA. C1 = RSA(A_sk,SHA256(M))

3. Then Encrypt M with Bob's public key. C2 = RSA(B_pk,M)

4. Send C1 to Bob

5. Send C2 to bob
6. Bob gets C1, Decrypts with Alice's public key resulting in SHA256(M)_received
7. Bob gets C2, Decrypts with his secret key, resulting in M_received
8. Bob then runs SHA256(M_received) and checks if SHA256(M_received) == SHA256(M)_received

Are there any flaws in this method? Is Confidentiality, Integrity, and Authenticity protected?

Update: I am curious as to what the weaknesses are in the above method.

Answer 1

The order is important. Encrypt the message to the receiver then sign the message. Receiver can verify signature and then decrypt.

The other way (sign then encrypt) means that Bob (receiver) can send someone else Alice's (sender) the signed message without her knowledge or agreement as if it came from someone else (decrypts with his key, re encrypts with 3rd key).

By doing encrypt and sign, it's clear that Alice meant the message for Bob.

The idea is that no one else can sign the encrypted message and no one else can decrypt the signed message.

Also, if Bob needs to show what Alice signed (the message is a contract), the encryption algorithm should be symmetric like AES and Bob reveals the key. It's the symmetric key that Alice encrypts with Bob's public key. So, there are two encryptions: symmetric, asymmetric and a signature.

Answer 2

First, include a timestamp with each message (use JSON format for simplicity) along with any other information you want to check against for security or identification purposes. Then, encrypt the hash of each message using the private key. Append the hash to the end of the message. Say Alice sends her signed message to Bob. Bob takes the encrypted hash and attempts to decrypt it with Alice's public key. If the decryption fails, the message cannot be trusted. Furthermore, if the decrypted hash does not match a re-calculated hash, do not trust the file. Only trust if all checks pass.

If you want the entire message to be encrypted, encrypt it using a symmetrical encryption algorithm using a generated CSPRNG as the key. Then take the CSPRNG and encrypt it using the recipient's public key. Include encrypted CSPRNG with the encrypted message to be signed. After the recipient verifies the signature, they can simply decrypt the encryption key using their private key, and can therefore decrypt the message inside as-well. But make sure to always encrypt before you sign. Best practices and all.

I would also like to point out that the more you use a private key to sign something that has the potential of being compromised, you increase the potential of your private key being compromised as-well (depending on the CSPRNG used internally for encryption). So if you're having many communications, I would recommend implementing an HMAC scheme over-top and using that whenever possible (as opposed to purely using digital signatures utilizing asymmetrical encryption). If not for security maybe at least for efficiency.