Argthtjtr

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?

...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!"

Example:

• 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?