I understand Kerckhoff's principle, in a very practical sense, that the best attack that can be performed on a given cryptographic algorithm should be only as practical, if not less practical, than an exhaustive key search, that is, testing every possible key. My question is, if this is the case, then why go through the trouble of creating a cipher in the first place? Why not simply use a ridiculously long key, if you're gonna create a cipher that only takes as long as an exhaustive key search anyway?

  • 5
    $\begingroup$ Related questions: one-time pad: Why is it useless in practice and Is modern encryption needlessly complicated? $\endgroup$
    – Ella Rose
    Commented Dec 29, 2018 at 21:00
  • 24
    $\begingroup$ Your question is unclear to me; to convert a plaintext and a key (of whatever length) to a ciphertext, you need an algorithm for transformation. That transformation algorithm is called the cipher. Without a cipher, no encryption, full stop. When you say "why not use a ridiculously long key", how do you intend to encrypt the plaintext? $\endgroup$
    – marcelm
    Commented Dec 29, 2018 at 22:12
  • 1
    $\begingroup$ @marcelm I assume the encryption would be using a one-time-pad of some sort, which arguably to some extent renders the algorithm so trivial that it's solely the key that's providing security, not the algorithm (probably some variant of XOR). $\endgroup$
    – March Ho
    Commented Dec 30, 2018 at 1:18
  • 4
    $\begingroup$ This "ridiculously long key" is exactly a one-time pad, and all of the usual disadvantages apply. $\endgroup$ Commented Dec 30, 2018 at 4:24
  • 1
    $\begingroup$ @MarchHo & chrylis - Maybe Will was talking about OTP, but I'd prefer to hear confirmation from him; maybe he meant something else. Either way, OTP is still a cipher, however trivial ;) $\endgroup$
    – marcelm
    Commented Dec 30, 2018 at 13:19

4 Answers 4


...why go through the trouble of creating a cipher in the first place? Why not simply use a ridiculously long key, if you're gonna create a cipher that only takes as long as an exhaustive key search anyway?

Designing a cipher is significantly less hassle then using a ridiculously long key.

Designing a cipher only needs to be done once by a competent professional.

