3
$\begingroup$

I have a cryptosystem that I'm using for secure chat.

It is using AES 256 (with RSA 2048 for key exchange).

Would a predictable, and repetitively sent ciphertext plaintext compromise the cryptosystem?

For example, if Eve knows that the string "Username: testuser" is sent with each message (making it predictable), would that compromise the system?

Or something like an "html" tag at the very beginning?

$\endgroup$
  • 1
    $\begingroup$ Should "ciphertext" be replaced with "plaintext"? ​ ​ $\endgroup$ – user991 May 30 '16 at 2:07
  • 1
    $\begingroup$ Is the ciphertext repetitive? If so, you are doing something majorly wrong. If the plaintext is repetitive, but the ciphertext isn't, that is fine. That said, if this is for a commercial product, you shouldn't be rolling your own crypto. $\endgroup$ – mikeazo May 30 '16 at 2:09
  • $\begingroup$ @mikeazo It is bouncycastle... $\endgroup$ – kys111 May 30 '16 at 2:13
  • $\begingroup$ Should the ciphertext be different every time, given the same input? @mikeazo $\endgroup$ – kys111 May 30 '16 at 2:14
  • 1
    $\begingroup$ Yes, resulting ciphertext should be different, except if using ECB, see stackoverflow.com/questions/1220751/… , also: en.wikipedia.org/wiki/… $\endgroup$ – P.Péter May 30 '16 at 7:45
5
$\begingroup$

Yes, if your ciphertext is repetitive, that's bad.

We can't really say how bad, since you haven't told us enough about your cryptosystem. It could be because you're using AES in ECB mode, which is kind of bad. Or it could be e.g. because you're using AES in CTR mode with a fixed IV, which would be worse. Or, in principle, you might be using a deterministic authenticated encryption mode like SIV without a nonce, which would be almost OK (although, for a chat application, even the minimal information leakage of nonce-less SIV would seem undesirable).

But, in any case, a modern semantically secure encryption scheme should never produce repetitive ciphertext, not even if the plaintext repeats. If yours does, it's a sign that you're using AES wrong somehow.

As a corollary, as long as the encryption method you're using is resistant to chosen-plaintext attacks (which turns out to be equivalent to semantic security), it does not matter what the plaintext is or how many times it's repeated, not even if the attacker gets to choose the plaintext.

Most standard AES modes of operation (with the exception of ECB) are provably secure against chosen-plaintext attacks, as long as the AES block cipher itself is not broken and as long as they're used correctly — i.e. the IV / nonce is chosen appropriately for the mode, and never reused, and the maximum amount of data encrypted with a single key is not exceeded (not that a typical chat application is likely to come anywhere close to doing that).

(However, if an attacker can intercept and manipulate the encrypted messages (and/or inject their own fake messages into the communication), they may be able to modify the messages in transit and to carry out chosen-ciphertext attacks, which the classical non-authenticated modes of operation like CBC, CFB, OFB and CTR are not resistant to. To protect yourself against such attacks, you either need to combine them with a message authentication code, or use an authenticated encryption mode that, in effect, has the encryption and authentication parts combined into a single standardized bundle.)

$\endgroup$
  • $\begingroup$ I think the question has been amended since this answer was posted. The question now concerns repeated plaintext which, to my knowledge, does not compromise the cryptosystem. $\endgroup$ – user9070 May 30 '16 at 13:01
  • $\begingroup$ @IlmariKaronen Thanks for the quality answer. Let me get this straight. I have plaintext p, which is "abcde", and password k, which is "pass", and salt s, which is {0,0,0,0,0,0,0,0}. I put these into my AES.cbc function, AES(p,k,s), and it outputs ciphertext "palfj". If I do the same operation a second time, with the same inputs, AES(p,k,s), and it still outputs "palfj", this is bad? $\endgroup$ – kys111 May 30 '16 at 15:06
  • $\begingroup$ @TruthSerum: Indeed, the question has shifted a bit. I've expanded my answer to try to cover both sides of the question now. $\endgroup$ – Ilmari Karonen May 30 '16 at 17:08
  • $\begingroup$ @kys111: Yes, if that's what you're doing, that would be bad. Note that CBC mode encryption does not take either a "password" or a "salt"; it takes an AES key (which you could derive from a password) and a random initialization vector (which is kind of like a salt, but needs to be exactly one cipher block long and must not be predictable). So the problem isn't really in your CBC encryption function, but in the fact that you're using it wrong. $\endgroup$ – Ilmari Karonen May 30 '16 at 17:16
  • $\begingroup$ @IlmariKaronen It is producing the same ciphertext everytime still, I even switched to AES with CTR mode (no iv with this, making it easier), and it does the exact same thing; The same inputs produce the same ciphertext. $\endgroup$ – kys111 May 30 '16 at 18:19

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.