I back up O.M answer. All our modern encryption techniques are about doing encryption in the world of computers, and are moot without computers. We have not 'discovered' any new techniques that are useful without computers that were not known by the era of telegraphs. Thus knowing these techniques (which many of them were known, at least generally, in the era of telegrams) would not prove useful.
TIME:
First, there is the obvious problem, our modern encryption works on the presumption that calculations are CHEAP. were talking about a world where 10 thousand calculations a second is considered a snails pace. In a world like this the only effective encryption works on a simple trick. I find something that is faster to calculate going forward then backwards, then I do that calculation many many times, so that it would take forever to do it backwards. However, these algorithms all work on a presumption that these calculations are cheap. Even knowing someones key it would take forever for a human to decrypt any modern crypto because there are so much math that goes into decrypting and decrypting even short keys. Of course, a more human-friendly encryption approach could be designed, which would make encryption and description easier/faster, but at the expense of making breaking them quicker as well.
Most of our encryption approaches work on the idea of using a process that is exponentially faster to do forwards then backwards. This works very well with computers, where doing tens of thousands of calculations a second is slow, causing that exponential difference in encryption vs breaking time to be pretty huge. However, exponential approaches work because of how well they scale up as you add on calculations; however, it takes quite a few calculations for this difference to become really noticeable. 2^20 may be impressive at over 1,000,000; but 2^3 is only 16, which is a bit smaller... Because humans cannot work at nearly the same speeds as computers the exponential difference is not as drastic, which in turn means you need to invest far more time to encrypt a message before you have a message that is unbreakable.
Rather then going into big O and a proper analysis, which will cause non-geeks to lose me, I'm going to cheat with a lazy example that isn't entirely accurate representation of encryption vs breaking costs, but should get across my general point. Lets say you have algorithm that takes exponentially longer to encrypt then break. for this example...
Being exponential f it takes me one second to encrypt a line it may take 1 second to break it. if it takes me 2 seconds to encrypt the line it may take 4 to break, 4 to encrypt is 16 to break etc etc, the longer I take to encrypt the longer it takes to break.
However, your enemy has an advantage on you. He only needs to break one message, at which point he has figured out your key and can use it to easily decrypt all your messages until that key is changed, whereas you need to send messages all day. Thus he could easily, for example, allocate 30 people to trying to brute force a single message for an hour to brute force your key. So he gets to put in 108000 man-seconds of effort to break that one message. Even using an exponential algorithm to encrypt every line to prevent it from being easily brute forced, your going to have to invest over 2.5 minutes a line to encrypting the message to avoid your enemy being guaranteed to break your message in an hour with his 30 man team.
Thus it takes you 2.5 minutes to encrypt the message, and your ally another 2.5 minutes to decrypt the message, in order to have any sense of security about the message. If the enemy hires a few more code breakers, or works until lunch break, well you better be willing to wait longer. You can't necessarily afford to spend 2.5 minutes per line with all the messages you have to send in a day, and some messages are too time critical to wait 5 minutes for the receiver to understand them.
Now, the above is not an entirely fair example, but it does show my point. because humans are so slow to do encryption the power of encryption approach that relies on efficient big O to make it prohibitively expensive to break your encryption is lost. It doesn't matter how well you scale up if your always going to have such tiny starting numbers.
ACCURACY:
There is ALLOT of math in our modern cryptography, math that computers do with (almost) perfect accuracy. Humans are more fallible Humans will have a hard time keeping up with and accurately performing the math required to encrypt and decrypt these messages. One error will likely compound on itself to register an entire section of the message gibberish until someone goes back and does the math over again. Anyone who has ever done any linear algebra by hand can vouch to how quickly even absurdly simple arithmetic can be screwed up when you have to do it enough times.
In addition, this assumes that the original binary was sent across the telegraph correctly. If you ever stared at a long line of 1 and 0 you would find out they blur together quickly. Having a human have to read the numbers correctly to transmit them, and another human write them down correctly, is hard enough. However, imagine you are listening to a stream of dots and dashes that don't make sense. How long will it take before you lose track of how long someone held the button down, so your no longer sure if your listening to a 1 unit dot or a 3 unit dash. The sounds will blur together and be recorded wrong. There is no way to go back and say "oh that's clearly an A not an X, I must have got my dash wrong" when you make a mistake.
Well, the above paragraph is not entirely true. remember computers are only nearly perfect at arithmetic, and they sometimes 'mishear' messages sent to them as well. There are complex tricks used to fix the fact that computers will not always be certain rather they heard a 1 or a 0 being sent to them as well. The easiest to understand is the idea of a sanity check at the end of a 'word'. For instance a basic sanity check that can sometimes tell you rather you misheard a section of a message by telling you how many zeros (or dots in Morse code) you should have heard, if you have a different number of dots then they say you should have you know you made a mistake...but not where.
However, most of our more complex error correction approaches also depend on math, more math then a telegraph operator can do on the fly. A basic parity check is not enough, because later (when) someone screws up the math decoding the message their be left wondering if their math is wrong, or if the telegraph operator recorded the value wrong. Thus your need a very robust error detecting block, which makes the message take 10-15 % longer to transmit, and requires more time of back and forth asking for help correcting words that you got wrong.
In short the process of correcting yourself is going to be quite difficult, and thus time consuming.
YOU HAVE TO KNOW THE KEY AHEAD OF TIME:
There are two types of encryption we use. One involves two sides both knowing ahead of time the 'key' that the other side will be using. The other involves neither side knowing the key ahead of time.
asymmetric, where neither side knows the key ahead of time, would be quite useful. this works by telling everyone your public key, which they can use to send you a message, because only you with your private key can 'unlock' a message locked with your public key. This is limited by the fact that these approaches take much longer to do, and as I said above this would be too slow.
However, there is another limitation. With this approach you have no way of proving who you are. How do you know it's not a nazi at the other side of the line (or standing anywhere between the two lines by physically taping your line)? With modern computers we ask a third party to help us out by 'signing' a key. Without going into detail this involves having someone we trust that we can say "is he who he says he is" and the third person says "yep, totally", and it works because we already know how to safely talk to the third person. Unfortunately, I don't think you can really manage the equivalent of trusted Certificate Authority that can sit in the middle of messages and double check who everyone is.
Thus your limited to symmetric, where each of you know the 'key' that your using to communicate.
Now there is nothing wrong with symmetric by itself, other then the fact that you need to collaborate ahead of time to share this key. If your enemy gets hold of your key, by attacking you, bribing you, or tricking you, they have now broken you.
Now lets look at the alternative option that Thucydides mentioned, a book code. You pick a specific book and you use the words of the book to encrypt your message. Without knowing the book ahead of time, or having the massive processing power computers offer which allows statistical analysis, these book codes are nearly unbreakable (with certain well known precautions). If your enemy knows your book you are broken, if they don't your effectively secure. You are as well off carrying your book around as you are carrying your private key around. In both cases you have a thing that if the enemy gets you are broken.
However, the book, or one time pad, is actually safer! The number of people required to do all that math to translate things back and forth for modern encryption requires telling multiple people your key. Since your key must have a minimum number of bits to be used everyone is likely to memorize the key their using quickly (it's small enough). now you have many many people who each contain within their head everything your enemy needs to break your code. You've spread the secret out across too many people, and created too many avenues of attack other then brute force attacks.
A onetime pad is easier to secure, just as unbreakable, quick to generate, and faster to encrypt and decrypt. A book code allows changing of the 'key' from a distance. a combination of these approaches can provide effectively the same security without the massive expense and time that our modern encryption takes.
