Cfrtjryk

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.

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.