3
$\begingroup$

In symmetric cryptography, a scheme is not considered secure if the data transmitted is only encrypted. The adversary will be able to modify messages to generate encrypted messages of his choice without having the key.

Is this applicable to asymmetric crypto such as RSA?

$\endgroup$
2
  • $\begingroup$ Yes, the same holds: insuring confidentiality and insuring authenticity are distinct goals, both in symmetric and asymmetric cryptography. $\;$ Is there anything in the question beyond that ? $\endgroup$ Aug 25, 2014 at 8:19
  • $\begingroup$ @fgrieu I know they are different. I'm not asking about the difference between the two. I slightly edited the question to make it more clear. Please check it again. Thanks $\endgroup$
    – BlaX
    Aug 25, 2014 at 8:27

2 Answers 2

5
$\begingroup$

The attack is even more simple with RSA than with symmetric keys, because the asymmetric encryption key is assumed to be public.

Let me tell you a story involving Alice, Bob and Mallory :). Alice wants to send a message to Bob using RSA.

  • Alice encrypts the message using Bob's public key and sends it
  • Mallory performs a Man-In-The-Middle attack, and encrypts another message using Bob's public key (as it's public)
  • Bob received the new message thinking it comes from Alice, as there's no origin authentication.
$\endgroup$
4
  • 1
    $\begingroup$ The only time I saw anybody ever propose unauthenticated RSA, both keys were private. $\endgroup$
    – Joshua
    Aug 25, 2014 at 18:58
  • $\begingroup$ This isn't how you'd go about attacking RSA. You don't encrypt a message using your own public key and send it to someone else. You encrypt it with their public key. The key question is "how do you know you can trust the other peer's public key?". Without authentication, you could be sending your message using the attacker's public key. (example: that's why the first time you SSH to a host, you are prompted to confirm that you trust the public key. If an attacker intercepted the communication using their unverified/unauthenticated key, they could intercept your session.) $\endgroup$
    – mpontillo
    Aug 25, 2014 at 19:15
  • $\begingroup$ This attack doesn't include knowing what is in the sender (Alice) message. Here, the attacker can replace or inject a message and neither the sender or receiver realise that the message was changed. SSH is a protocol (which includes a key exchange) so it's difficult to compare it to a encryption primitive like RSA. $\endgroup$
    – HocusPocus
    Aug 25, 2014 at 20:53
  • $\begingroup$ @HocusPocus, I agree with your answer completely, up to the point where you say "thinking it comes from Alice". Bob can't assume anything about the sender of the message, unless RSA is used in the context of a protocol (such as SSH or TLS, whereby you would validate the peer based on a mutual certificate, password, etc), PKI envelope, etc. I think it's useful to think about practical attacks against real systems that employ asymmetric crypto. Your attack is practical, but misses the part about why it would work. (that is, why the key is unauthentic and yet trusted anyway.) $\endgroup$
    – mpontillo
    Aug 25, 2014 at 21:20
0
$\begingroup$

With RSA (or any asymmetric cryptography, for that matter), the key question is "how do you know you can trust the other peer's public key?". Without authentication, you could be sending your message using the attacker's public key.

Example 1: the first time you SSH to a host, you are prompted to confirm that you trust the public key. That's because if an attacker can intercept the communication and use their own unverified/unauthenticated key, they can decrypt your session by using man-in-the-middle attack.

Example 2: if the organization you work for uses a deep packet inspection firewall, and they enable SSL inspection, they will be instructing your workstation to trust their corporate public key. (which comes in the form of a certificate) Whenever you hit a site using HTTPS, their firewall will execute a man-in-the-middle attack, and you will [essentially] use the public key (found in the certificate, which you now trust) to secure the communications with your remote host. The contents of your session are now available to the organization.

$\endgroup$

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.