2
$\begingroup$

These days I found myself thinking about the implications of padding or not padding block cipher modes that act like additive stream ciphers (I meant OFB, CTR, GCM etc). Let's call additive modes.

You know, people hooked on crypto tend to be I little bit paranoid... Well, at some point in my ruminations about the pros and cons of padding when using those additive modes, maybe I got found a "cons" that let me a bit intricated: maybe not padding the cryptogram will offer a shortcut for the cryptoanalyst on excluding all other non additive modes during a brute force or even during any other more sophisticated cryptoanalysis.

Since modern ciphers are constructed in a way that any cryptogram will look like random data. If it was encrypted by using CBC or GCM, in practice, the picked mode will not be recognizable by any statistical or other method if cryptogram was a multiple of the cipher blocksize, right?

My doubt about it is if this alleged "operation mode leaking", in state of art, would be considered a weak point in the whole cryptographic infrastructure. Since cryptographers and cryptoanalysts have an endless fight, if a cryptographer is able to not provide shortcuts for the cryptoanalyst, would not it be better to avoid providing any shortcut for the cryptoanalysis? Let's forget a little Kerckhoffs's principle. Even better, if you can keep secret the key, why not also keep the operation mode in doubt?

Sorry if it sounds a little crazy or paranoid question but I am sure that here will be the only place at the Internet where I could be able to find "paranoids" worried about those more philosophical crypto questions ;)

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ BTW: The category of modes containing CTR, OFB, etc is usually called "stream cipher" modes, not "additive" modes. $\endgroup$
    – Mikero
    Commented Feb 10, 2022 at 7:11
  • $\begingroup$ Yes, it is just a way of keeping clear that we are using the basis concept of an additive stream cipher there (XORing the input bytes out with an iterative computation of what would be the keystream). $\endgroup$
    – r s
    Commented Feb 10, 2022 at 12:15
  • $\begingroup$ If you're truly paranoid, you'll pad out all messages to a constant length (and send encrypted messages at regular intervals, whether or not you have a message to send). In that case, we've already answered the question of "whether to use padding or not" $\endgroup$
    – poncho
    Commented Mar 9, 2023 at 17:54
  • $\begingroup$ The information about the mode is usually not secret - and it would weaken the encryption, if you assume it is ( in the security proof). On the contrary, in a security argument or Proof, you have to assume the attacker knows everything accept the key. $\endgroup$
    – tylo
    Commented Mar 10, 2023 at 15:30

1 Answer 1

Reset to default
3
$\begingroup$

According to Kerckhoffs' principle, everything about a cryptosystem except for the key(s) should be assumed to be known by the attacker (and the keys should be easily replaceable without invalidating prior security analyses of the system).

This includes the cipher and the mode of operation being used.

If your cryptosystem is secure even against an attacker who knows exactly how it works, then attempting to conceal the mode of operation adds no security. Conversely, if your system's security relies on the attacker not knowing how it works, then you're relying on security through obscurity, and will likely sooner or later find out that the details of its operation that you thought were secret actually aren't (and that, unlike changing a key, you can't easily change them when they're leaked).

Relying on security through obscurity also means that you cannot publish your system design for review by experts, and than even hiring individual crypto experts to review it under an NDA is a security risk. Since most cryptographic vulnerabilities arise from implementation bugs and/or inappropriate design choices, this is a serious problem. It also means that you'll have to keep all software and/or hardware implementations of your cryptosystem closely guarded, as an attacker getting their hands on the system will likely be able to reverse engineer it to find out how it works.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I agree but the point here is: if an intercepted cryptogram, picked from a widely unrestricted filtering announces this mode operation by producing cryptograms with irregular sizes (from the multiple expected of the blocksize). Would it not be a kind of modern crib, bad use that has betrayed Enigma in the past, for example? If an attacker must apply some brute-force over known obvious keys from the intercepted data, the task will be shortened if she/he know that should not attempt any mode different from stream based ones. AES is a standard, so have clues is better than have no clue. $\endgroup$
    – r s
    Commented Feb 11, 2022 at 2:50
  • $\begingroup$ Thus, even still hard the search problem was reduced. This is the point of the question, to challenge us to let the theoretic a little aside and thinking in practical terms, that people actually trying to exploit crypto must do, I believe. In terms of math and theory everything is really beautiful and wonderful, I think. Taking a look at some works on cryptoanalysis during those years, I realized that the most successful were the ones that really thought outside of the box. But I understand your point this is the concept and when studying we should not diverge from it. $\endgroup$
    – r s
    Commented Feb 11, 2022 at 2:51
  • $\begingroup$ @rs Weak attack scenarios like ciphertext -only are completely irrelevant. Ciphers must withstand stronger attacks in today's world. And there is no point in adapting from one weak assumption to another weak assumption. $\endgroup$
    – tylo
    Commented Mar 10, 2023 at 15:45

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.