I checked the most common AES modes and I think I got the goal of them: avoid same cyper text for same plain text. However all modes except ECB have the weakness that lost part of the message stream will result in a broken decryption because the key can not be generated. CFB is one attempt to resynchronise, it needs the previous cypher block and CTR is another way, if you know how many blocks are missing.

I am not a specialist in cryptography but I would like to suggest a extended use for ECB: Would it be appropriate to split each block into a part with plain text and another part with true random data in order to assure that each cypher text will be different from the other while keeping the same key (ECB mode)? Of course I loose plain text capacity and safety depends on the ammount of random data. Lets say the first 10 bytes of each block are plain and the last 6 bytes are random content. That means that I reduce the randomness from 2^128 to 2^48 which is still high (and it applies only if I allways have the same plain text).

Is this an acceptable safety? OK, reply attacks are possible and need to be handled separately.

  • 2
    $\begingroup$ That is how RSA encryption is made indeterministic; so I believe the idea itself is acceptable but not optimal for symmetric ciphers. $\endgroup$ – kludg Oct 4 '16 at 14:28
  • 2
    $\begingroup$ That some lost part of the message stream will result in a broken decryption is not a weakness in the cryptographic sense of that. It is at worse a practical annoyance. The workaround suggested brings another, most serious practical annoyance: it significantly increases the ciphertext size. That's probably why it is seldom used (in combination with a block cipher like AES at least). $\endgroup$ – fgrieu Oct 4 '16 at 14:29
  • 1
    $\begingroup$ As a suggestion; you don't use 6 bytes random data; instead, you use a 6 byte counter. That means that you're guaranteed not to repeat an encrypted block (until the counter rolls over), and you'll catch it if someone does a reply/rearrange attack (and make it more likely to detect a random change). This is still probably not practical (because of the ciphertext expansion...) $\endgroup$ – poncho Oct 4 '16 at 14:51
  • $\begingroup$ Yeah, but in that case you might as well use AES-CTR and XOR with the ciphertext stream, same functionality without the expansion. $\endgroup$ – Maarten Bodewes Oct 4 '16 at 21:30
  • $\begingroup$ Thanks for the assesments! I like the idea of poncho which solves the reply attack issue. It is not quite the same as AES-CTR because the key is fixed and it can be decrypted in any case. It even gives the information of how much traffic got lost. $\endgroup$ – phu Oct 5 '16 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.