This cipher is pure security-through obscurity and it held up well.
It's sounds like you're saying that something like a substitution cypher, or even a one-time pad, would be security by obscurity, because they key is "obscure."
My understanding is rather that security by obscurity means you're relying on the attacker not to have knowledge about you system -- e.g. that you have an admin backdoor at /s3cr3t-admin-pag3.html (real-world example), or that you can ping the server at an unpublished end point to get a token.
The opposite of security by obscurity is when the entire structure of your system is a complete open book (e.g. everything is completely open sourced) except the password, and yet the system is sound enough to resist an attack. But note that possessing a "secret" (a password, a key, a one-time pad, the substitution rules, etc) doesn't mean it's now security by obscurity.
Did a ROT-13/15 (vowels vs consonants, if it matters) test on _smart_ collegues. Turns out they fear the worst and start top-down.
Plenty of smart people don't jump straight to a solution when seeing a ROT13 ciphertext, whereas I think most people who are experienced would realize pretty quickly there seems to be a simple transformation going on.
That the problem only happens when you reuse that sheet.
This doesn’t apply here specifically, but if you would have told me this previously I would have assumed it was securing through obscurity.
What makes encryption "perfect"? This is not obvious, so I'll just skip ahead to the conclusion: encryption is perfect when it's impossible to distinguish which candidate plaintext led to a specific ciphertext without knowing the entire key.
It's easy to see that a one-time pad qualifies here. Even knowing all but one character of the plaintext doesn't give you any cryptographic way to determine what the last character is. The list of possible keys associating the known plaintext with the current ciphertext allows for every single character in the unknown position. This isn't a matter of computational power, it's an information-theoretic limit. You just don't have enough information (from the cryptography, anyway) to prefer any choice over another.
You can apply a pigeonhole principle argument here and see that this requires the key to have the same size as the message. (Something along the lines of each key specifying a permutation between messages of the same length, and you need the key size to be big enough to specify every possible permutation for that message length.)
That argument can then be used to demonstrate the information-theory quality of the encryption is related to the ratio between the lengths of the message and the key.
When you look at modern cryptography, you can see that we're not depending on information-theoretic security at all. If you had all but one characters of the plaintext and all the ciphertext, it's quite likely there'd only be one key that matches the known permutation. We've gone in a different direction: computational security. It should require an implausible amount of computation to derive what the key is, even when you know matching plaintext and ciphertext.
It's certainly more convenient than moving terabytes of key around, and computational limits are actually pretty compelling, as long as flaws aren't found in the construction.
But it lacks the satisfaction of provably unbreakable.
The base step:
Start with one bit. The key is also a bit chosen at random, and the cipher text is plain XOR key.
You can then work out that no matter what key is chosen, you have no reason to believe 0 or 1 is the original plain text.
The inductive step is simply to add a new random bit of key that is independent from the prior key, and a new bit of plaintext.
What I like about this explanation is that you can actually work out the decision trees for a few bits to convince yourself that the encryption still holds.
This algorithm is information-theoretic secure for a bitstring of length N
The grantparent's argument is to first convince yourself that a) this is true for a bitstring of length 1, and b) if it's true for a bitstring of length N, then it's also true for a bitstring of length N+1 (or alternately formulated: if it's true for bitstrings of length M and N, you can concat them and it will be true for a bitstring of length M+N)
The inductive step is then to apply this to show that because it's true for length 1, it's also true for length 2. And if it's true for length 2 then it's true for length 3. etc etc.
https://www.douglas.stebila.ca/teaching/visual-one-time-pad/
IIRC this is exactly how OTP was used by some spies during the Cold War. (My compsci teacher actually showed us an 'original' pair of sheets that encoded a Chinese character).
Also shows it very neatly why reusing the sheet is a bad idea.
Edit: Forgot the link https://darknetdiaries.com/episode/83/
The answer to this can tell how easy it may be to create a similar problem today.
ebeorietemethhpiti
Maybe none.
This person killed several people, and THAT is your biggest problem?
There's a discussion about how strong the cipher is, and:
thatwasunusual> ...and still the killer is unknown. That's pretty good, IMO.
Someone pointed out that measuring the strength of the cipher by the fact that the killer is unknown is a bad metric, and you seem to believe this as a defence of murder?
They are merely pointing out there is no connection between the fact the killer is unknown and if the cipher was strong or weak.
Given he fooled everyone for 40+ years I find it hard to believe he would overlook details, especially when it's about his main publicity tool.
swiches instead of switches, cid instead of kid, figgure instead of figure, cerous instead of curious
There are more.
Even if it was intentional, I am not sure that spelling mistakes would make 60s/70s decryption attempts any worse. They did not work by brute force and it's unlikely he predicted someone will use a supercomputer to crack his code decades later.