***************************************************************************** ***** DRAFT 0.51 - SANITY CHECK AND PROOF READ ONLY. NOT FOR RELEASE. ***** ***************************************************************************** Encryption, a simple guide. ---------------------------------------------------------------------------- This document is copyright Michael Lawrie, 1998. It may be used and distributed freely, provided it is not changed in any way. The author accepts no responsibility for anything at all, ever. This is a draft copy - Version 0.51 19980611 Very slight updates - Version 0.90 20001026 ---------------------------------------------------------------------------- -- Introduction: This document was written for users of our systems to understand how encryption and keys work, and how to use them safely, and properly. I have made the document as generic as possible, and included some background information so that it can be used elsewhere. It is not an overly technical document because it is not aimed at technical people. Some of the examples may well contain what looks to be glaring inaccuracies but remember, this document aims to put across the concepts of encryption rather than to provide mathematically sound ideas. Some artistic licence has been used in the really technical parts to make life a bit more simple. Since computer security seems to have become popular since 1997, when a lot of this was written, a lot of new products have come onto the market. Any products mentioned in this document can probably be assumed to be old versions or even obsolete technologies by the time you read this. Saying that, the concepts haven't changed, so this document can still be considered to be valid for now. -- Related documents: The document "One time passwords, a simple guide" addresses some of the issues mentioned in this text in more detail. -- Types of encryption: -- Simple encryption: Firstly, you need to work out what sort of encryption you want to use. The simplest form of encryption is just to use a known algorithm to jiggle around with the contents of the file to produce something that can be reversed (decrypted). In really simple terms, assume that you have a text document and replaced every "A" with a "B", every "B" with a "C" and so on, until you get to "Z" which you then replace with an "A". A file containing: HELLO THERE, I AM AN ONION. Would become: IFMMP UIFSF, J BN BO POJPO. This is a very simply encryption but it fits a lot of the criteria for simple protection. At first glance, the text appears to be gibberish, it doesn't take much computer power to encrypt and decrypt the document and someone glancing at the file wouldn't be able to make much sense out of it; but... If someone were to steal the document from you, it wouldn't take them too long to break this code. A lot of people will pour scorn on simple encryptions like this but, they have been used for a couple of thousand years by such people as Ceasar and Leonardo Da Vinci and they offer quite good protection against the casual browser. The main benefit is that they don't use much resource to decode but besides that in these dase of massive computing power, they are really worth very little in terms of security. -- Password based encryption. The next 'level' of encryption relies on you providing a password to "seed" the encryption. We have gone beyond treating a file as a file of letters now, and we view it more as a computer would, in a numeric form. Let's look at the previous bit of text: HELLO THERE, I AM AN ONION. Most computers store letters in something called ASCII which gives every character a numeric code between 0 and 127. Our bit of text in ASCII is actually: HELLO 72 69 76 76 79 32 THERE 84 72 69 82 69 44 32 I 73 32 AM 65 77 32 AN 65 78 32 ONION 79 78 73 79 78 46 So, this is now: 72 69 76 76 79 32 84 72 69 82 69 44 32 73 32 65 77 32 65 78 32 79 78 73 79 78 46 This method of encryption involves you giving a password, so let us assume the password you give is "HELLO". The aim is to encrypt the file so that if you give the same password to decrypt it and this process is reversed it produces the original file. If you give a different password, it should produce gibberish. The computer will now fiddle with this password somehow to produce a method of encryption so, let's make up a really simple one to show how it works. 1) We'll get the password, and convert the letters to their ASCII form. HELLO = 72 69 76 76 79 2) We'll add all the numbers up. 72 + 69 + 76 + 76 + 79 = 372 3) We'll take the first and the last digit of the result to give us a two digit number so with 3, 7 and 2 we get 32 - This number is called a 'hash' (a number created from a password) and we will be using this 'hash' to 'seed' a mathematical function later... Most encryption formulas are written by bearded hippies so no guesses for working out where some of these terms came from! 4) We will add the seed to every the ascii code of every letter to give us a set of new numbers, which will be the final, encrypted file. So, taking a section of our unencrypted file (HELLO THERE): 72 69 76 76 79 32 84 72 69 82 69 And adding 32 to every letter, it becomes: 104 101 108 108 111 64 116 104 101 114 101 This of course is quite easy to crack still because all you have done is to add a constant amount to each digit. In actuality, the "seed" would probably be fed into a mathematical function that generated a new number each time, and that number would be used as the new seed. For instace, if the function was: seed = seed + 5 And each time a "letter" was encrypted, a new seed was calculated then the following would happen with the phrase "HELLO THERE" H = 72 seed = 32 new value = 104 E = 69 seed = 37 new value = 106 L = 76 seed = 42 new value = 118 L = 76 seed = 47 new value = 123 O = 79 seed = 52 new value = 131 = 32 seed = 57 new value = 90 T = 84 seed = 62 new value = 146 H = 72 seed = 67 new value = 139 E = 69 seed = 72 new value = 141 R = 82 seed = 77 new value = 159 E = 69 seed = 82 new value = 151 As you can see, this newly encrypted representation of HELLO THERE is not as easy to see a pattern in (for example, you can't see the repeated L's in HELLO) and thus harded to decrypt without some knowledge of the methods used to do the actual encryption. This example is horribly simplistic, in actual fact both the initial hash and the seed calculation formulas are usually horribly complex. It is important that the hash produced is actually a lot larger than the one we used so that not many passwords produce the same number. It is worth mentioning as an aside, that a lot of operating systems store their passwords as a "hash" and not as the actual password. Although these passwords are often said to be encrypted technically they aren't as they can't ever be decrypted. When a password is first set for a user, a hash of this password is made and stored in a password file. When the user logs in again, the password typed is hashed again and compared against the hashed password stored. This means that there is no record of the real password stored anywhere and even if someone has the hash of the password it should be nigh on impossible to reverse it to get the real password (although it may be possible to calculate another set of letters that will hash to the same thing that could be used as a password). On some operating systems, for example, Unix, the "hash" is simply made up of the password provided. "hello" will hash to "SI50OC4u.jlPc" whatever the username. Other operating systems, for example, VMS include the username with the hash so the password "hello" will hash as different values depending on the username, for example: User: BEUB1 Password: HELLO Hash: DEF0CDAB 0BD79CCE 0607 02 User: BEUB2 Password: HELLO Hash: 50A6F50B CDCE1EA1 0607 02 In some situations you could go to extremes and hash the month, or the year in with the username and password, this would mean that passwords were only valid for a certain amount of time. -- Keys The problem with passwords is that people put rather too much trust in them and really, they are not very good at what they do. Imagine some of the following scenarios. . People usually chose easy to remember passwords. The password "hello" is far easier to remember than "u23hv2348hd20dh02lknjdb2". Most people think that their password is very difficult to guess but most people find (to their cost) that they are wrong. As a mostly irrelevant but personal aside here, it is commonly known that you shouldn't use the name of a favourite pet as a password; what is less commonly remembered is that you shouldn't name one of your pets after a favourite password. . Some hash functions don't even allow a password to be very long, for instance, Unix only takes notice of up to 8 characters. The passwords "hellothere" and "hellotherefred" are treated as the same. This is not always commonly known. . Brute force can be used to guess a password if the hash is known. A common method of breaking someone's password is to hash every word in a dictionary and compare it with the hashed password. Various combinations of numbers and letters (for example, birthdates and car number plates) can also be tried. Fast password "guessers" can try 20,000 passwords a second so the majority of passwords can be cracked in a matter of a few minutes. . Your password may be "snooped" as you are entering it. This can range in complexity from someone looking over your shoulder and watching what you type (think of Cash-Machines), people monitoring the network connection as the password you type is sent over a network (this is a far more common occurence than people think!) all the way to the hi-tec world of people remotely monitoring the radiation coming from your computer monitor, the sound of your keys as you type a password and other such strange things! One way around this is to use various one time password methods such as DES one time keys, Secureid or S/KEY (these are explained in another report, "One time passwords, a simple guide". The favourite way these days is to use a "key" which really is nothing more than a very big password. The thing about keys as opposed to passwords is that they are not designed for humans to use directly and really need to be "carried around" by some physical means. The easiest way to explain the differences between a password and a key is to look at the differences between a combination lock and a physical lock. A combination lock is convenient because you can open it at any time (as can other people who know the combination) but modern key-locks are far more secure having the disadvantage that you need to be physically carrying a key to get into it. Technically speaking, a key is simply a very big combination (you can describe keys in terms of a long set of measurements, angles and 'cutouts') but it is a very complicated and not very easy to replicate. An intruder can open a combination lock if they have access to the lock and know the combination; they can only open the key-lock if they have access to the keyhole and have the original or an exact copy of the key. Simply speaking, a computer based encryption key is a file containing a very big password. When you want to do something that requires a password to be entered (eg: encryption) this key is used instead of you actually typing a password in. These keys are now starting to be used more and more for authentication, replacing the simple password you would normally use to validate yourself to remote systems. This key is very valuable and needs to be kept safe. If someone copies it then they can simply use it in the same way that you do; for this reason most keys are actually stored encrypted and require a password to unlock them for use. Think of this as keeping your key in a safe that is protected by a combination lock, and you only remove your key very occasionally. Ideally, this encrypted keyfile (your safe) should be kept in a secure location and you should do your best to avoid people seeing the password you use to unlock it. Remember, you are protecting two things now, the key file and the password you use to unlock the key file. In computing terms this means you should bear in mind the following: Physically protect your private key file: It is possible to use brute force techniques to unlock it, in the same way that it would be possible to guess the combination lock to a safe. Do not store your key on a disk that is accessable from a network, do not leave your key on a computer that people may have physical access to (it takes only seconds to copy someone's key to a floppy disk or to email it to someone) and try to make sure that the key is never transmitted over an insecure network. Really security minded people keep their key file on a floppy disk that they carry around with them when they need it and keep in a secure place when not using it. Remember that if your key is stolen, the password is the only thing protecting it so chose a good one. Most keys want a long pass phrase instead of just a password to protect them, the more unguessable this is (lists of unconnected words and characters are good) the safer your key will be if it is stolen. Just remember, it is usually far easier to steal your key and then try and guess the password to the key than it is to try and 'forge' your key. There is a good document on selecting good key passwords at: http://www.stack.nl/~galactus/remailers/passphrase-faq.html All of this is especially important if a key is being used to give you access to other resources (for example, an ssh key). By its nature a key of this type often sits on a network and often gets transmitted across networks. The password to keys of this sort must be very good since anyone breaking it potentially has access to every machine your key unlocks. -- Public keys. A public key is a key file that goes along with your private key file. In simple terms, it is a 'padlock' that your private key can unlock. The public key can be freely sent out to people and they can then use it to secure things in a way that only you can unlock. In the real, physical world, it would be quite easy for someone to open up your publically available padlock and "reverse engineer" a key from it. In the computing world, the mathematics behind generating the public and private keys is so hideously complicated that it in all practical terms it is currently impossible to reverse engineer a key. Saying this, computing power advances so fast that older 'small' keys are starting to be condidered potentially insecure, and much larger keys are now starting to be used as standard; what was once described as a "military strength" key is now considered to be a very basic key. The world's governments don't really like people having access to encryption like this and there are various laws coming into play to stop it being used. We'll look at that in more detail later on. Typical applications of public and private keys are: . A person could send you a file encrypted with your public key (locked with your padlock) that only your private key can unlock. . A person can secure a remote computer account with your public key instead of a traditional password so that you can use your private key to login to the account. Your private key is never actually sent to the remote computer, instead it is used to generate a one time password to be sent. . A file, or message can be 'digitally signed' using your private key, and a recipient can use your public key to verify that the digital signature is really yours. In simplistic terms, the contents of the document, and your private key are turned into a hashed and then this is sent along as the signature. If the contents of the document are altered by anyone the signature will not be valid. -- Guarding your passphrase. The importance of guarding your private key files cannot be overemphasised but they are encrypted using a pass phrase for a reason. If your private key file is stolen, the pass phrase will still protect it so you must make sure it is not known by anyone. If you can't be bothered to read the passphrase FAQ mentioned earlier, bear in mind the following tips on choosing a good one. . Don't use a single word, a well known phrase or anything connected with you that people may guess. . Don't assume that people won't guess it. . Spell things incorrectly, use punctuation, swap words around and use random letters or words in the phrase. . Read the passphrase FAQ anyway - It is at: http://www.stack.nl/~galactus/remailers/passphrase-faq.html When you have the good pass phrase, make sure you are not watched when you type it. Bear in mind the following points. . Don't type your pass phrase over a network, someone may be snooping your connection. . If you are using a 'public' computer, bear in mind that the passphrase you type may still be hanging around in the machines memory and that may be viewable by other people. Even if you are using a secure link into a machine, and then entering a passphrase to go onto another machine (something a lot of people do all the time) are you sure the password you typed is not still in the machine's memory. . If you are typing your passphrase into a remote machine, over a secure encrypted link, are you sure that session hasn't been snooped and is in the process of being forcibly 'decrypted'? . Don't use the same passphrase on all of your keys, especially ones on remote machines that you may one day have to type over a network. . Ideally, only ever type your passphrase into a local machine that you have sole control over. . Although it is possible to change the pass phrase on a key, if someone has an old copy of the key and knows the old passphrase, they can still use that key. Read that last sentence again, because it is very important that you remember. If you know someone has an old key and suspect they may know the passphrase (an ex-employee, an ex-partner, your best friend..) then revoke the whole key. Stop using it and generate a new one (mind you, keep a backup copy of the old key just in case you have things encrypted with it). In companies that use shared keys to generate digital signatures, this is incredibly important since an employee leaving the company can take a copy of the key and use the passphrase they know to sign things as you. -- Trusting keys. If you want to send a confidential file to someone encrypted with their public key then you need to be sure that the key you have is really theirs. This introduces the complicated world of key verification. Most public keys have a 'key id' and a 'key fingerprint'. A key-id is just a reference so that a key can be retreived from a public database and a key-fingerprint is a hash made from the key that is pretty much certain to be unique. The easiest way of getting someone's key is for them to give you it on something like a floppy disk. When you have this key in your posession you should talk to them, physically, and verify that the key fingerprint you can see on the key matches when they think the fingerprint should be. Once you know that this key is really theirs, you can keep it in a safe place for later use. This works well in an ideal world but, realistically, it isn't always possible to do this. There are a few ideas in current practice that try and work out ways around this. We'll look at a few here. -- Key escrow. [ MJL: Check that this does actually apply to public keys too! ] The word "escrow" basically means that something is kept in safe storage by a third party that everyone trusts. What key escrow means is that keys are held safely and securely by someone that everyone trusts. When you need someone's key, you ask the third party for it and they deliver it together with a fingerprint that you could if you like, check independently. Key escrow is actually wider reaching than this. Trusted third partys can also hold private keys and passphrases. If you accidentally lose your private key, you could get it back from the third party; if you die and your estate for some reason needs the key, they too could apply for it. Key escrow relies on you having a great deal of trust in the third party. Since noone these days trusts anyone; escrow doesn't work very well. -- Chain of trust. Let's assume that your friend Fred gives you his public key. You verify the fingerprint with him, and you are completely sure that the key really does belong to Fred. You are now in a position to give out Fred's key to other people. In fact, what you could do is to 'digitally sign' Fred's key with your own key, to say that you are 100% sure that this really is Fred's key. Whilst you are at it, you may as well give Fred your public key, and ask him to digitally sign yours. Now let's assume that you have a friend called Bill. Bill has your public key but now he wants Fred's key as well. If he were to aquire (maybe from a WWW site or a special key-server) a copy of Fred's key and saw it was signed by you with a verifiable digital signature, Bill could be pretty certain that this really was Fred's key. He could go further, and sign that key with his own key to say he was sure that it was really Fred's key as well but really, to be correct about this whole thing, he should personally verify the fingerprint with Fred before doing so since if he didn't he would be completely relying on your word that this was really Fred. Eventually, if people are good about signing keys, it is quite possible that you may pick up a key for someone that you don't know that has been signed by someone you do know. If not, then one of the people who has signed the unknown key may themselves have been signed by someone you know. In this way, a trust relationship builds up. A lot of 'high level' keys are signed by hundreds of people and there is even a printed paper book of their keys and fingerprints (the theory being that this cannot be electronically altered). If these people are willing to sign other peoples keys, after properly verifying them then this strengthens the trust enormously. It is a rather nice, semi-anarchistic solution to disposing of a single trusted third party and is the mechanism used in by the "PGP" community (of which, more later) to very good effect. -- Legal issues: It is fair to say that governments don't like the public having access to this sort of encryption. Governments like to know what people are doing and they employ a very expensive police and intelligence service who are meant to watch what is happening, and take action where necessary. The monitoring of private communications between suspected criminals is a very important tool and if these communications are encrypted then this will severely hamper them. In the past encryption has been used but governments have been very good at breaking it (for instance, in World War Two, most messages from the Germans were read by the allied forces despite the fact they were encrypted) because it was never really very "strong". Governments always had more powerful computers that the people and so were satisfied that they were one step ahead. This is no longer the case, and is starting to look like things may get out of control. Rather than go into huge ethical discussions it's easier to look at a few points, and examples. . The French have 'solved' this problem by disallowing encryption that they can't break from going over their networks. . The Americans, convinced that they have the best encryption in the world have decided to make it illegal to export the software to do it by electronic means. . The British propose to make key escrow mandatory. Encryption is fine as long as the keys used to do it are all lodged with a trusted third party so that if needs be, government and police agencies can read it. . Using Public/Private key systems such as PGP (See later) it is possible to send a mail that you yourself could not possibly decrypt, and by doing so, implicate yourself. This may be useful for some people to remember especially in light of the UK RIP laws. By the same note, a vital mail message you send may be impossible to recover unless you have kept a clear text copy or also encrypted it to your own key. Reading this, it would seem obvious to most people that criminals and spies aren't usually law abiding people and it is criminals and spies that these laws are aimed at. This makes most sane people think that these measures are all completely pointless but none the less, the world's governments are panicked enough to try and legislate the issue of encryption. It is worth while trying to find out what your local laws on encryption are and, if you are the law abiding type, stick with them. -- Some encryption products. Rather than go through looking at various different products for encryption, it is easier to just take a sample of a few very good ones and explain what they do and how they work. - F-Secure Desktop: [Note: 20001026 - This is now out of date, they appear to have dropped this product. Will update with information on PGPDisk and Network Associate's security solutions] This product is really aimed at the PC user who is paranoid about their computer being stolen and their data being read. It is especially suitable for people with laptops containing confidential data. Each 'user' of the machine has their own private key-file, protected by a passphrase. When the machine starts up, you enter your key name, and your pass phrase and a designated set of files is automatically decrypred. Similarly, when you shut the machine down, you enter your pass phrase and they are encrypted, and the originals are securely wiped. If someone steals your computer or disk, all the important data (assuming you set it to auto-encrypt) will be protected and unreadable provided your pass-phrase isn't guessable. Desktop will also encrypt and decrypt files 'none automatically' and there is an option to security erase files by making sure they are completely wiped from your hard disk. The Desktop site at http://www.datafellows.com/f-secure/desktop/ has a lot more information about the product, and home and educational users can download a free version of it that us supported by some advertising banners. If you are lazy, and you have a laptop with confidential data, this is definately something you should look at. - Secure Shell (SSH) SSH is a product that provides an encrypted "telnet" session between two computers using public/private key technology. It is mainly used on Unix systems although you can get a client for Windows and Macintosh. SSH is also capable of encapsulating other protocols over its encrypted link including X-Windows traffic, making it very attractive for remote access to Unix hosts from desktop machines. SSH has been covered quite well previously in this document, so there is not much more to say about it but SSH does come with a lot of hidden dangers. . Make sure you keep an eye on the list of keys that have access to your remote accounts; it is trivial for someone who has hacked a computer to slip their public key into an authorized keys file and use it. . Try not to give one particular key access to too many machines. If that key is compromised, you are potentially giving someone huge amounts of access. . SSH logging can be very bad. On servers where SSH is allowed to fall back to traditional Unix password methods (useful, because the password is sent over an encrypted link at least) make sure you have all the logging you can turned on to spot people using this as a brute force method of getting entry. A lot of SSH servers fail to log or do much about this. . Never telnet normally into a machine and then SSH out of it if you are unsure of the security of the network. Your passphrase could be being snooped on, potentially compromising every machine you have access to. . Make sure you keep your SSH server software up to date. In the past some versions have had some nasty security holes. SSH is available for Unix at http://www.cs.hut.fi/ssh/ - F-Secure also do a Unix server and clients for PC and Macintosh at their website (Currently: http://www.datafellows.com/f-secure/fclintp.htm). So that this doesn't become an advert for Datafellows, it should be pointed out that the free versions of SSH are excellent and there is no need to buy the Datafellows Unix ones. If you want a client for Windows or Mac, you have to stick with the F-Secure one though, which in many ways is a shame because it has such a terrible user interface. - PGP. PGP stands for Pretty Good Privacy. Originally written by a chap called Philip Zimmermann, it has pretty much become the standard product for encryption on the Internet. It uses public/private key encryption and for most encryption applications does just about anything that anyone would want. There is a good overview at http://www.pgpi.com/overview/ There are essentially two versions of PGP, this is because of the US law on exporting encryption technologies. The International one (PGPi) is the one we will concentrate on. In this, the 'engine' was legally exported from the USA in book form, and then re-entered into a computer outside the US with a scanner, some OCR software and a lot of patience. The people who did this could have done what most other people did and just taken a US copy anyway but they had a point to make. PGP has been around for a long time and has a large following. There are 'plugins' for a lot of software, support for just about all current operating systems (including an excellent Windows interface) and a well established network of public key servers for looking up other people's public keys. PGP is free, works well and most people use it. On the down side, PGP is free, large corporations can't make money out of it and so you won't find much support for it built into commercial software meaning you may have to wait a while for someone to write a plugin, if indeed, it is possible. Some notes on PGP: . The homepage to start at is http://www.pgpi.com/ . Use the latest version, if possible. . Although chosing a big key may seem silly now, you may be keeping this key for years and computing technology will advance massively. . The interface to PGP is meant to be simple but the operation of some of the plugins (for example, Microsoft Outlook Express) can be a bit tricky. It is worthwhile persevering though. 2 years on from writing this original, there have been lots of changes and the intergration with Outlook is neat and quite seamless, adding lots of functions. . When you send out an encrypted mail, make sure you also send it to yourself if you want to be able to read it again in the future. . When you reply to an encrypted mail, make sure you don't send back the contents of the mail in clear text. This is very easy to do by accident. . Don't sign someone's key and allow it to be put back on a keyserver unless you are really sure that the key is valid. . Sign your own public knd export it to a key server. Essentially, doing this means that someone at a later date can't easily upload another key pretending to be you without it looking suspicious. For more information on this, see: http://www.stack.nl/~galactus/remailers/selfsign.html . The PGP documentation makes the comment: It is very important that you read the documentation that comes with PGP before attempting to use the program. If you don't understand the basic principles behind public key cryptography, then you may very well jeopardize both your own and other people's security, and PGP will only give you a false sense of safety. This fact cannot be stressed enough! The links below should provide you with the information needed to avoid most pitfalls. . If you want to send people encrypted mail or to digitally sign things to protect their integrity then there is little option but to use PGP. There are alternatives such as Verisign (much beloved by Microsoft) but they are in their infancy, cost real money and importantly, they are only compatible with certain limited ways of working and certain operating platforms. -- Additional buzzwords. A lot of people who talk about encryption use a lot of words and phrases that they don't properly understand. Like most 'buzzwords', these terms slip into the language without ever really being defined. This brief section tries to give a mostly accurate description of what some of them mean, without overly complicating everything. A lot of these definitions can be found in much greater detail in the excellent Encryption Algorithms and Techniques document at: http://www.rsa.com/rsalabs/newfaq/alg_tech.htm Shared Secrets: A shared secret is used to confirm that when two systems are talking to one another, one of the sessions has not been "hijacked". The essence of a shared secret is that every now and again, each session will validate the other session by saying something that is true of a secret that is shared between them. The other session must then respond with something that is also true about the same secret or it will know that the other side is an imposter. In reality, this is done with hideously complicated maths. Shared secrets are often used during the initial agreement of a key to be used to encrypt a link between them for further use, this key is called a "session key". Zero Knowledge Key Exchange: This is the ability for two systems to exchange session keys without first having agreed upon a shared secret. The maths and underlying logic to this is so complicated that it best to treat the whole thing as magic. There is a good explanation at: http://www.tcm.hut.fi/Opinnot/Tik-110.501/1995/zeroknowledge.html but I very much doubt you will want to read it. ROT13 (the Caesar cypher): This is a very simple cypher often used in Usenet news postings. It is a simple letter substitution where A -> N, B -> O, C -> P etc (when it runs out of letters, it rotates back round to A, hence ROT13 = 'Rotated alphabet with an offset of 13 letters'). It is not used to actually encrypt text, merely to hide it from view so it can't be immediatley read. Some would find it ironic that the cypher Julias Caesar used to win an empire is now mainly used to hide the answers to jokes in news postings. Block Ciphers: A block cipher is an process that encrypts a fixed amount of data. The size of the block is usually measured in 'bits'. To put this in nice simple terms, an ASCII character is made up of about 8 bits so a '64 bit block size' will encrypt blocks of 8 letters as though they are one 'block' of information. Key size: This is quite simply the number of bits in the key. This cannot sensibly be equated to the number of letters because letters are a lot less random than 'bits'. DES: DES stands for the Data Encryption Standard. It was originally written by IBM and in 1977 was taken on by the US Government as an official standard. It is a 64 bit block cipher with a 56 bit key and it is the most well known and widely used encryption system in the world. Triple DES: Take one DES encryption, do it three times and you get Triple DES. It is not quite as simple as this as it usually uses diferent keys on each encryption, and, perversely, one standard (DES-EDE3) does the second "encryption" as a decryption with the wrong key. RSA: The name "RSA" comes from the authors of this system, Ron Rivest, Adi Shamir, and Leonard Adleman. It is a public/private key system invented in 1977. RSA is, to the public-key encryption world what DES is to the block-cipher world. RC2, RC5, IDEA, SAFER, FEAL, Skipjack, Blowfish: These are DES's competition in the block-cipher popularity charts. They all have various merits in terms of safety, speed and block sizes and they seem to have increasingly strange names. Diffe-Hellman: The original concept of public/private key encryption was published in 1976 by Whitfield Diffie and Martin Hellman. Their names pop up all over the place in various situations. MD2, MD4 and MD5: These are all algorithms for creating a digital signature for a message. For the purposes of this document, just assume that MD5 is the only one worth using, although it has now been "broken" as well. HTTPS and SSL: Basically, these are both protocols used by browsers talking to a web server which create an encrypted link between client and server. These protocols are often used when a web site wants you to enter your credit card details or other sensitive information. The company running the web server will then usually store all of this information unencrypted on their servers, but that is a different matter. Distributed cracking: Experts often say that cracking various forms of encryption would take thousands of years of machine time. This is true, but if a thousand machines are all working on the problem at the same time it will only take a year. If 365,000 machines are all working on the same problem, it would take a day. Using distributed techniques, a lot of the modern algorithms are being put under very close scrutiny and problems are being found with some of them. For more information, see the web page at http://www.distributed.net/ . Cryptocard and smartcards: It is possible to store a key on an electronic "credit card". These can either be plugged into a card reader to read the key or, they can have an LCD display. One added bonus of the electronic card is that the key can change according to time based or use based criteria. As long as both the card and the system accepting the key realise this it all works nicely. US Export policy: Generally speaking, the US Government will not allow the electronic export of any cryptographic product with a key size larger than 512 bits. There are some exceptions to this nowadays because even the US government have realised how silly this law is. One time pads: The one time pad is a rather quaint concept often used in military applications although occasionally incredibly useful in the real world. The easiest way of thinking of it is as a pad full of numbered pages each containing a completely random encryption method. There are usually 2 copies of the pad made, one given to the sender, and one to the recipient. When a message is to be sent, the message is encrypted using a random page from this pad, this is sent to the recipient, along with the pad-page used's number, and the recipient uses that to decrypt the message. As soon as the message is encrypted, the senders page is destroyed so that it can never be used again. Simplistic forms of the one time pad are incredibly useful for telling people passwords and the like over the phone. Military applications tend to use single use CD-Roms full of completely random data generated from real-world sources such as atomic decay counters. Digital certificates: A digital certificate is a way of validating that the holder of the certificate is really who or what they say they are. These are often used on the World Wide Web with server certificates to verify that the server being talked to really is the server it should be and personal certificates to tell the server that you are really who you say you are. The most widely available personal certificates (Verisign) do not need a passphrase to unlock them so anyone using the machine can pretend to be the machine's owner unless the key is protected by another product. [MJL] The private key for a Verisign server certificate is held on the server and the public key is held by Verisign. [FINISH THIS CRAP] -- More information. Hopefully, this document has given a simple and understandable overview of most of the issues of encryption. There is a lot more information and reading on the Internet, some already mentioned in this text. This document is not kept up to date like the Web so most of the references are to pages of more links in the hope that they at least will be updated occasionally. . Firstly, this page has a brilliant set of links to most things you will need to know. An excellent starting point. http://www.stack.nl/~galactus/remailers/index-privacy.html . Mentioned at the top of this page, but worth mentioning by itself: http://www.stack.nl/~galactus/remailers/index-pgp.html . The Datafellows homepage: http://www.datafellows.com/ . Verisign's FAQ: http://digitalid.verisign.com/ask_veri.htm . And finally, if you really want to know more, RSA labs have it all... http://www.rsa.com/rsalabs/ http://www.rsa.com/rsalabs/newfaq/