I'm using RSA (4096) and AES GCM (256) to exchange messages between A and B. A random key for AES is generated, the plain message is encrypted with AES, and the random AES key is encrypted with Bs public key. The encrypted message and key are sent to person B. Lets assume they use an insecure server, they didnt share a secret offline etc. Is there any way for person B to make sure A sent the message and not a man in the middle?

  • $\begingroup$ If there is an additional voice (not necessarily secure) channel a Short Authentication Tag can be used to verify verbally. $\endgroup$
    – kelalaka
    Sep 17 '19 at 9:43

In what's described, nothing makes B sure that A sent the message. And that can't be obtained without some secret on A's side.

A common solution is to have A sign the (e.g. encrypted) message, and B check the signature.

A PKI (perhaps, implemented using digital certificates) can help ensure B uses A's genuine public key, which is required for this proof or origin to work. It can also help ensure A uses B's genuine public key, which is required for confidentiality is the question's protocol.

  • $\begingroup$ What's stopping the man in the middle to use his own private key to sign the encrypted message since person B wont receive the original signature, but the one created by the MITM? $\endgroup$
    – yejc55
    Sep 16 '19 at 12:43
  • $\begingroup$ @yejc55: A digital signature is checked against a public key. Here the message's signature should be checked against A's public key. Hence the need for B to know A's public key for certain, just like A should know B's public key for certain. $\endgroup$
    – fgrieu
    Sep 16 '19 at 13:52
  • 1
    $\begingroup$ Really instead of "certificates" it should probably say PKI (public key infrastructure) which is commonly created using certificates. Central to the PKI is establishing trust in the certificates and the public keys inside of them. In the end though the idea is that the receiver trusts the correct public key of the entity or entities that are allowed to send messages to him/her. $\endgroup$
    – Maarten Bodewes
    Sep 17 '19 at 13:04

The GCM operation is an authenticated encryption algorithm designed to provide both data authenticity (integrity) and confidentiality. So B can ensure that A is sender.

  • 3
    $\begingroup$ A secure algorithm doesn't make a secure protocol. As anybody can encrypt with the public key from B, it isn't possible to verify that the secret key was generated by A. If the secret key cannot be trusted, then the ciphertext can not be trusted to be from the correct entity either. $\endgroup$
    – Maarten Bodewes
    Sep 17 '19 at 13:00
  • $\begingroup$ AES is an cryptographic algorithm. But AES-GCM is ian authenticated encryption algorithm. AES-GCM uses an authentication tag that can be used to verify the integrity of the data. The encrypted text contains the IV, ciphertext, and authentication tag. $\endgroup$
    – Cao Tuan
    Sep 18 '19 at 1:43
  • 1
    $\begingroup$ @CaoTuan unless the key is previously established in an authenticated manner, the authentication of GCM is meaningless. It only attests that the ciphertext wasn't modified. It provides no guarantee that the ciphertext (and key) were produced by any specific entity. $\endgroup$
    – Maeher
    Sep 18 '19 at 7:22
  • $\begingroup$ Yeah, I was talking about AES-GCM, not just AES. Maybe I should have called it a "scheme" instead of an algorithm. OTOH, GCM is certainly not a protocol, that's higher level and would include the RSA encryption. $\endgroup$
    – Maarten Bodewes
    Sep 18 '19 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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