In school, I enjoyed Science. Figuring Out, and Understanding, and the teachers I had, were Cool.

Sadly, no one told me about engineering... Making Things Scientifically, until it was too late to pursue a career there.

"Design" is an important part of engineering. And learning to do design well would be useful to anyone, in any lifestyle. It's a bit like a hammer. If I give you a hammer, you may be a bit nonplussed... but if you put it to one side, the day will come when you find you have a use for it.

Let's briefly talk about designing a vehicle. Do you want a tricycle? A yacht? A fighter jet.

It depends...

It depends on what you have, what you need, what effort you consider worthwhile.

And it is the same with codes and ciphers

Cryptography Design Factors

"The right" cipher for your needs will depend on the following. If you use a bit of imagination, you can see the impact of these parameters on what will be good for a particular combination of requirements and opportunities.

The huge range of possible combinations, and the resulting huge range of "right answers" is part of what keeps me fascinated with cryptography. I hope some of my fascination will rub off on you.

Some of the following may seem far-fetched. I don't think any of them are... but it may take you a moment to imagine circumstances where the requirement or opportunity would pertain. By all means write me, ask "When would that be relevant?", if you think I've included too much.

Requirements

Users Who? Who is going to use the cipher? Bright person? Dull person? Will you need a system which allows one? a few? hundreds of people to read something that you have sent out in encrypted form? (The more people who know anything about what you are doing, the more chances there are that one of them will let something slip to the wrong person, e.g. what cipher is in use, or, worse, what key. I'm with Mark Twain: "A secret is safe if only two people know it. And one of them is dead.")

Enemies Who? Who are you trying to "keep out of" the message? Younger people in your own family? The NSA?

Where? Will the cipher be used on a private computer, in the user's home? Simply so that he or she can keep something private... say a list of passwords for internet sites? Or will a member of some country's Secret Service be using it in hostile territory? On a website, say, Amazon.com, where thousands of strangers mingle? (Cryptography is used there to safeguard your credit card details as they pass from you to Amazon through channels which, while not "easy" to tap, can, if you are sufficiently motivated, be monitored in some circumstances. Willing to steal from someone? What if I give you access to the credit card details for, say, all the people ordering from Amazon in the next hour?)

How strong? How hard must it be to break the cipher?

How serious? How much will it matter if someone does break the cipher?

How fast? (Almost) every cipher can be broken. But if you can ensure that it can't be broken quickly, that may be all that's needed. And how fast can legitimate users encrypt and decrypt things by your scheme?

How awkward? How important is it to you that encrypting or decrypting (for an authorized reader) be "easy"?

How often? Do you need encryption for "one job", just once? Do you need something for "everyday"? Something in between?

Not only does the answer affect how easy it will be for you to use it, but there is another consideration, too. For occasional encryption, it had better not be too complex, or you will forever be cursing yourself for having forgotten a process which you once knew. The other consideration is this: The more you use a particular cipher, the more material there is which The Enemy could, in theory, have access to. And if you have a large volume of material all encrypted with the same cipher, the better your chance of an unauthorized decrypt. If it is all done not only with the same cipher, but also with the same key, so much the better.

Volume and nature: How much material do you need to encrypt? A quick "Meet me at the 39 Steps at midnight?" Or the full specs for a nuclear missile?

Photographs? Or just text? An audio signal, perhaps? A TV signal?

In respect of volume: Not only how big is "the message", but do you need to send just one... or many?

Project lifetime: Do you want to protect the contents of an important corporate announcement until the agreed release date, next week? Or keep private some financial records you don't expect to need to look at again, but may need to read 10 years from now?

Audit: Do you not only need to try to keep something secret, but also need to know if someone has succeeded in looking at it? This requirement is tricky... unless you go the "ink-on-paper, (well) sealed in an envelope" route... and even then, you don't know who looked at it. Is this important? If it was in the care of a messenger who's job was to keep it unread, then knowing the messenger failed may be enough. On the other hand, if you are not only afraid that someone might look at the message, but also tamper with it as well, then cryptography can help you detect unauthorized changes to material.

Detection: You want to prevent others from seeing something. Do you also want to keep the fact that there's something to read from them? If you can achieve the latter, you don't need to worry too much about the former, do you? You may go for a mixed system. Revealing the presence, maybe even the contents, of the ciphertext may be unavoidable. But, with a bit of imagination you may be able, in some circumstances, to "send" (or store) the key for that material with the ciphertext, but out of sight of The Enemy.

Is "lossy" acceptable? In a perfect world, if I want to send "The invasion will be in Normandy on the 6th June", I want ALL of that to arrive. Depending on the system you are using, the following may be sufficient: "The invasion.. Normandy.. 6th Jne". Some... not many, I would suspect, ciphers will tolerate a certain level of loss of information in the transmission of the ciphertext. If your system is not loss tolerant, that has implications for other parts of the design. See "compression" below.

Does compression help? Expansion matter? The sort of simple substitution ciphers that are fun to play with, but of not much practical use do have one virtue. If the plaintext is 25 characters, the encrypt is 25 characters, if you elect to leave spaces and punctuation in place.

If you want to make unauthorized decrypting difficult, one ploy is to litter the message with "rubbish". (A very simple scheme: Tell "Bob" that you're using a simple Caesar cipher, but he should ignore the first 13 characters of the encrypt, and then use just every fifth character.) The only problem is, a short message becomes a long encrypt. If the messages you need to send are up to 20 words long, and you are sending them by email... no problem! If you are sending 100 word messages by radio from Nazi held Norway, you don't want to give the radio detection vans time to take their bearings.

That was a crude trick using expansion. If you can allow even modest expansion, all sorts of things become viable.

So much for the matter of message expansion. What about compression?

There are many tricks for compression which may make the transmission or storage of lengthy messages more convenient. Compression often requires that you can accept a lossy process.

For a simple idea drawing on several aspects in this, consider the following: Suppose you have email, a computer and a digital camera available. Write the message on a piece of paper. Photograph that. Run the image through IrfanViewer, adding as much compression as you like, so that you don't have to be online too long. Run the resulting jpeg through a simple program to reverse the order of each pair of numbers in the file. Send that. As long as your "Bob" has the computer program to reverse your last step, everything else about the process only uses standard or freeware elements.

Spot the flaw? Nothing wrong with the "plan"... but it wasn't a very good example of a place where you might feel compression helpful. Either send the text as (encrypted) numbers (one number for each plaintext character), and have a nice small message, or use the "do a picture first" if there are other reasons to do that... but no jpeg, however much compressed (if still readable!) of the text is going to be smaller than the number-per-character version.

Opportunities

Cost: What can be spent building and maintaining the cipher, and access to everything by authorized individuals?

Communication channels: Many texts which you would wish to encrypt need to be sent to one or more recipients. Are you going to see the recipients face to face? Do you want to put the message down as ink-on-paper? Send it via the internet? Besides the encrypted texts, you will probably also need to share keys.

Technology: Is it okay to assume that Alice (ciphertext sender) and Bob (intended recipient of message) both have a computer, with the right software? Do you need a system that can have one or both parts (encryption/ decryption) done with simpler things than a computer? Pencil and paper? In the head?

Specific instances

So much for the broad questions and parameters.

By way of illustration of the I hope interesting combinations of requirements and opportunities which arise, consider the following...

Secret Agents: Traditional "Code" Stuff"

Say "codes", and most people immediately think of espionage. And the work of secret agents has certainly been important, for good and for evil, for centuries... even if James Bond may not be a very good picture of what real spies do. And spies use both codes and ciphers, each having their pros and cons.

And don't forget that espionage isn't limited to inter-government relations. Industrial espionage is an industry in its own right. With a sub-division for industrial spies spying on the industrial espionage industry, no doubt!

Until personal computers became available, there were severe limits on what ciphers could be used. Some very strong ciphers would be virtually impossible to implement by hand.

Spies and their masters have two problems, problems with very different parameters: The spymaster probably would like to be able to send messages to the spy while on a mission, and the spy may want to send messages in the other direction, too.

The spymaster has things easy... he can work in a secure environment. He can draw on a staff of helpers. He can have equipment and papers with only one purpose: Cryptography or coding.

The spy, while of on his or her mission, will be in a much tighter corner. Being found with a code book, if it was recognizable as such, would be A Bad Thing.

Both of them also face challenges in respect of communication channels. Even if the spy has "perfect" provision for encrypting "the attack will be in Normandy, on June 6th"... without some means of getting the encrypted text to Berlin, the spy's discovery won't matter.

In modern day (2014) India, access to satellite phones is very difficult. It is not just "back in history" when secure communications channels were limited.

On the other hand, design matters are seldom symmetrical. While it may be hard for a spy to send a message out, getting a message to your spy is a different matter. Still "hard", but in different ways. To take another example from WW II, most people know that the BBC used to broadcast "personal messages" after the news.... "Mr Henry L Smith announces that his daughter Sophie has had a baby boy, 7lbs, 4oz" would mean little to anyone listening. And (almost) anyone could listen. I don't think... correct me if I'm wrong?... having a radio receiver wasn't nearly as dangerous in Nazi controlled areas as having a transmitter. But if your spy had been told to look out for a message "from" "Henry L Smith", and that "Sophie" meant "pickup from the St Omer landing field, "Hazel" meant pick up from the Hazebrouck field, and 7lb meant 7 days from now, and 4oz meant 4am.... you get the idea? Communications channel problem solved. Need for an intelligent "Bob" greater. Always trade-offs.

Messages to spies by radio almost certainly didn't die with peace in Europe after the defeat of the Nazis. Wikipedia has an interesting article on the so called "numbers stations" which could (can?) be heard from time to time on certain radio bands.

If you can send "Mr Henry L Smith announces that his daughter...", you can send "3, 1, 20"... which would "spell" "cat" in plaintext. And if you can send "cat", you can send more complicated things.

If you don't mind your spy having a computer with some fairly general purpose, and in any case quite "hide-able" "extra bits", you can even fix things so that it plugs into the earphone socket on your radio, and "reads" the numbers from the broadcast directly, saving the spy the tedious business of entering them into the decrypting mechanism.

Charges against spies accused of listening to numbers stations continued into the 2000s. The old ways are sometimes good ways. Simple can be good.

A few simple messages, in a non-hostile environment

I believe I am right in saying that the "one time pad" is an unbreakable cipher.

So why are any others ever used?

Key generation and distribution problems. And equipment requirements.

Good "pads" aren't as easy to generate as you might think. Management of the pads, by Alice and Bob, would be tedious, if there were many messages, or even a few long messages. (You'd need to be able to call up the right pad for each message. A different pad for each.)

Doing "one pad" encryption is tedious by hand, and you need a pad. Doing it with a computer isn't hard, but now you have computer and "pad" (inside the computer, in virtual form) which are subject to loss (bad... you can't read your old messages any more) or theft (worse... your messages might reach the wrong eyes), AND (computer and pad) may "tell" people you don't want to know that you are sending secret messages.

