Let's look at some different attacks on the Vigenère cipher and determine how much of a role alphabet size plays.
From Wikipedia:
The primary weakness of the Vigenère cipher is the repeating nature of its key. If a cryptanalyst correctly guesses the key's length, the cipher text can be treated as interwoven Caesar ciphers, which can easily be broken individually.
With a number like 1114111, breaking the individual Caesar ciphers by brute force would still be pretty easy. Maybe if you increase the size even further (128 bits or higher?). However, there could be attacks that perform better than brute force given the nature of the cipher.
Kasiski Examination:
Analyzing repeated groups of ciphertext which could correspond to the key. Extending the alphabet size would not affect this method, the best defense against this would be extending the key (ideally to the length of the plaintext, more on that later).
Key Elimination:
We can guess the key length (or figure it out somehow, like the Kasiski method) and remove the key from the ciphertext. This makes the alphabet size redundant (even if it was well above 1114111) because the key would be removed from the ciphertext anyway. To stop this, our key must be as long as our plaintext (see one-time-pad below).
Frequency Analysis and Friedman Test:
These rely on having information about the plaintext beforehand. Depending on implementation, your method could break these analysis techniques (or at least make them more difficult to implement).
These are just the methods outlined on Wikipedia for breaking the Vigenère cipher (you can of course look deeper into other methods). It should be pretty clear that Vigenère in the modern world can be considered broken, even if you play with the alphabet length and tweak the cipher in little ways.
Your question is tagged with one-time-pad, so I thought I should address this too. The one time pad can be implemented as a Vigenère cipher with a key that has the same length as the plaintext.
The one time pad is perfectly secure, but it has some stipulations and drawbacks.
- The key must be truly random, and at least as long as the plaintext.
- This means it shouldn't be entered by a user, repeated to fit the plaintext length, or generated using any pseudorandom number generator
- Generating true random numbers is difficult and generally impractical*
- Practically, you could use a CSPRNG, but then your OTP is only as strong as your CSPRNG (i.e. not a true OTP)
- The key must never be reused. The key is used once to encrypt, then once to decrypt, then discarded. Encrypting multiple plaintexts using the same key can open you up to attacks (like Key Elimination mentioned above).
If these conditions hold, then the OTP is perfectly random, because any one key is equally as likely as any other. Which means that any plaintext is equally as likely as any other plaintext to the adversary. So even with infinite time and resources, the adversary could never reverse the cipher (without the key).
* Generating truly random numbers can be done using a TRNG, usually implemented as an external hardware device. You can purchase these as USB input devices or make your own circuit.
a
is ASCII97
, butA
is65
, so it allows decrypts as the same as it went in, also allowing you to use punctuation, etc. $\endgroup$