Using a ridiculously long key would need to be:

  • Done by all parties
    • "all parties" includes everyone with a networked electronic device
    • Almost all of them are not competent professionals
    • Requires a pre-existing secure channel, or more likely a face-to-face meeting
      • "secure channel" must not use encryption, otherwise the problem is circular
  • Done pairwise for each group of communicating parties
    • e.g. You have to go through the key establishment process for every particular site you want to visit
    • A web site with 1000 users that each have a 1GB key would need to have access to 1TB of reliable, secure storage just to store the key material (that's a small website)
  • Done repeatedly
    • You will eventually run out of key material
    • Your keys could become compromised
      • Updating them in a useful time frame will be next to impossible
  • Destroyed securely after use
    • Re-using any part of the key will lead to a practical lose of confidentiality
      • In a practical scenario (e.g. HTTP requests) known-plaintext attacks apply, which will allow trivial recovery of the key

It simply would not work in practice. A proper cipher will.


Edit: I wrote the below on autopilot with the definition in the question. I have since realised an additional mistaken detail: the rule about no attacks better than key exhaustion is not called Kerckhoff's principle. Kerckhoff's principle is a related rule of cipher design that the key is the only component that can be relied upon to be secret.

When you say "If Kerckhoff's principle holds", I think you might have slightly misunderstood Kerckhoff's principle. It is not a scientific hypothesis about some property of all ciphers so much as a design principle for making good ciphers.

By way of analogy, suppose I have "Lancelot's principle" about suits of armour. Lancelot's principle is really simple: everything covered by armour should withstand three strikes from a longsword. Now it might be tempting to ask "If Lancelot's principle holds, why bother with fancy metalwork? If armour is always going to block a sword, let's just get the local tailor to make cloth** armour that covers every inch of you and your horse." Of course Lancelot's principle isn't actually saying that anything we call armour can block a sword: instead it's saying that something that can't block a sword shouldn't be counted on to serve as armour.

So, let's pick on some random thousand byte polyalphabetic Vigenère cipher. It's been known for over a hundred years how to use frequency analysis to break a polyalphabetic cipher. So long as the message is long enough, this attack takes linear time in the size of the key (whereas key exhaustion takes exponential time). So, it is not that this Vigenère is guaranteed by Kerckhoff's principle to resist anything short of exhaustive key search. Rather a Vigenère algorithm fails the test posed by Kerckhoff's principle, and therefore shouldn't be used as a cipher.

I hope that clears things up.

** If someone with dual interests in crypto and military history turns up to tell me that cloth is surprisingly effective against swords, replace cloth with body paint or something.


There's a simple maxim that demonstrates otherwise. It's much much harder to make true random numbers/your 'ridiculous' key than it is to make pseudo random numbers.

A cryptographic strength pseudo random number generator can be instantiated at the drop of a hat (or calling a C++ constructor with a seed value). Based on some experience, a clever DIY guy can probably make 10 megabits per second of true random bits. A modern photonics laboratory can do much better, but most don't have access to those resources. Even then, you have the Brobdingnagian problem of distributing the key between parties. If an unexpected party suddenly wants to join the discourse, you're in trouble distributing said key to expand the conversation.

In the last six months, half a billion people visited Britain's BBC website which is served over HTTPS. Based on a recent page download survey suggesting a mean entertainment page size of 1.7MB , Auntie would have to generate > $10^{15}$ bits of key material/year. Many lava lamps would be required. It would take me 22 boring years to generate that much entropy. And ship it out of channel across international boundaries to ill defined transitory recipients. It's logistically impossible.

You've discovered a one time pad. They have practical applications, but only on very limited criteria.

Slight niggle: A one time pad à la random Vernam cipher is still a cipher.


I understand Kerckhoff's principle ...

... then why go through the trouble of creating a cipher in the first place?

I think you misunderstood something:

Kerckhoff's principle does not say that a cryptosystem is secure. The principle says that the cipher used must have certain properties if the cryptosystem shall be secure.

In other words: Kerckhoff's principle won't be satisfied if the cipher used is bad!

An extreme counterexample

We could design the following "cryptographic" system:

  • The key consists of any characters but the colon (:)
  • To encrypt the text, we simply add a colon followed by the key to the text; the result is our "ciphertext"
  • To decrypt the text, we check if the "ciphertext" ends with a colon followed by the key
  • If yes, we remove the colon and the key; the result is our plaintext
  • If no, our plaintext is "Sorry, wrong key!"


  • The plaintext is: "This is a very secret text."
  • Our secret key is: "This is our secret key."
  • The "ciphertext" will be: "This is a very secret text.:This is our secret key."
  • If we use the correct key for decryption, the decrypted text will be: "This is a very secret text."
  • If we use any other key for decryption, the decrypted text will be: "Sorry, wrong key!"

Not using the correct key for decryption will definitely not result in the correct plaintext but in: "Sorry, wrong key!"

Do you think using a very long key will result in a secure encryption?

  • $\begingroup$ The principle in question states that the system should remain secure even if an adversary knows all of the steps of the algorithm, but does not have the key. The example provided here is broken with a single ciphertext-only attack, even to someone who previously did not know the algorithm. $\endgroup$
    – Ella Rose
    Commented Jan 1, 2019 at 16:05
  • $\begingroup$ @EllaRose I doubt that there is any algorithm that allows "calculating" the algorithm from any information: Modify "my" algorithm in a way that the number 1234 must be added to every number when the "key" contains the word "hello". The plaintext "My cellphone password is 1111." would become: "My cellphone password is 2345.:Password is hello." If you don't test my algorithm with a number in the plaintext and the word "hello" in the key, you will never find out! $\endgroup$ Commented Jan 1, 2019 at 18:07
  • $\begingroup$ @EllaRose ... and of course my intention was to show an example of an algorithm where Kerckhoff's principle definitely is not given. $\endgroup$ Commented Jan 1, 2019 at 18:09

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.