3
$\begingroup$

Does the size of the cryptogram affect the possibility of breaking it?

In the context of symmetric and block algorithms.

Does the format and earlier processing of the document (compression, changing the document format) affect the possibility of its cryptanalysis?

$\endgroup$

4 Answers 4

2
$\begingroup$

The earlier processing and format of the document doesn't affect the possibility of cryptanalysis if that processing is done in a way that leaks no information about the plaintext to an attacker.

That caveat is important. Compression side channels were the source of the CRIME and BREACH attacks on TLS. Attackers could trick browsers into compressing data they sent along with some data that should have been secret to the user. When the attacker-controlled data was equal to the user's secret data, the resulting compressed value would be smaller than if the two values differed. That let the attacker infer that their guess was correct, even if they couldn't read the (encrypted) compressed data.

There have been numerous other side-channel attacks on various security systems. Padding oracle attacks on RSA PKCS#1v1.5, the Spectre and Meltdown attacks on CPUs, Rowhammer against memory, etc.

Note that side-channel attacks don't actually break the cipher, they bypass it entirely. By analogy a thief doesn't have to cut (or pick) a bike lock if only the front wheel of the bike is locked to a rack, they can just remove the front wheel and take the (more valuable) remainder of the bike. They're sometimes still part of the general field of cryptanalysis, but they're different from algorithmic attacks.

$\endgroup$
0
$\begingroup$

Maybe you can share some more information about what the attack model is?

For all practical purposes it does not matter how much data an adversary obtains - a secure cryptosystem (when used correctly) guarantees the secrecy of the data it encrypts.

$\endgroup$
6
  • 1
    $\begingroup$ You covered yourself with "for all practical purposes" but you might want to point out how much data is actually needed to start implementing attacks. EG XChaCha20 can produce up to 2^64 blocks of keystream for a given key/nonce pair. After that, it's a two-time pad and you have to change the nonce and/or rekey. Since each keystream block is 512 bits that's 256 exbibytes. Which is quite an impractical amount of data. $\endgroup$ Nov 17, 2020 at 1:42
  • $\begingroup$ You're right, and there have been practical attacks on 3DES or Blowfish due to their 64 bit blocksize. However even with 128 but blocks, you will only expect a collision with ~50% probability after 2^64 blocks. $\endgroup$
    – ambiso
    Nov 17, 2020 at 16:07
  • $\begingroup$ ChaCha20 has only a 64-bit counter, so after 2^64 blocks the keystream repeats. Which turns it into a two-time pad. $\endgroup$ Nov 17, 2020 at 18:00
  • $\begingroup$ I'll also note that the IETF variant of ChaCha20 used in TLS only has a 32-bit counter, so it's far easier to overflow that. On the other hand a TLS session is unlikely to stay around that long, and the TLS spec ensures that no compliant implementation will keep the same key+nonce pair long enough for the counter to overflow. $\endgroup$ Nov 17, 2020 at 18:59
  • $\begingroup$ Oh, yeah, counter mode is a problem. Although a sane implementation probably checks whether a counter overflows. And yeah, TLS rekeys after I think 2^14 records or something. $\endgroup$
    – ambiso
    Nov 17, 2020 at 19:16
0
$\begingroup$

If we're talkin about a good cryptosystem the answer is no, but a padding scheme (e.g zero padding) should be used.

Your cryptosystem must be able to produce consistent ciphertexts even if the encrypted value is a single bit which was padded before encryption.

The only artifact that might affect the security of a consistent cryptosystem is the key, so the key size must be important, not the plaintext. What I'm saying is according to the Kerckhoffs's principle.

$\endgroup$
0
$\begingroup$

Does the size of the cryptogram affect the possibility of breaking it?

Yes, symmetric encryption modes generally have size limits on how much data you can encrypt under a single key, tied to the block cipher block size. For an accessible discussion of an example, see Matthew Green's blog post on the Sweet32 attack.

But as the posting explains, here we're talking about 64-bit wide block ciphers and 256GB of data encrypted with one key, which the rest of your question indicates is not what you're thinking of.

Does the format and earlier processing of the document (compression, changing the document format) affect the possibility of its cryptanalysis?

At smaller sizes, definitely not. The output of a cipher is required to be indistinguishable from random for any practical amount of computation.

$\endgroup$

Your Answer

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

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