So. Very strong cipher... but with drawbacks.

Teenager doesn't want sibling reading diary

(And a wide variety of situations which while not immediately obvious as "parallel" to this are, actually!)

Write the diary with a wordprocessor. Keep it, and similar, in a folder called "ShoppingLists" (Sibling may not even get as far as looking there, thinking "Shopping lists would be boring.")

Save the document "with a password". I.e. save it so that when you re-open it later, it won't open until the "password" is supplied. (The password, as mentioned elsewhere, is really a key. The key is used by the cipher built into the wordprocessor both to encrypt, and decrypt the file, as it goes, respectively, to and from the hard drive.

Feeling cheeky? Use "ShoppingLists" as the password for the files in the ShoppingLists folder. You will probably remember the password, and few Bad Guys are likely(?) to try that.

Computers are out.

It isn't always possible, sorry, to have a computer available as part the opportunities for the design.

Certainly if you are interested in some code or cipher from before, say, 1945, a computer wasn't part of it. That doesn't mean that codes and ciphers didn't exist!

Simple substitution will never be very strong protection for your message. But substitution-with-tricks can boost the strength, without making the complications of using the cipher escalate too rapidly.

The Vigenère cipher was thought to be "unbreakable" for hundreds of years (in spite of Babbage decrypting something... but he didn't tell people how, and it took a while for someone as bright to come along again). And you can encrypt and decrypt things with a Vigenère cipher with little trouble. If the plaintext is 50 characters, the encrypt is 50 characters. All in all, quite a neat cipher. Not "NSA proof", if they get their hands on a reasonable amount of material encrypted with the same key. Easy for someone to get into, if you let the key fall into the hands of that "someone". But pencil and paper will do. But it is "just" substitution, with a trick. (It is easy to add a few other tricks, to "encrypt the encryption", if you want to.)

I mention it, though, to counter any feeling that you may have that "only with a computer do you have enough power for 'serious' encryption."

Have you heard of Flattr? Great new idea to make it easy for you to send small thank you$ to people who provide Good Stuff on the web. If you want to send $$erious thank yous, there are better ways, but for a small "tip" here and there, Flattr ticks a lot of boxes which no one else has found a way to do yet. Please at least check out my introduction to Flattr, if you haven't heard of it? "No obligation", as they say!

Search across all my sites with the Google search button at the top of the page the link will take you to.
Or...

Search just this site without using forms,
Or... again to search just this site, use...

The search engine merely looks for the words you type, so....
  *!  Spell them properly   !*
  Don't bother with "How do I get rich?" That will merely return pages with "how", "do", "I", "get" and "rich".

I have other sites. My Google custom search button will include things from them....
   One of my SheepdogGuides pages.
   My site at Arunet.

Ad from page's editor: Yes.. I do enjoy compiling these things for you... I hope they are helpful. However.. this doesn't pay my bills!!! If you find this stuff useful, (and you run an MS-DOS or Windows PC) please visit my freeware and shareware page, download something, and circulate it for me? Links on your page to this page would also be appreciated!

This page's editor, Tom Boyd, will be pleased if you get in touch by email.

Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes. There were two "unknown attributes" in Google+ button code, two further "wrong" things in the Google Translate code, and similar in Flattr code. Sigh.