I'm trying to figure out which is the best way to get privacy and integrity together in public cryptography.

Alice needs to send multiple files $f$ (may be big) to Bob.

I've thought:

Alice computes the hash of the file $h(f)$.

Alice signs $h(f)$ with her private key.

Alice encrypts with Bob's public key $f$ and $Sig_a(h(f))$ resulting in the ciphertext $Enc_b(f, Sig_a(h(f)))$.

Only Bob can decrypt with his private key: privacy guaranteed. Once Bob decrypted, can verify Alice's signature.

In my opinion this protocol provides privacy and integrity together, right?


So, according to your answers, here's what i've understood:

  1. The protocol is terribly inefficient because it encrypts a large file using public cryptography. This would require to split the file in n chunks ($f_1,f_2,...f_n$) and to send to Bob $Enc_b(f_i, Sig_a(h(f_i)))$ for i = 1 to n. This may require a padding.
  2. A bad guy (Charles) that receives $Enc_c(f, Sig_a(h(f)))$ could decrypt it and re-encrypt it with Bob's public key and send it to Bob. No confidentiality.
  3. In order to fix this, Alice should perform $Enc_b(f,A,Sig_a(h(f),B))$

At this point we can say that:

  1. This protocol (as it is) MAY (depends on how it is implemented in practice) guarantee integrity.
  2. I would use Diffie-Hellman key-exchange protocol (the ephemeral version) to estabilish a secure channel and use symmetric cryptography.

Update 2

Not even integrity is guaranteed. I've seen the so called "message malleability".


2 Answers 2


Signing and encrypting together is not secure in this method, at least in the way most would perceive security. For example, Bob would likely interpret this message as being sent from Alice to Bob. However, Alice may have sent it to Charles who decrypted and re-encrypted the signed message under Bob's public-key. In order to do this securely, you need to add the sender's and receiver's identities inside (the signature with Alice's key should contain Bob's identity, and the encryption with Bob's key should contain Alice's identity). In addition, you need to use CCA-secure encryption. In short, this isn't so simple and you need to check the details in order to determine if it's secure. This topic is called "SignCryption" and you can look it up for more information.


Instead of trying to invent your own protocol, you'd be much better off using something that is already out there. For example, you could use TLS to transport the data. Another option would be to use GnuPG and some other transport mechanism (post the file on a website to be downloaded by Bob, send it via email, etc).

Now, to your question of does this provide privacy and integrity together. The answer is, it is too hard to tell from your description. You would need a much more complete specification.

First, I'm assuming that by privacy you really mean confidentiality. Your basic protocol is to sign a hash of the file and then encrypt both the file and the signed hash. This is where things start to break down. We never use public key crypto for bulk encryption. So, I hope when you have encryption of the file (which could be very large) and the signed hash with Bob's public key, what you really mean is that you are encrypting a symmetric (say AES-128) key with Bob's public key and encrypting the file and the digital signature with that symmetric key. See, this is why it is best to start with something that already exists. GnuPG does all this for you. Use it and you've reduce the problem to one of key distribution (how do you get Bob's public key and how does Bob get yours) and transportation.

  • $\begingroup$ I've just to analyze that protocol as it is. For encryption/decryption the protocol uses public cryptography. So i have no choice. Encryption with Bob's public key, decryption with his private key. Once analyzed, i could suggest a different approach that uses symmetric cryptography. $\endgroup$
    – Loris
    Commented Aug 27, 2015 at 15:56
  • $\begingroup$ @Loris, but how are they encrypting large files with, I'm assuming, RSA? With RSA, if the modulus is only 2048 bits, you would have to break a large file into small chunks to encrypt. Are they using padding of any sort? All of these things will affect the security of the protocol, which is another reason to use a standard method (though it sounds like at the moment, this isn't up to you). $\endgroup$
    – mikeazo
    Commented Aug 27, 2015 at 16:08
  • $\begingroup$ I have no such information. I've been asked to answer that question as it is. The file can be very large but it is both hashed and signed prior to encryption. If it is impossible to answer, then i'm sorry. $\endgroup$
    – Loris
    Commented Aug 27, 2015 at 16:35
  • $\begingroup$ @Loris, unfortunately, without that type of information it is impossible to answer. There are ways it could be done and provide confidentiality and integrity (but be very, very slow) and there are ways it could be done that completely destroys confidentiality. $\endgroup$
    – mikeazo
    Commented Aug 27, 2015 at 16:45
  • $\begingroup$ Ok then, which are these ways? If i can ask.. :) $\endgroup$
    – Loris
    Commented Aug 27, 2015 at 18:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.