14
$\begingroup$

Let's say we have some plaintext. Let's say that we encrypt this plaintext with a random 32 byte key using AES-256. Let's say that we also encrypt this plaintext with an RSA 2048 public key.

If only the cipher text was known, which of these would be harder to identify the plaintext from?

My thoughts are that it would be the RSA ciphertext since the assumption is that the attacker has no access to either the public key or the private key, just the ciphertext. This is because the attacker has nothing to base any assumptions on and would still have to figure out what the private key is.

Improve this question
$\endgroup$
3
  • 4
    $\begingroup$ I don't see how you came to such a conclusion. In both cases of your description (AES as well as RSA) an attacker has nothing but the ciphertext to base any assumptions on and would therefore still have to figure out what the (private) key is. If the ciphertext of AES and/or RSA would enable an attacker to derive any information about the plaintext or key material, the related algo would need to be considered broken. At the time of writing this, no such weaknesses are known in relation to AES or RSA. (If anything, key length and/or how you created the key material could make a difference.) $\endgroup$
    – e-sushi
    Jun 6, 2017 at 3:53
  • $\begingroup$ The word "public" when referring to keys means your attacker is assumed to know it. $\endgroup$
    – adelphus
    Jun 6, 2017 at 10:50
  • 1
    $\begingroup$ Any thoughts about ciphertext-only attacks (COA) are pretty much futile from a modern point of view: If an encryption scheme offers only COA-security, it is utterly broken. And any stronger security propertly is implicitly COA-resistant as well. $\endgroup$
    – tylo
    Jun 6, 2017 at 12:42

2 Answers 2

Reset to default
27
$\begingroup$

It is also assumed that an attacker doesn't know anything about the secret key used as input to the AES algorithm.

Now lets assume that for either algorithm a mode of operation is used that sufficiently protects the ciphertext (say AES-CTR and RSA-OAEP). Then it comes down to analysing the security of the cipher itself given the key size.

Neither AES nor RSA has been broken in the sense that it is much less secure than the strength it was designed for. The key size is therefore easy: AES-256 has close to 256 bits of security while RSA only offers about 112 bits of security. In that respect AES-256 has RSA-2048 completely beat. [EDIT 2023] Although I would strongly suggest 3072 or 4096 bit keys for RSA nowadays, performing close to $2^{112}$ operations to crack just one key is outside the realm of likeliness.

As for the algorithm, AES-256 is considered secure against analysis with quantum computers. RSA is definitely not, given a large enough quantum computer. The only disadvantage of AES is that there is no security proof of the algorithm itself. We suppose it is secure, but we're not certain. RSA probably has a slightly better mathematical problem behind it.

Operationally speaking: it is much more likely that AES is implemented / executed correctly rather than RSA.

All in all I'd strongly recommend AES given your question.

But in the end recommending one over the other is futile; an asymmetric cipher has different properties and should be used in different scenarios than a symmetric cipher.

Say for instance that the system that performs the encryption is not as secure as the system that does the decryption. In that case RSA is a much better fit than AES as RSA encryption only requires the public key to be present.

Distributing a public key is of course also a completely different fish than sharing an AES secret key. With a public key you can distribute freely as long as the receiver can trust the public key. With AES you need a secure channel in advance.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Is RSA even really more mathematically proven than AES in the role of a general-purpose cipher? For short, random data such as single keys for another encryption layer, I would have thought both are proven to offer their 112 / 256 bits of security. It is for generalised frequency analysis etc. attacks that we don't know if AES becomes perhaps weaker, but that requires the transferred data has some known structure which in the case of RSA is in practice never the case as much as it is for typical AES applications. Why would RSA be inherently stronger than AES against such attacks? $\endgroup$
    – leftaroundabout
    Jun 6, 2017 at 14:50
  • 1
    $\begingroup$ @leftaroundabout The type of data, and how the alogirhtm is used, is not important. And that RSA has a proof does not mean that must be stronger than AES: ... There's a mathematical proof that cracking RSA can't be easier than factoring prime numbers. There's no such proof for AES. That's all $\endgroup$
    – deviantfan
    Jun 6, 2017 at 15:19
  • $\begingroup$ ... People searched fast methods for factoring large primes for many centuries, without success, so RSA being harder than it is (was) a good sign. (was: Now quantum computers are getting better and better...) $\endgroup$
    – deviantfan
    Jun 6, 2017 at 15:23
  • $\begingroup$ @deviantfan the proof of RSA as I've always understood it says that if all you know is the public key and the encrypted data, it's hard to get at the plain data. Well, the same is true even for a naïve substitution/XOR cipher (except that the “public key” contains zero bits): if you XOR-encode equal-distributed random noise, the result is equal-distributed random noise, and it's impossible to extract any information from it. Only, symmetric ciphers are required to work with highly non-random data all the time, so an attacker also knows something a priori about the plaintext. $\endgroup$
    – leftaroundabout
    Jun 6, 2017 at 15:57
  • $\begingroup$ @leftaroundabout the proof of RSA as I've always understood it says that if all you know is the public key and the encrypted data, it's hard to get at the plain data Yes and no. The proof basically ist "It's hard because getting the plain data is at least as hard as factoring a (large) prime number ("N", a part of the public key data)", and factoring large primes is/was considered hard. ... (But, there's no proof that factoring primes is hard, and as we know now, at least in the quantum computer area, it's not that hard. As soon as they are usable for real stuff, RSA is useless) $\endgroup$
    – deviantfan
    Jun 7, 2017 at 2:03
2
$\begingroup$

Though AES is more secure than RSA in same bit size, AES is symmetrical encryption. That's why SSL certificate can't use AES, but must be asymmetrical ones, e.g. RSA or ECDSA. AES is used in SSL data session, i.e. SSL negotiation is basically to define AES key to be used by data session. Anyway, RSA is going away. ECDSA can provide stronger encryption at much less bits.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ Welcome to Cryptography. This question is not really comparing AES vs RSA in the general sense. The OP rather a specific two scenarios to consider. $\endgroup$
    – kelalaka
    Jul 31, 2020 at 12:05
  • $\begingroup$ FYI: TLS-PSK exists for situations where you don't want asymmetric cryptography but where you do want TLS. SSL does not necessarily require asymmetric cryptography. In most cases however, it is indeed highly desirable. $\endgroup$
    – Ruben De Smet
    Jul 31, 2020 at 12:20
  • $\begingroup$ "AES is symmetrical encryption" (and therefore more secure) is, by itself, not a good argument. Single DES is also symmetrical encryption, but it is definitely not more secure than RSA for common key sizes. SSL negotiation establishes the ciphersuite, but the key establishment is not part of that although both are part of the handshake. RSA is not going away anytime soon, and it is less susceptible to attacks with a quantum computer. But yes, where key size or computational overhead are more important, EC is often the better choice. $\endgroup$
    – Maarten Bodewes ♦
    Apr 28 at 16:09

Your Answer

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

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