3
$\begingroup$

I know that ECB block cipher mode is the weakest method of encryption because repetitions in input data with a stride of a block size lead to repetitions in output data.

However, as I may consider, elimination of repetitiveness should give a stronger result like for other modes (CBC, etc.). In addition, I know that compression algorithms are just designed specially for searching and removing certain types of correlations.

Let's consider input data are compressed using DEFLATE algorithm via zlib 1.2.11 with the highest compression level possible (9). How does such an approach increases the strength of ECB?

Update: My goal is to increase encryption speed by parallelization. I receive UTF-8 texts already deflated as specified in the previous paragraph, encrypt it with a user-supplied key, and put it to cache storage in a user folder.

Improve this question
$\endgroup$
8
  • $\begingroup$ "I know that compression algorithms are designed specially for searching and removing certain types of correlations." - are they? I'm not sure which compression you refer to and which correlation but I doubt that general purpose compression like gzip will remove arbitrary correlations and I'm not sure if the "certain" correlations you refer to are actually the ones which are relevant in the context of encryption. Do you have any source for this knowledge? $\endgroup$
    – Steffen Ullrich
    Apr 14, 2019 at 9:45
  • 1
    $\begingroup$ which correlation - as far, as I understand, compression removes byte- and chunk-level repetitions (differently for each algorithm, but still), messing up at least with N-rams, right? I know that this is certainly not a Diehard-grade approach by its own, so I am curious if it allows to strengthen ECB with such preprocessed data to a level of any other mode with raw, unprocessed data. My use case is to receive UTF-8 texts already deflated as specified in the last paragraph of the question and encrypt it with a user-supplied key before putting it to cache storage in a user folder. $\endgroup$
    – Arhad
    Apr 14, 2019 at 10:08
  • 7
    $\begingroup$ CTR (and thus AEAD built on CTR like GCM) can encrypt the message in parallel. openssl encrypts using AES-128-GCM at 5GB/sec (bytes, not bits) on a single core. There is absolutely no excuse for using ECB or for not authenticating. $\endgroup$
    – Z.T.
    Apr 14, 2019 at 12:04
  • 2
    $\begingroup$ @Z.T. openssl encrypts using AES-128-GCM at 5GB/sec (bytes, not bits) on a single core. There is absolutely no excuse for using ECB - oh, I really came into an XY problem here. Also, thank you for pointing to AEAD, I've discovered about new attacks it mitigates (and the existence of which I did not suspect). $\endgroup$
    – Arhad
    Apr 14, 2019 at 12:38
  • 1
    $\begingroup$ Using a compression algorithm, you make the first block of ECB (and by deduction all the blocks) even more susceptible to known plaintext attacks. $\endgroup$
    – A. Hersean
    Apr 16, 2019 at 15:00

5 Answers 5

Reset to default
3
$\begingroup$

Not only does compressing the ciphertext not make ECB secure, but it actually makes a secure cipher like AES-GCM insecure by leaking the content of the plaintext through the message lengths as in the CRIME and BREACH exploits.

If you are tempted to ‘increase the strength of ECB’, consider stepping back from minutiae like ECB for a moment to review your broader goal. There's a whole literature out there of ways to build authenticated ciphers—which are the black boxes that take keys and messages and turn them into ciphertexts that keep your conversations secret and detect forgery—with various performance characteristics. If you want to keep up with it, you might follow the IACR ePrint archive.

Forget, for a moment, that the concept of ‘block ciphers’ exists. Focus on authenticated ciphers: if you insist on block ciphers, you'll rule out some of the most popular and highest-performing authenticated ciphers like ChaCha/Poly1305, which, as it happens, can exhibit an essentially arbitrary degree of parallelism.

Next, is parallelism your goal, per se, or is performance your goal—in terms of latency and throughput? Let's take a look at the standard cryptography benchmarks which use a consistent framework for performing fair measurements across a variety of machines. It's a high-dimensional space that's difficult to navigate, which is why there's a large literature out there.

