Firstly, bear with me, I'm relatively new to cryptography. In a recent static analysis scan of our application, one of the findings complained that we are using ECB:

A mode of operation of a block cipher is an algorithm that describes how to repeatedly apply a cipher's single-block operation to securely transform amounts of data larger than a block. Some of the modes of operation include ECB (Electronic Codebook), CBC (Cipher Block Chaining) and CFB (Cipher Feedback). ECB mode is inherently weak, because it results in the same ciphertext for identical blocks of plaintext. CBC mode does not have this weakness, making it the superior choice.

We are using ECB with RSA. Our understanding is that RSA doesn't support anything other than ECB as it doesn't permit a block size bigger than the size of the key's modulus, and therefore would only ever encrypt a single block (or throw an exception if breaching block size). Our suspicion therefore is that the static code analysis tool is searching for 'ECB' in our code base irregardless of the crypto algorithm used.

Given our choice of an RSA crypto algorithm, is there an inherent weaknesses using ECB mode?

  • 2
    $\begingroup$ RSA is not a block cipher and you shouldn't use it as one. $\endgroup$ – Thomas May 4 '15 at 12:57
  • $\begingroup$ If this is a publicly available product, I strongly recommend you hire a crypto consultant to get you a better design. It appears you are putting your users at significant risk given your current design. $\endgroup$ – mikeazo May 4 '15 at 13:03
  • 1
    $\begingroup$ Also, are you sure you are using RSA with ECB? If you are using a publicly available crypto library, chances are you are using RSA to encrypt a symmetric (AES) key, and AES in ECB mode. I don't know of any crypto libraries that have an ECB mode for RSA. $\endgroup$ – mikeazo May 4 '15 at 13:05
  • 1
    $\begingroup$ There are two related questions here Is RSA in an ECB-like-mode safe for bulk encryption? and Why shouldn't I use ECB encryption?. $\endgroup$ – mikeazo May 4 '15 at 13:06
  • $\begingroup$ If you came here like me because static code analysis flagged you with a security flaw for using ECB instead of CBC in code that looks like this: Cipher c = Cipher.getInstance("RSA/ECB/OAEPWithSHA-1AndMGF1Padding","SunJCE"); You might have to explain to someone that it's just a Java syntax thing and that ECB or CBC don't really do anything because RSA isn't breaking the message into blocks. $\endgroup$ – Richard Brightwell Apr 30 '17 at 4:57

It is highly misleading to call how RSA Encryption is used as 'ECB mode'.

With ECB mode, we break the plaintext into N bit segments, and send each one through the block cipher separately. The block cipher is deterministic, and so if two plaintext blocks happen to be the same, so will the corresponding ciphertext blocks.

Now, with RSA encryption, we take the short message, and some randomness, stir them together (using a padding method), and send that through the RSA primitive, resulting in the ciphertext. If we encrypt the same message again, well, we'll stir in different randomness, resulting in a different looking ciphertext. Hence, we avoid the problems inherent with ECB mode (and thus it is rather inappropriate to call what we do with RSA 'ECB mode').

Now, some closing comments:

  • The above assumes that you are using a known-good RSA padding method, such as OAEP. If you aren't, and are instead using 'textbook RSA' (which is just to take the message, interpret it as a large integer, and send that to the RSA primitive), then there are a number of security problems you can run into, in addition to determinism. If that is the case, you definitely need to fix it.

  • Someone could devise a CBC-type mode for doing RSA encryption (by breaking up the message into separate blocks, and doing an "add mod N" of the ciphertext of one block to the plaintext of the next). We never do so, because of efficiency - if we ever need to RSA encrypt a long message, a far more efficient approach would be to pick a random (say) AES key, RSA encrypt the AES key, and then AES encrypt the actual message with the AES key. Because AES is far more efficient than RSA, this is faster (and we retain the only-someone-with-the-private-key-can-decrypt property of pure RSA).

  • 2
    $\begingroup$ Well, that sounds exactly like the textbook version of RSA, so I see no problem in calling it ECB. Well, you should still not use it "in ECB mode". $\endgroup$ – Nova May 4 '15 at 13:37
  • $\begingroup$ Thanks @poncho, that was very helpful. We are using OAEP. $\endgroup$ – Chris Knight May 4 '15 at 13:57
  • 3
    $\begingroup$ What I (differently) understood is that RSA is used to encrypt a random symmetric key, and this one is used to encrypt the message in ECB mode. This approach would be insecure, even if the symmetric key was random, because two equal blocks of the message would produce the same encrypted block. The approach that you discuss in your answer would be secure as long as RSA uses enough bits to allow a large amount of random padding. However, it would be very inefficient due to the large amount of processing that RSA would consume. I recommend to encrypt a random key and use CBC or CTR mode with it. $\endgroup$ – jordix May 4 '15 at 17:46
  • $\begingroup$ @ChrisKnight how many bits of padding are you using? $\endgroup$ – mikeazo May 4 '15 at 18:52
  • $\begingroup$ @jordix: yeah, that's another plausible way of interpreting the question. $\endgroup$ – poncho May 4 '15 at 19:06

"We are using ECB with RSA": It's difficult to understand what you mean by this; nobody does it, ever, so we have no "default meaning" to fall back on. You will have to describe your protocol in more detail, and then we can tell you why it is flawed.

  • 2
    $\begingroup$ This looks more like a comment than an answer. Did you intend to post it as an answer? $\endgroup$ – mikeazo May 4 '15 at 16:05
  • $\begingroup$ Not true. Here is Java syntax for using RSA: Cipher c = Cipher.getInstance("RSA/ECB/OAEPWithSHA-1AndMGF1Padding","SunJCE"); Granted the ECB makes no sense with RSA, but that's how you do it in Java and it freaks out the static code analysis tools that blindly search for ECB. $\endgroup$ – Richard Brightwell Apr 30 '17 at 4:53
  • $\begingroup$ @RichardBrightwell: Like I said, nobody uses ECB with RSA. Even Java's RSA/ECB/OAEPWithSHA-1AndMGF1Padding doesn't use ECB with RSA. $\endgroup$ – TonyK Apr 30 '17 at 11:19

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