private line magazine and e-zine back issue text archive. Caution when using any material here which is now very much dated.
- (1)_(1A)_(2)_(2A)_(3)_(3A)_(4)_(4A)_(5)_(5A)_(6)_(6A)_(7)_(7A)
- _(11)_(11A) (12)_(12A)
THE FIRST PRIVATE LINE E-ZINE!
by Tom Farley
(916) 777-4420 Voice & FAX P.O. Box 1059 Isleton, CA 95641-1059 USA
Thanks to Rich Adams, Dayglo, and Vamprella
I. Editorial Page
II. Updates and Corrections
A. An apology to _Cellular Networking Perspectives_
B. A.E.'s most excellent demarcation points
C. A new telephone related hardcopy zine from Canada
D. The 1996 International Directory of Telephone Museums
E. Download this! -- Nortel's "Telephony 101" pdf file
III. Letters
IV. Encryption Basics by Rich Adams
A. Introduction
B. The Julius Caesar Cipher -- substitution algorithms
C. World War II -- cryptography becomes science
D. The downside -- problems with shared keys
E. A New Dawn: public key cryptography today
F. Concepts -- understanding basic public key ideas
1. Editor's note on keys
G. Stepping through encryption -- the process
H. Pause for discussion
I. Stepping through encryption continues J. Conclusion
V. Reprint from _private line No. 1-- The GTE RTSS phone
VI. Adventures in Semi-rural telephony -- Isleton telephone service by Tom Farley
A. Introduction
B. Isleton looses long distance and 911 for a day
C. Life under GTD5 (Revised)
D. Free payphone calling in the 916
E. Fun with AT&T
VII. History: Fire! - The Bell System's worst single service disaster
VIII. _private line_ general information
IX. The last word: Vamprella's Hacker Manifesto
I. Editorial Page
Welcome to the first _private line_ e-zine. Comments, corrections and contributions are always welcome. Feel free to distribute freely but respect the copyright of any particular author. I suggest you put the e-text of all _private line_ back issues and the contents of this e-mail version into one giant text file. Then use your word processor's "Find" utility to look up what interests you. Got some funny looking line breaks? Reduce the font size a point or two and that should clear things up.
I am humbled by the response readers and subscribers of _private line_ are giving me to the the demise of the hardcopy magazine. I've received dozens of nice notes and letters of support. Thank you all. Many people want nothing, some want back issues. Not a single request for a refund has come in. Much as I appreciate this, I must state once again that I will honor any refund request. Just drop me a note and I'll take care of you.
Rich Adam wrote this issues' lead article; a well done encryption introduction for _private line_. As with all things cryptographical, it's necessary to go over it slowly. Print it out. Draw some diagrams or flow charts. Read a basic encyclopedia article on encryption later to see if they phrase things in a way you might understand better.
Web site development over at privateline.tv will start as soon as I complete mailing this. The next issue of the e-zine will contain some original writing by myself on prison phone technology. Let me know now if you have experience with this subject so I can incorporate your comments.
On a personal note, I have recently fallen in love with a woman named Nancy. She's everything I've ever wanted and I am quite overwhelmed. This 38 year old bachelor thought he'd never find the right person, however, I know now life is indeed endless with possibilities and hope. Gone, forgotten or abandoned feelings are all coming back. This is a happy time for me and I hope it is a happy time for you as well. Best wishes,
Tom Farley -- privateline@delphi.com
-------------------------------------------------------------
II Updates and Corrections
A. An apology to _Cellular Networking Perspectives_
The January/February _private line_ (No.10) featured a _Cellular Networking Perspectives_ article by David Crowe that I copied without permission. I used his article to fill space at the last minute. Another writer's promised article never came in. At the last minute I dropped in David Crowe's article, hoping that the positive publicity might be enough to compensate _Cellular Networking Perspectives_. That was wrong, of course, and I apologize. I should have picked up the phone and asked. Deadline is a terrible thing and I worried that David wouldn't give permission. David was nice enough not to send the Mounties out and to keep me on his mailing list. You need this newsletter if you make your living with cellular. Check out the following for more information:
http:www.cnp-wireless.com/cnp-wireless
B. A new telephone related hardcopy zine from Canada
_Voice On The Wire_ (the operator/telephone culture digest), is a simple, engaging, personal zine by Judith Beeman about telephone operator issues. This eight page photocopied zine from British Columbia is definitely worth two American dollar bills. What's the theme? This is how Judith, an operator with BC Tel explains it:
"What's not to love about being an opr?! The hours are great (I am not a morning person); I talk/assist/people people without face to face contact (not that I am antisocial...); the chairs are comfy and our work positions modern; I dress casual; get to speak with those charming male operators in the U.K. once in a while and -- now this is crucial -- the work leaves me plenty of time for other hobbies and interests. Being an operator is quirky and definitely a dying breed . . . I truly enjoy my work and hope it'll last for many more years."
The debut issue features cartoons, commentary and real life stories about being an operator. There's even a reprinted book review from _private line_.The well done lead article features Rick Wehmhoefer's story -- the Bell System's first male operator. _Voice on The Wire_ shows promise and I look forward to future issues. By the way, articles, clippings, cartoons and clip art about operators are solicited. Send one dollar if you live in Canada and two dollars if you live in the United States to:
Voice on The Wire #4636 MPO Vancouver British Columbia V6B 4AI
Or contact VOTW at beeman@mindlink.bc.ca
C. GTE's most excellent demarcation points
I wrote a little about the demarcation point in _private line_ No. 7, in the article on outside plant. A photograph and an illustration pictured WECO (Western Electric Company) units. Here in Isleton we have Automatic Electric units. They are much neater in appearance and best of all they include a normal phone jack in each one. No more messing around with alligator clips to test the line. Beige boxing, I mean, service and repair, is much easier. Got a problem with your phones? Repair will often ask you to call out from the service terminal before sending a lineman. In my case, heavy, intermittent static is plaguing my phones. When tested at the demark point, however, no static is present at any time. I have some investigating, therefore, to do of my inside wiring.
D. The 1996 International Directory of Telephone Museums
The Telephone Historical Centre of Edmonton, Alberta has once again published their invaluable directory. Issue No. 9 is 23 pages long with 180 listings. Edited by Nellie Anquist, Isabel Peters and Susan Anderson, with direction by the Centre's Executive Director, Bert Yeudall, this directory continues to be the only semi- comprehensive source to telephone museums. I say semi- comprehensive because many entries list a museum but there is no current information to go with it. That's a shame. More people ought to buy the directory, visit a museum with little information, then send current info to Edmonton. Although this may be the last directory to be published for several years due to budget restraints, the Centre will continue to "act as a focal point for collectors and telephone museums world-wide."
Purchase the directory for $6.00 plus $2.00 postage and handling. North American orders can pay with money order or check. Other orders are asked to pay with an international money order. Here's the mailing address:
Telephone Historical Centre P.O. Box 4459 Edmonton, Alberta T6E 4T5 Canada
Or pick one up at the Centre when visiting their museum:
10437 83 AVE Edmonton, Alberta Canada
Their phone number is (403) 441-2077. FAX is (403) 433-4068
E. 'Telephony 101' by Nortel -- an excellent, informative file
(Nortel has long pulled this file from their site. But I've archived a copy here and it's still a great read. Click here to download the 693K file in .pdf (internal link)
Been to Nortel's site yet? (http://www.nortel.com) If you're able, download and printout the Adobe Acrobat file 'Telephony101.' It's a well done, modern introduction to the telephone system. It doesn't have much on the local loop, so it's a little deceptively titled, but I really enjoyed it. It helps put current technology magazines like _Computer Telephony_ in better focus by explaining terms you've seen but perhaps haven't looked up. Here's one example involving SCAI (Switch-to-Computer-Applications Interface):
Switch-to-Computer-Applications Interface (SCAI) enables a central office to communicate information in its data banks with incoming and outgoing telephone calls. SCAI services include:
Coordinated Voice and Data -- provides an agent a screen of information about a caller concurrently with receipt of an incoming call
Third-Party Call Control -- permits a customer's computer to interact with Coordinated Voice and Data to place outgoing calls and provide telephony control from a call center computer
Voice-Processing Integration -- allows a host application, i nterworking with an Interactive Voice Response (IVR) system or Voice Response Unit (VRU) to obtain additional information about callers and direct them to the appropriate agent
Third-Party Agent Control -- enables an external host computer to log-in and log-out ACD agents through SCAI signaling
'Telephony 101' contains many clear diagrams. This file is 100 pages when printed out so get ready to download a *big* file. The Acrobat reader program is downloadable from their site for free, so you can view and print this document. It's worth the effort if you have a fast modem. I suppose you could call 1-800-NORTHERN to weasel a hardcopy of the document but don't say I sent you.
------------------------------------------------------------- III Letters
(Editor's note: these are just two of many nice letters I am getting. In the future, feel free to write in on anything the magazine is covering or should cover.)
Mr. Tom Farley, publisher, _private line_ magazine
I have received a satisfactory value from your magazine. No refund is necessary.
Best wishes, hope to see you on the Web.
James R. Niederlehner M.D.
Dear Tom:
I just received your letter last week explaining your position on why you were discontinuing your magazine. I must say that I'm sorry that your magazine will no longer be published, I thoroughly enjoyed all of your articles.
I first heard of _private line's_ demise in the latest issue of _Blacklisted!411_ magazine. I don't know what would become of my subscription , so I'm glad that you had written to me.
Again, I enjoyed your magazine and I don't want my subscription fee refunded to me, but I would appreciate it if you could send me issues #3-7. I already have issues #8-10. To complete my _private line_ collection I have enclosed $10.00 for issues #1&2.
Thanks for keeping me informed of your situation. I hope things go well for you in the future and I wish you well.
Sincerely,
Mark Curran, Santa Rosa
-------------------------------------------------------------
Excellent, free file on encryption by John E. Canavan from his Fundamentals of Network Security. This complements Rich Adams' article below (24 pages, 211K in .pdf)
Ordering information for the title above (external link to Amazon)
Encryption Basics by Rich Adams-Copyright 1996 by Rich Adams
A. Introduction B. The Julius Caesar Cipher -- substitution algorithms C. World War II -- cryptography becomes science D. The downside -- problems with shared keys E. A New Dawn: public key cryptography today F. Concepts -- understanding basic public key ideas 1. Editor's note on keys G. Stepping through encryption -- the process H. Pause for discussion I. Stepping through encryption continues J. Conclusion
(Rich Adams is a Communications Analyst and Network Operations Manager for Chevron Information Technology Company, a Division of Chevron U.S.A., Inc.)
First the disclaimer: this article is not meant to be a highly technical dissertation on encryption. When you are finished, you will not be able to rush out and design encryption algorithms to rival DES or IDEA. If you do, it's because you would have been able to do so before reading this. This is merely a primer to allow one to understand how encryption, public keys, and digital signature works, not the "why" down at the nuts and bolts level. If you wish more detail than this article provides, I would recommend Bruce Schneier's most excellent book, _Applied Cryptography_ (ISBN 0-471-12845-7 (second ed.), which explains the mathematics behind the algorithms along with the source code of some of the algorithms, completely researched with cross references to over 900 other sources.
Cryptography is a complicated subject, but the underlying principles are actually quite simple--almost deceptively so. Quite often the use of analogy is employed to illustrate the principles. For example, many of us might take the need for encryption as a given, yet others may not quite see the purpose. One of the most popular analogies is to use the postal service. If you had a message you wanted to send to someone else, and didn't want to hand deliver it, you could do one of several things. You could write it on a postcard and mail it, you could put it in an envelope and mail it, or you could slip it into a strong box, lock it, and mail it. If you did the last, you would then be faced with the problem of getting the other party a duplicate of the box's key, but we'll get into that later.
If we send something electronically, we are faced with pretty much the same choices. We can send it as we have been doing so far. That is analogous to sending it on a postcard. Whatever nodes or wires it crosses, it will be in plaintext, and easily intercepted and readable. Encrypting it is analogous to putting it in something. Using weak cryptography is like putting it in an envelope which could be steamed open. Using strong cryptography is like putting it in the strong box.
The first recorded use of cryptography was in Ancient Sparta. The Spartans used what was called the "Scytale," a long and narrow strip of parchment that was wound around a staff. The message was written down the length of the staff, then unwound and sent to the receiver. The message could be read only if wrapped about a staff of the same thickness. Any other diameter would result in a jumble of letters.
II THE JULIUS CAESAR CIPHER -- Substitution algorithms
The most common reference to encryption in ancient times, however, was with Julius Caesar, who shifted the alphabet by three, so that A became D, B became E, and so on. This type of alphabet shifting or substitution is common today in the "cryptograms" and "cryptopuzzles" found in the daily paper. It can be broken by elementary school children. Methods for encryption became more and more complicated as time passed. Algorithms and keys were developed and became so complicated that they had to be run by machines, like the Enigma machine in World War II Germany. The algorithms, that is, the mechanics of how the encryption was done, were always kept secret, and were always the targets for interested third parties. When the British captured one of the Enigma machines, they were able to read everything the Germans encrypted and sent.
To give an idea of how all this works so far, we'll encrypt the phrase "NEITHER A BORROWER NOR A LENDER BE" from Hamlet. If we were to use a simple substitution algorithm like the Caesar Cipher, our algorithm would look like this:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
D E F G H I J K L M N O P Q R S T U V W X Y Z A B C
and the phrase would then read:
QHLWKHU D ERUURZHU QRU D OHQGHU EH
Our phrase is not in what we might consider a standard written English and would therefore be harder to break than a common sentence, but even so, there are two characteristics about it that a cryptanalyst could and would exploit. One is obvious, the single letter standing by itself. Only two letters do that, the A and the I. The other is the double letter in the third word. If the interested third party knew that our algorithm was a simple alphabet shift, they would only need to try twice, shifting the alphabet three times one way (as we did) so that D becomes A, or shifting it five times the other way so that D becomes I. Had our algorithm been a true substitution cipher, our cryptanalyst would then have begun working on the double letter, because only some of the letters can be doubled in English. Eventually, after some tedious work, the message would be broken. The longer the message, the more clues are available, and the easier it is to break.
However, suppose we used a more complicated algorithm, one we called "multiple alphabet shift." Our algorithm might look like this:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
P Q R S T U V W X Y Z A B C D E F G H I J K L M N O
R S T U V W X Y Z A B C D E F G H I J K L M N O P Q
I J K L M N O P Q R S T U V W X Y Z A B C D F F G H
V W X Y Z A B C D E F G H I J K L M N O P O R S T U
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
T U V W X Y Z A B C D E F G H I J K L M N O P Q R S
E F G H I J K L M N O P Q R S T U V W X Y Z A B C D
L M N O P Q R S T U V W X Y Z A B C D E F G H I J K
I J K L M N O P O R S T U V W X Y Z A B C D E F G H
N O P O R S T U V W X Y Z A B C D E F G H I J K L M
E F G H I J K L M N O P O R S T U V W X Y Z A B C D
We work our algorithm by finding the first letter we want to encrypt, the N, and dropping to the first shifted alphabet to get C, the second letter, E, drops to the second shifted alphabet, and we get a V. The third letter goes to the third alphabet, and so one until we reach the bottom, then we start over. Our phase now becomes:
CVOOHXV L JBVGFEZR GSC I YICUMM BX
That is the message we will be sending. The party with which we are communicating will have to know two things, the algorithm, "multiple alphabet shift," and the key. In this case we have a key length of eleven, and you've probably already noticed by reading down the left side of the algorithm that our key is "private line." We could have made it even more difficult by making our key something like "private line + 5" or "private line - 2" and buried the key somewhere in the middle.
Although the message now seems as unreadable as the first time, our cryptanalyst friend has lost a number of their clues. For example, the single letter words are saying nothing. Our double letters are buried and false doubles have been introduced. The cryptanalyst will now have to somehow get a hold of the key, or try a brute force attack and try every possible key.
III WORLD WAR TWO -- Cryptography becomes science
By the time the world was slugging it out in the 1940s, Cryptography had reached the level of a science. By then, there were elaborate electromechanical means to do encryption even more complicated than what has been described above. Consider for a moment Germany's "enigma" machine which the Allies were able to break only because they had a captured Enigma machine of their own, which Churchill called his "ultra secret."
By then, what is considered the only unbreakable algorithm (even by today's standards) had been developed. It was called the "one time pad." Each character in a one time pad is randomly generated--tens of thousands of characters spanning hundreds of pages. Only two copies of the pad are made. These copies are shared between the two communicating parties. One will encrypt the message using the first page of the pad and the receiver will decrypt it using the same page. Then both parties tear the page off and destroy it. It's a great scheme, but the logistical nightmare behind it is obvious. It's difficult to generate random numbers, especially in the quantities needed. Then there is the problem of trusted couriers securely getting the pad to the other party--handcuffed attache cases, locked safes, trusted guards--real cloak and dagger stuff. Affordable only by governments who feel they need to do that kind of spook stuff.
Even as late as the 1970s, military comm centers had the punch card version of one time pads to synch up the communications equipment. Every morning at "oh six hundred zulu" the comm center operators would destroy the previous day's card and tear a new one from the pad.
(Editor's note: Dayglo points out that many countries still use a one time pad scheme to pass embassy, military or intelligence traffic over shortwave to field operatives around the world. Information on "numbers stations" occurs occasionally in both _Monitoring Times_ and _Popular Communications_.)
IV. THE DOWNSIDE -- Problems with shared keys
Let's return now to our strongbox analogy. What has been described so far is what's known as Shared Key Cryptography. Even the algorithm based on DES, the Data Encryption Standard, requires the sharing of keys. By analogy, if you have something you want to send in a strongbox, you have to share the key with the other party. You either send the key with the strongbox (not a good idea--if someone intercepts the box they also get the key), send the key separate from the strongbox (again, not good-- if they can intercept the strongbox they can intercept the key), or you can meet the other party before hand and give them a duplicate of the key, which is precisely how it's done, both with real strongboxes and in Shared Key Cryptography. The box (algorithm) remains the same, and whatever one person locks, the other can unlock.
There are, of course, problems. What if the parties cannot meet ahead of time? What if they have never met and have no way of knowing if the person they are now giving the key to is the real person with whom they will later be communicating? What if you need to communicate the same message with more than one person? Do you all share duplicate keys? That's bad security-- it doesn't allow communication that cannot be read by other key holders. But then, if you have a different key for every two people, the number of keys begins to grow exponentially. You only need one key for two people, but ten people would need 45 keys. Add an eleventh person and you suddenly need 10 more keys. When it comes to cryptology, it seems that people don't make truly random keys. If a key becomes compromised, then the "Time Machine Effect" becomes active: not only are present communications compromised, but everything that is sent in the future will be compromised, and everything that has been sent in the past becomes compromised.
V. A NEW DAWN: Public Key Cryptography
Luckily, everything mentioned until now is "stone age." Modern cryptography began in 1976 when Whitfield Diffie and Martin Hellman first described Public Key Cryptography. Since then, there has been an explosion in cryptography, especially aided by the continuing speed and development of the computer. Since then, randomization of keys became feasible, digital signature became possible, and perhaps most importantly, encryption was no longer the exclusive domain of the National Security Agency. Since then, acronyms and jargon like DES, IDEA, PGP, RSA, Blowfish, Public Key, Private Key, Key Escrow, and the like have been in the media.
The concept of public key cryptography is deceptively simple. The first time you hear it, you understand it; then five minutes later you've lost it. The standard explanations like "with public key cryptography, two keys are generated, a public key and a private key; the private key the individual keeps to himself, and the public key is shared with everyone" doesn't really convey the power behind this technology. What we are going to do is a step by step walk through the encryption and decryption process and conceptually examine what happens at each step.
VI CONCEPTS -- Understanding basic public key ideas
Before we begin the process, we are going to have to lay some ground work. The first thing to realize is that a modern encryption package will "do it all." The user has to do nothing much more than hit the "encrypt and send" button, and the receiver has to do not much more than hit the "decrypt and verify" button. So as you read, please don't get bogged down with the feeling that encryption is only for mathematicians and spooks. Anyone can do it.
Modern encryption packages, in addition to a friendly user interface, contain four major parts or functional components. One is an encryption engine (DES, IDEA, Triple-DES, Blowfish, RC4, etc.). One is a public key generator (RSA, ElGamal, Diffie Hellman, etc.). One is a digital signature algorithm (RSA, DSA, etc.) And one is a one-way hash function (MD5, SHA, Luby Rackoff, etc.).
The first thing we'll begin with is an understanding of public keys. Think back again to our strongbox analogy. Shared public key cryptography could be compared to making duplicate keys and sharing them with others. With public key cryptography, two keys are generated. One key is for locking and one is for unlocking. That is perhaps the most important concept in public key cryptography, so I'm going to repeat it. You have two keys, both different, say a red one and a blue one, and one strongbox. If you lock the strongbox with the red one, ONLY the blue one can unlock it. The red one cannot unlock what it has just locked. If you lock it with the blue one, only the red one can unlock it; the blue one cannot. Neither can the green one or the yellow one or the purple one. You keep a copy of your red key safe and hidden, and place your blue one out where anybody can get it and make duplicates. If they want to send you something, they take the strongbox and a copy of your blue key, lock it, and send it to you. Only the red key can unlock it, and you have the only copy. When you want to send something secured to someone else, you get a copy of their "blue key" and lock the box with it. You will not be able to unlock it with the blue key, and neither will anyone else who has a copy of that blue key. Only that other person's "red key" will be able to unlock it.
That's what happens electronically with encryption keys. The two keys that are generated are unique. You keep the private one, your "red key," safe and secure, and put your other one out on a public key server. It's published, much the same as a phone number. If anyone wants to call you on the phone, they look your number up in the phone book. If anyone wants to send you something encrypted, they look your public key up in a key server.
A. (Editor's note: Is your brain shutting down yet? It's difficult to grasp this key concept since it fights against our experience of what a key does. An ordinary key locks and unlocks something: a car door, a gym locker, or a finely made gun case. Strongbox keys, though, are specially made, in that they may lock but not unlock. Two keys, therefore, are needed to operate them. Let me beat this into you further with an example:
Let's imagine a stagecoach rolling along to pickup a payroll. The strongbox lid rattles slightly since it isn't locked yet. The guard picks up the money, throws it into the box and locks it up with his key. This key will not open the box any longer, only a different key will back at the bank. In a similar vein, you can leave your public encryption key out for all to use, much as a bank could leave dozens of locking strongbox keys around. Anyone may use your key to lock up a message but only you, back at Hacker's Bank, can unlock the goods with your unlocking key.
Similarly, an e-mail message or other box becomes a lockable device. The process of creating and sending an encrypted document, in effect, builds a strong box made of data. It can be more secure than any box made of steel or oak. And once someone locks in a message only you can open that door. But let's get back to Rich's article.)
STEPPING THROUGH ENCRYPTION -- The process
Now let's begin the process. We are going to look at one of the most complicated scenarios--digitally signing and encrypting a message, then decrypting and verifying the signature at the far end. Even though complicated, it's still quite understandable, and any other scenarios will be a piece of cake. We have a Sender, let's say a young man who's in love, and we have a Receiver, a young lady who is the object of his affections and is halfway around the world on the Internet, with lots of interesting places in between where a message could be compromised. We'll assume for the moment that neither have the spiffy interface and have to do everything manually so we can see what happens at each step.
Step 1. The Sender has a message that he wants to send confidentially to Receiver.
Step 2. The Sender generates a one-way hash of the message. This "hash" is really a type of digital fingerprint that is unique to that message. Change a comma to a period, and the fingerprint would be different. It can be compared to the pseudoscience of numerology, where you take the person's name, King Lear, say, and boil it down to a single number, nine perhaps, and then try to figure out the person's future. Change the name to King Leer, and you end up with a different number. And it's one-way, which means you can't take the number nine and from it extrapolate "King Lear" any more than you can extrapolate a data packet from its CRC.
Step 3. The Sender "signs" the fingerprint by using a digital signature algorithm and his private key.
Step 4. The Sender concatenates the "signature" to the plaintext message.
PAUSE FOR DISCUSSION
At this point, many people stop and send their message. Why? Because the contents are not sensitive and may be read by anyone, the critical portion being that the reader may want to verify who it came from. Remember, what one key locks, only its pair can unlock. So if something is encrypted with a private key, only the corresponding public key can unlock it, and everybody has access to the public key, so everyone can verify that only one person locked it.
END PAUSE
Step 5. The Sender generates a one-time random key. This is sort of an electronic equivalent of a one-time pad. It's also called a session key, and this is the key that all the hullabaloo is about with the US export hassles.
Step 6. The Sender uses this one-time key to encrypt the "signed message" from Step 4. This key is NOT part of a public key private key pair; it both encrypts and decrypts (locks and unlocks) the message. Note that this one-time key is still in the clear at this point.
Step 7. The Sender gets the Receiver's public key from a key server, or perhaps in this case, from the Receiver herself.
Step 8. The Sender then encrypts the session key using the Receiver's public key and the public key algorithm. Yes, it is feasible to bypass the session key generation and encrypt the entire signed message using a public key algorithm--but it's not normally done. RSA, for example, is slow, around 6000 times slower than the other encryption engines. So the public key algorithms are normally used for encrypting the keys only, leaving the bulk of the message to be encrypted by the faster engines.
Step 9. The Sender concatenates (joins -- puts together) the encrypted key to the encrypted message.
Step 10. The Sender then uses e-mail to send the encrypted message to the Receiver.
PAUSE FOR DISCUSSION
At this point the message is out where anybody can get to it. The addressees and routing information is in the clear for anyone to read. And they can separate the session key from the encrypted message, but what good would it do? The message has been encrypted by the session key and can only be decrypted by it. The session key has been encrypted by the a public key and only its corresponding private key can decrypt it.
It is against the encrypted session keys that all the attacks are directed, which is why the key length is so critical. The only feasible way of breaking them is through brute force-- trying every possible combination until the right one is found. With a short key length, considering the computing power we have today, brute force is a snap. Any key length of 40-bits or less is okay for export according to the US government. Any why not? They can break it in .2 seconds (assuming $1,000,000 in hardware). You can export up to 64-bits IF it's to an overseas division of the same company and IF you give the government a copy of the key. PGP, by comparison, uses the 128-bit IDEA algorithm.
Ah, but there's a paradigm that computing power doubles per price every 18 months. At that rate, a 64-bit key, which takes 38 days to break today, will only take an hour to break by the year 2010. PGP, using today's computers, will take 1018 years. By 2010, 1015 years, and by the year 2030, will still take 10 years. These figures are all taken from Schneier's book.
Whether the US government's export rules make sense or not shouldn't really be a part of this discussion, but I can't help myself. Everyone, from anarchists to corporate types disagree with the government. The government, on the other hand, wants to be able to read anything encrypted that leaves the country so they can spot illegal activities. I can't imagine a drug cartel, for example, using only government approved software. It's legal to use encryption of any strength within the US (and Canada). It's legal to buy and use encryption of any strength that was developed somewhere else in the world (IDEA was developed in Switzerland). It's legal to use that software to communicate with someone in another country who also bought it legally outside the US. But it's not legal to take or send it out once you get it in the US, and it's not legal to develop something here and take it out. At that point it's classified as a munition and falls under the same category as a weapon. Does that make sense? You decide.
Anyway, to get back on the subject, the encrypted message is out for anybody to examine, but the only thing that they could tell is that the Sender sent an encrypted message to the Receiver, and if they used PGP, they won't be reading it until about the year 2080.
END PAUSE
Step 11. The Receiver receives the message, trashes the header and trailer information, then separates the encrypted session key from the encrypted message.
Step 12. Using the same public key algorithm and using her own private key, the Receiver decrypts the session key. Remember, the public key locked it, only the private key can unlock it.
Step 13. Using the same encryption engine as the Sender and the now decrypted session key, the Receiver decrypts the signed message. The session key is discarded, never to be used again. The message can now be read.
Step 14. To verify the authenticity of the Sender, the following substeps will be taken:
Step A. The Receiver separates the message from the "signature." Step B. The Receiver generates her own one-way hash of the message. Step C. Using the Sender's public key which she was able to get either off a server or directly, the Receiver decrypts the encrypted hash she received. Step D. The Receiver compares the two hashes. If they are the same, the message is authentic. If not, she knows someone else is trying to spoof her, and throws the message away.
CONCLUSION
Remember, all those steps are transparent to the user. All those little discrete steps are done behind the scenes and require little more than button pushing. A short note takes less than a second to encrypt and send, and less than a second to decrypt. A large file might take several seconds to several minutes .
Despite the thousands of years that encryption has been around, it's really still in its infancy. There are two main issues we'll be facing in the future as far as encryption is concern. The first is the aforementioned government restrictions. Hopefully, when some common sense gets into the bureaucracy, that will become a non- issue.
The second will take time. Think about telephones for a moment. You can pick up the phone and call anyone in the world. It doesn't matter what make or manufacturer made the two phones, you will be able to speak to each other. You can even understand each other if one of you happens to know the other's language. It seems silly to think that if one person owns a Western Electric phone they would not be able to talk to someone who owned a phone purchase at the AT&T phone store.
That's how it is with encryption, however. There are no standards. Someone using PGP cannot communicate with someone using, say, Motorola's Signet or Nortel's Entrust, but only other PGP users. Perhaps in the future, we'll be buying one encryption product over another because we like the key management better, or the GUI better, or the price better, but the different products can still work together.
Excellent, free file on encryption by John E. Canavan from his Fundamentals of Network Security. This complements Rich Adams' article below (24 pages, 211K in .pdf)
Ordering information for the title above (external link to Amazon)
NEXT PAGE -->