For example, anything based on AES will have a wide gulf between (a) hardware implementations that are fast and secure, (b) software implementations that are slow and insecure, and (c) software implementations that are painfully slow and secure. (The scale of slowness may not be relevant to your application; what is more significant is that secure software AES implementations like BearSSL's are few and far between.)

This is also why there are only a few choices that have been widely implemented in software—notably AES-GCM and NaCl crypto_secretbox_xsalsa20poly1305 or variants like ChaCha/Poly1305. The CAESAR competition didn't really turn up anything much better for most users, and there's an ongoing Lightweight Cryptography competition if you want to follow an academic bloodbath of destroying security of novel ideas.

If you are writing software, you should just take one of the handful of secure authenticated ciphers that are ready on the shelf, like AES-GCM or NaCl crypto_secretbox_xsalsa20poly1305, according to engineering constraints, and pay attention to the security contracts. Considerations that might figure into this choice:

  • Is one of these readily available in your software environment, and will that make the difference of whether you use cryptography or expose users to harm? If so, do that!
  • Are you subject to auditors who insist that you follow US federal government standards and will look for AES-GCM? If not, consider safer options like crypto_secretbox_xsalsa20poly1305.
  • Can you guarantee that you use AES-NI and CLMUL hardware support, or not? If not, consider safer options like crypto_secretbox_xsalsa20poly1305.
  • Can you choose nonces sequentially, as in a sequential conversation, or not? If not, consider safer options like crypto_secretbox_xsalsa20poly1305 with random nonces—or maybe a deterministic authenticated cipher, which can't conceal the fact of message repetitions but otherwise survives nonce reuse.
Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ Would the downvoter care to explain what you disagreed with in this post? $\endgroup$
    – Squeamish Ossifrage
    Oct 6, 2019 at 21:28
2
$\begingroup$

One problem with this approach is that both most compression algorithms and most block ciphers in ECB mode are deterministic. In other words, if you encrypt the same text twice, even if it has been compressed before, this fact will be obvious from the ciphertext.

I'd recommend you to have a look at counter modes, in particular AES-GCM (Galois/Counter Mode). They allow you to perform encryption in parallel without suffering from the problem outlined above (provided you use different IVs for each plaintext, as you should).

Improve this answer
$\endgroup$
1
  • $\begingroup$ Got it. So I need to work with initialization vectors only excluding any prior knowledge on input data, right? Anyway, thank you for pointing to CTR, here are out-of-the box solutions exist (like WolfSSL's implementation of AES_CGM, or AES-128-GCM, as Z.T. pointed in the comments), so I have no chance to implement it in an ad-hoc, weak manner. $\endgroup$
    – Arhad
    Apr 14, 2019 at 12:34
1
$\begingroup$

No, this is insecure.

Most compression algorithms work in blocks. Generally, each compression block is entirely deterministic and stateless. This is why you usually don't need to load all the data you wish to compress into memory and can instead stream it into the algorithm. For DEFLATE, this block size is commonly 32 KiB. Any duplicate 32 KiB chunks of uncompressed data will compress to identical compressed chunks. If you then encrypt that data with a block cipher in ECB mode, you will be able to determine which 32 KiB blocks are identical.

Improve this answer
$\endgroup$
0
$\begingroup$

Yes, it dramatically increases security.

No, it is by no means sufficient to be considered secure.

And most inportantly you have better options.

Compressing before encryption is in general good for security, almost all attacks are harder when the plain text is compressed. This is true also for weak ciphers ot weak modes like ECB. After encryption you will still be able to identify duplicate messages or even duplicate prefixes but compressed blocks are not likely to repeat unlike original message which under raw ECB will trivially reveal repeating blocks.

You have better options, if the goal is parallelism you can use CTR mode, or GCM if you want authentication as well.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ Compressing plaintext leaks plaintext content through the side channel of ciphertext length. This is not a theoretical concern; the idea has been demonstrated to, e.g., leak secret cookies through HTTPS—see CRIME and BREACH. While this may increase security against certain attacks, it also breaks the security of what would have otherwise been a secure cryptosystem—which I would not characterize as something that ‘dramatically increases security’. $\endgroup$
    – Squeamish Ossifrage
    Oct 5, 2019 at 17:55
  • 1
    $\begingroup$ Especially if you are using ECB I would say it increases security. Of course the details of what is being encrypted can be important. If I choose a book from project Gutenberg and took a few pages from it, and encrypted it in ECB mode it would be trivial for you to find the book and section. If I compressed first it becomes a serious challenge. Obviously you can mitigate with random padding for even more protection. $\endgroup$
    – Meir Maor
    Oct 5, 2019 at 18:03
-1
$\begingroup$

Stop trying to use AES or any other crypto primitive. What the community of security and crypto implementation engineers have learned since the 90s is that if the developer has to type A-E-S into their own code, there is too high a chance it will be insecure.

You are allowed to use Wireguard, TLS, SSH, Libsodium and Google Tink. That's it. Build your solution as something that uses one or more of those and absolutely no cryptography outside one of those.

(The above is the policy in AppAmaGooSoftBook, who hire smart engineers and then watch them make terrible mistakes, so their security teams have invented misuse resistant APIs to lower the chance of someone deploying something insecure. Just supplying a nonce into a secure AEAD is fraught with danger).

Improve this answer
$\endgroup$
4
  • $\begingroup$ So I need to use full-armed and tested libraries and not reinvent the cryptowheel, got it. But, for libraries, you listed only libsodium and Google tink (the rest are channel programs and protocols, so I doubt they can be applied to storage). What's about Open/WolfSSL and NaCl? These libraries also implement a whole infrastructure of streams encryption, checks, and authentication, not bare primitives. $\endgroup$
    – Arhad
    Apr 14, 2019 at 13:11
  • 1
    $\begingroup$ Wolfssl implements TLS, so it's allowed. It doesn't have a great reputation (prefer boringssl if you can) but it's better than rolling your own. Libsodium is the production version of nacl, prefer it over nacl. $\endgroup$
    – Z.T.
    Apr 14, 2019 at 13:15
  • 1
    $\begingroup$ Who is it that 'allows' us to only use "wireguard, TLS, ssh, libsodium and Google tink"? $\endgroup$
    – Paul Uszak
    Apr 26, 2019 at 13:45
  • 1
    $\begingroup$ @PaulUszak This was asked on security SE, not crypto SE. Crypto SE is generally not the right place for software devs asking "how do I ...?". I stand behind that as a very short security advice that leads away from badness, and particularly as the correct advice to a person contemplating using ECB. There is of course no one to stop you from using broken crypto, the community can only try to steer people towards misuse resistant high level APIs. If you are an expert, you can use low level primitives and take responsibility if it goes horribly wrong. $\endgroup$
    – Z.T.
    Apr 26, 2019 at 13:59

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.