Bookmark this on Delicious
Recommend toStumbleUpon
There's nothing very scary about the basic idea of a key. But please bear with me; get past the introductory material. The basic idea isn't scary, but some of the cleverness in how keys are used in cryptography will, I hope, interest you. Or at least inspire- be you a maker of ciphers, or a breaker.
Even in crypotography, a key is still more or less what a five year old thinks a key is.
Imagine a small village of 100 homes, but even though it is small, the inhabitants are careful and lock their front doors.
It is unlikely that they will 100 different kinds of locks. But even if Mr Smith and Mr Brown have Yale locks on their doors, Mr Smith can't open Mr Brown's door, can he. Same mechanism, but not exactly the same. Mr Smith's key only open's Mr Smith's lock.
Many ciphers use one or more keys. Let's start with a reminder about....
Your cipher is the "rule" you use to encrypt something. A crude cipher is "add 1 to each letter"... e.g. make A b, B c, etc... a very simple Caesar cipher. (In the village analogy, the cipher is the brand and model of lock the homeowner is using.)
To illustrate a key in action, let me first define some simple "alphabet arithmetic": If I say "add A to a letter", it means, for this example, that you "add 1", as we did above with the crudely appiled Caesar cipher, A was turned into b, etc. (If you "go past the end", e.g. try to add E (5) to, say, Y, then you "wrap around", and the encrypt of Y, "with D added" would be c.
Now let's say that our cipher is that we take the plaintext, let's say, "CAT", and add, one after the other, the letters of "the key". If, today, the key is a very weak "ABC", then CAT becomes
C A T plaintext. 1(A) 2(B) 3(C) key (ABC) and "what to add" d c w encrypted version of plaintext.
(In a simple cipher like this, for a longer message, we just repeat the key over and over, as needed.....)
THE CAT SAT ON THE MAT "long" plaintext ABC ABC ABC AB CAB CAB key, repeated as necessary hjh dcw tcw pp wig pbv encrypted version
That's a simple key used by a very simple cipher. But, if you think a little, you can see the principles of "what is a key" from the example.
We could code THE CAT SAT ON THE MAT again, using the same cipher (rule), but a different key. This would result in a different encrypted text... but no "learning curve" for encrypter or decrypter.
Reminder: In crytography texts, "Alice" refers to someone who wants to send a message securely, and "Bob" is her intended recipienct, who is supposed to have an easy way to decrypt the ciphertext.
One cipher can be used by muliple pairs of Alices and Bobs, all using the same cipher, without one pair being able to read the messages of another... as long as each pair keeps the key they are using with the cipher a secret from The Enemy, including other Alices and Bobs.
"All using the same cipher." Why would they do that? Why not? If their circumstances and needs are the same, presumably there is one cipher that best fits them. Or maybe they all work for the same organization, and standardization has been deemed useful? Maybe one Alice is talking to multiple Bobs... Bobs who must not be able to read the messages to any of the other Bobs. You're not going to ask Alice to fool around with multiple ciphers, are you? As long as she uses a different key with each Bob, all will be well.
If Alice and Bob are using a symmetrical key, they each use the same key. Alice uses it to encrypt the message, and Bob uses the same key to decrypt it. So, obviously, they must both know the key.
But how does Alice let Bob know what the key is? This can be quite a problem in some circumstances...
Which creates scope for fun! What clever schemes can you devise for getting the key from Alice to Bob without making things so complex that errors will arise, or so simple that The Enemy will get ahold of the key?
If you study how serious cryptographers have overcome the problem of key sharing over the years, you will begin to appreciate the whole picture.
I believe that the idea of asymmetric keys is relatively new. It mostly solves the problem of key exchange... for the moment! So far, for every new idea in cryptography, each new "unbreakable" code, someone has... except, so far, for the latest, as far as anyone is admiting... found a way to break it.
Asymmetric keys, for all their merit, do not solve the problem for, say, a Secret Service spy found in a hostile environment with a computer programs for cryptography, and illegal communications equipment. See how cryptography is a fun web of different circumstances and design requirements?
Asymetric key encryption is widely used today because there are strong systems available, and because the problem of key distribution is significant. Examples: RSA and PGP, which are cipher systems you won't break, but should know at least a little about, if you are interested in ciphers. You can use, for free, descendants of PGP. ("Pretty Good Privacy". Name inspired by elements of Garrison Keillor's wonderful News From Lake Woebegon.)
(I am going to describe "old PGP" here. Since "the good old days", PGP has been upgraded, adding furher layers to the basic idea. I should note that the earliest PGP used mere symmetric keys. Also, there are interesting moral and legal questions around the creation and use of good ciphers, which are explored in parts of the Wikipedia article on PGP.)
If Bob wants to receive messages using, say, PGP, he needs TWO keys! One is his "public key". He can give this out on his website, for all the world to see. The other is his "private key", which he keeps, well, private.(!)
If Alice wants to send Bob a message, she uses his public key to encrypt it. Bob (with a computer!) can easily decrypt the message by putting the encrypted text into the computer along with his private key.
But no one else can decrypt the message without the private key.
Isn't that cool? If you are The Enemy, you may have obtained a copy of the encrypted text. You can easly oftain a copy of the key used to encrypt it... and yet, even so, you can't decrypt it!
If Bob wants to reply to Alice, he needs for Alice to have obtained her own public and private keys, he needs to know her public key, and he needs a computer to do the encryption. (His keys aren't used if he is responding. Messages from Bob to Alice are a whole separate story. Essentially, Bob "becomes" Alice, and vice versa. If you have two people talking to each other, sending messages both ways, you need four keys: Two public, two private.
"Could Alice put her public key on her business card?", I hear you ask.
Well... the world has moved on from the early days of asymmetric keys. Even then, the short answer was "no... impractical... too long." Now the keys are WAY too long, and to further complicate things, they are "wrapped up" in "certificates", anyway. They are a whole new subject, which I'm not going into here.) But! All is not lost. The practicalities of obtaining a machine readable copy of what Alice needs to encrypt a message she wants to send to Bob are all dealt with, thanks to computers and the interent, or other distribution media.
If you want to consider using, for free, a cipher based on asymetric keys, go to the homepage of the Gnu PG ("Pretty Good" (Privary)) project for more information.
"Gnu"? The name adopted by a project, tremendously important to all who love open source software. "Gnu, Not Unix". (Think about it!) We wouldn't have Linux, Open Office, Lazarus, and much, much more with out the Gnu Project. (The word is also a synonym for "wildebeest").
Long ago, and far away, "everyone" used a nice little program to create and to unzip "zip" files. That was back in the day when it was important to compress things because disk space and transmission speeds were limited. It was given to the world by Phil Katz. PGP was written by another Phil, Phil Zimmerman, and he started work on PGP while working for the first Phil. PKzip was important to many people, but Katz didn't insist on large profits from the very useful tool which so many people used widely.
Besides bringing us first PKZip, and then PGP, Katz and Zimmerman and others fought tremendously dangersous (for them) battles with governments, who didn't like the idea of private citizens being able to keep their communications... private. Whether it is a Good Thing that private citizens (and criminals, and "freedom fighters ("terrorists" who happen to be on "our side") can, for the moment, use powerful encryption is another discussion... with no simple answer. None I've come across, anyway. The UK government decided "no", passed a draconian law that tramples civil liberties, and opens the door to dastardly acts against innocent people by Bad People in the general population. And the Great Unwashed didn't call the lawmakers to account for doing so.
Asymmetric keys solve one problem... the distribution of keys... but another problem looms, in some cases. Suppose someone sends you a message saying, "This is the NSA, we need your help... please reply using the attached public key."
How do you know that message really comes from the NSA?
That problem is solved by other means. Solving that problem was never part of the reason for asymmetric keys, so the fact that they don't solve it doesn't really steal any of their thunder, does it?
None-the-less, systems like PGP have "tricks" which help with the extra problem, too. Which I am not going to address today!
If you are still reading, you deserve more reward than you've already had, I hope. I hope you have acquired some new knowledge. I hope it is useful. Maybe even interesting... but the chances of the last are, perhaps, slight. But I have considered carefully whether I think you need it enough to be worth the reading. (Writing it was harder, remember!)
So to finish this page, something I hope you will agree is fun... even if it is "keys" related.
Suppose you've written an important document which you want read only in special circumstances. A list of your user name and passwords for web-sites you use, for instance. And the "special circumstances" are "if I am hit by a bus, and my executor needs to close various accounts".a
Now, you could of course, just print the list, ink-on-paper, and put it in an envelope, and give it to someone you trust. But where's the fun in that? In any case, that "answer" won't meet all needs.
So, you save the document as a computer file, and lock it with a key. Your wordprocessor probably allows you to save things in a "password protected" form. The "password" is a key, to a cryptographer.
Before we go any farther: Remember that whoever is supposed to read this will need a computer with the same wordprocessor as you use. It may even have to be the same version of your wordprocessor. Probably safer to save the document in a widely supported format... pdf comes to mind. If you use the free Open Office's "Write" wordprocessor, you can export to pdf, and "lock" the document with a "password"... i.e. encrypt it (by something specified in the pdf standard), the "password" being the key for decrypting the document.
"But!," I hear you say, "that's not much better. I have to give the key to someone, and so it is still just a matter of trust that they won't open it at the wrong time."
Well... partly true. But. We HAVE made progress over the plaintext as ink-on-paper, in an envelope. It that were misplaced or stolen, anyone could use it. As long as whomever you have trusted isn't foolish, the .pdf and the password won't be stored together. So if either goes astray (or is stolen) without the other, it isn't of much use.
But it gets better!... in two stages. Don't think you know all of what's coming when you anticipate the first bit of "better".
One person may fall to temptation, if he/ she can act in secret. What if there was a way to prevent the opening of the document unless TWO (or more) people were in agreement that they weren't opening it "a bit early"? ("Opened it a bit early", with a sheepish grin, is a quote from something dear to me. Any friends who what to prove they've read this, and know me, can give me great pleasure by identifying who said that, and in what circumstances!)
Suppose you "locked" the document with the following key: "WeAllStandTogether".
And your friends Dick and Kate are the ones who've accepted the chore of Dealing With Everything, should you not see that bus. Tell Dick "The first part of the password is "WeAllStand"". Tell Kate "The last part of the password is "Together"".
But... and here we have a nice example of how the design requirements dictate choices...
Suppose what's in the document is really, really important? And that there's a real chance that You Won't Be Here when Dick and Kate need to read the document?
(What I am going to add to what we have so far also gives protection against one of them not being available, or of one of them losing their half of the password.)
Bring in a third almost-trusted person. "Give out" the password differently.
Can you see a way... one that can be scaled up to other numbers, by the way... of "giving out" the password so that, say, any two of the password holders can access the document, even if the third isn't present, or has lost his/ her part of the password?
Read no further until you are ready to be told the answer. You may want to try to figure one out for yourself, before hearing my solution....
... The answer is just a little farther down the page now...
Here's what you do, using the same password as before: "AllStandTogether", with "Kim" the added trusted person...
Give Dick "WeAllStand", and tell him that it is the start of the password. Tell Kate that "StandTogehter" is the last part of the password... and here's the new, and tricky bit... tell Kim that the password starts "WeAllS..." and ends "...dTogehter."
Now, any two of the three trusted people can open the message when the time comes... but none of them can open it on their own. All through an elegant use of a key for decrypting a ciphertext!
It may amuse you to know that I spent many hours on a "clever" computer program to achieve the same "any two can open it" result... before realizing that any key-based cipher could do the same job without further ado, if you distributed the key along the lines indicated. Sigh.
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!
Keys for Cryptography, a Flat Earth Academy guide.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.
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.