Assume that Alice has a file F which she is going to send, in encrypted form, to Bob. Alice possesses F and the public encryption key K of Bob in form of an X509-certificate. She generates the file E using the encryption algorithm CNT_3DES, BitsInKey = 192 (RSA PKCS#1 encryption method). She sends to Bob the file E through a certified mail system which will get a digital signature and a time stamp from an external authentication authority. Therefore it is possible to include in the body of the mail any information, including hash codes, that will be accepted as well known before the creating time of the mail.

After some time Alice has to proof to Mike that the file E send to Bob has the same content of the file F. But Mike does not have the private key of Bob for decrypting the file. And encrypting the file F now produces a different file than E since encryption adds a random padding on encryption stage. How can this proof be given from Alice to Mike? As explained, it is possible to include in the body of the mail any useful information that will be necessary for this proof.

I hope that I explained my problem in a sufficiently clear way. And sorry for my poor English.

  • $\begingroup$ Can't Alice simply give the symmetric key to mike? $\endgroup$ Jul 26, 2016 at 15:13
  • $\begingroup$ If she can, can she also give the RSA random padding to Mike? ​ ​ $\endgroup$
    – user991
    Jul 26, 2016 at 15:15
  • $\begingroup$ @CodesInChaos Ah, saw that comment just when I posted :) $\endgroup$
    – Maarten Bodewes
    Jul 26, 2016 at 15:30
  • $\begingroup$ @RickyDemer Interesting, maybe I'm overseeing something? Why do you need the random padding? To try and generate the same encrypted value to show that the right symmetric key was used? In that case a MAC might also be used maybe? $\endgroup$
    – Maarten Bodewes
    Jul 26, 2016 at 15:32
  • $\begingroup$ @MaartenBodewes : ​ ​ ​ You need the random padding to show "that the file E send to Bob has the same content of the file F". ​ (For example, what's the "content" of a MAC mismatch?) ​ ​ ​ ​ ​ ​ ​ ​ $\endgroup$
    – user991
    Jul 26, 2016 at 16:10

2 Answers 2


Retaining the 3DES encryption key would probably do it. Now simply use the same IV as before and encrypt the file; the IV is only random when it is initially chosen. Alice could also encrypt the key and store it together with the message.

You'd have to prove that you used the same key. That's no problem for larger messages in CBC mode where the possible plaintext is known, but for good measure, I'd include a MAC over the IV and ciphertext in the mail header.

Alternatively, and possibly better than using a MAC, is to transmit the random padding with the message and store the secret key. That way you can regenerate the wrapped key by pairing the padded key with a raw RSA operation, proving that it was that specific key you used.

It might be better in the sense that creating a covert channel is harder if all the information is shown to Mike. It has the drawback that it requires access to raw RSA operation, which may not be directly available to you.

  • 1
    $\begingroup$ If Alice doesn't want to save it, she could attach it to the message in encrypted form (that she can decrypt using one of her long term keys) $\endgroup$ Jul 26, 2016 at 15:47
  • $\begingroup$ @Bodewes: you talk about IV. This is Initialization vector? When yes, the idea would be OK (that could work for us, with the IV Alice could regenerate an identical file E starting from F and that would be the proof that Alice is searching for). But, we asked Eldos - the producer of the tools which we us to generate the file E). The answer was: "What you asking for is a violation of the standard, and also a security weakness". The full question and answers: eldos.com/forum/read.php?FID=7&TID=6050 $\endgroup$ Jul 28, 2016 at 11:00
  • $\begingroup$ If you are bound to use their software as it is, then you won't be able to do that. Another way (which they might also consider a violation of the standard) would be that you can assign an IV optionally. Then you choose the IV, and they will use it in the encryption process, and if you provide the same IV again, you get the same encrypted file. But most likely, that will also be declined, since using the same IV can cause security weaknesses. $\endgroup$
    – tylo
    Aug 26, 2016 at 10:25

You say that you're using 3DES, which is a symmetric secret-key encryption method, but also that you're encrypting the file using Bob's public key (for, presumably, some asymmetric cryptosystem like RSA). This suggests that you are (or the software you're using is) actually using hybrid encryption, where you first generate a random symmetric 3DES key, encrypt the file E with that key, and then encrypt the key with Bob's public key.

Given this, a simple way for Alice to prove that the encrypted file E sent to Bob was actually created using the plaintext file F is for her to save the random 3DES key K used to encrypt the file, and hand it over to Mike. Mike can then decrypt the file E sent to Bob using the key K, and compare it with the known plaintext F.

A subtlety here is that this doesn't prove that K was the encrypted key that Alice sent to Bob. However, as long as the messages are reasonably long, coming up with two 3DES keys that would decrypt the same ciphertext to two different meaningful plaintexts is pretty difficult (especially if one of the plaintexts is fixed in advance). So, in practice, if Alice did send some key other than K to Bob, all Bob would get when decrypting E would be random gibberish (and if the ciphertext E included a MAC for integrity protection, it would almost surely fail to validate).

If Alice does wish to prove that she didn't send random gibberish to Bob, things get trickier. In general, any secure public-key encryption scheme must be non-deterministic, so Mike cannot simply re-encrypt K with Bob's public key and compare it with the encrypted key sent by Alice.

However, if Alice also stores all the random inputs used in the process of encrypting K, then she can also provide those to Mike, and thus allow him to confirm that the encrypted key sent by Alice to Bob is indeed a valid encryption of the 3DES key K (and, therefore, that K is what Bob would have received when he decrypted it using his private key).


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.