1
$\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?

Improve this question
$\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.

Improve this answer
$\endgroup$
5
  • 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$ – SAI Peregrinus Nov 17 '20 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$ – cisnjxqu Nov 17 '20 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$ – SAI Peregrinus Nov 17 '20 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$ – SAI Peregrinus Nov 17 '20 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$ – cisnjxqu Nov 17 '20 at 19:16
0
$\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.

Improve this answer
$\endgroup$

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.