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?
1
-
$\begingroup$ If there is an additional voice (not necessarily secure) channel a Short Authentication Tag can be used to verify verbally. $\endgroup$– kelalakaCommented Sep 17, 2019 at 9:43
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
3
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$– yejc55Commented Sep 16, 2019 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 ♦Commented Sep 16, 2019 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 ♦Commented Sep 17, 2019 at 13:04
$\begingroup$
$\endgroup$
4
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 ♦Commented Sep 17, 2019 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 TuanCommented Sep 18, 2019 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$– MaeherCommented Sep 18, 2019 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 ♦Commented Sep 18, 2019 at 21:10