diff options
| author | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-05-22 05:12:18 +0000 |
|---|---|---|
| committer | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-05-22 05:12:18 +0000 |
| commit | aa0f5b38aec14428b4b80e06f90ff781f8bca5f1 (patch) | |
| tree | 95f3d0c8cb0d59d88900dbbd72110d7ab6e15b2a /doc/src/glossary.html | |
| parent | 7c383bc22113b23718be89fe18eeb251942d7356 (diff) | |
| download | vyos-strongswan-aa0f5b38aec14428b4b80e06f90ff781f8bca5f1.tar.gz vyos-strongswan-aa0f5b38aec14428b4b80e06f90ff781f8bca5f1.zip | |
Import initial strongswan 2.7.0 version into SVN.
Diffstat (limited to 'doc/src/glossary.html')
| -rw-r--r-- | doc/src/glossary.html | 2257 |
1 files changed, 2257 insertions, 0 deletions
diff --git a/doc/src/glossary.html b/doc/src/glossary.html new file mode 100644 index 000000000..38d0db7bb --- /dev/null +++ b/doc/src/glossary.html @@ -0,0 +1,2257 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html"> + <title>FreeS/WAN glossary</title> + <meta name="keywords" + content="Linux, IPsec, VPN, security, FreeSWAN, glossary, cryptography"> + <!-- + + Written by Sandy Harris for the Linux FreeS/WAN project + Freely distributable under the GNU General Public License + + More information at www.freeswan.org + Feedback to users@lists.freeswan.org + + CVS information: + RCS ID: $Id: glossary.html,v 1.1 2004/03/15 20:35:24 as Exp $ + Last changed: $Date: 2004/03/15 20:35:24 $ + Revision number: $Revision: 1.1 $ + + CVS revision numbers do not correspond to FreeS/WAN release numbers. + --> +</head> + +<body> +<h1><a name="ourgloss">Glossary for the Linux FreeS/WAN project</a></h1> + +<p>Entries are in alphabetical order. Some entries are only one line or one +paragraph long. Others run to several paragraphs. I have tried to put the +essential information in the first paragraph so you can skip the other +paragraphs if that seems appropriate.</p> +<hr> + +<h2><a name="jump">Jump to a letter in the glossary</a></h2> + +<center> +<big><b><a href="#0">numeric</a> <a href="#A">A</a> <a href="#B">B</a> <a +href="#C">C</a> <a href="#D">D</a> <a href="#E">E</a> <a href="#F">F</a> <a +href="#G">G</a> <a href="#H">H</a> <a href="#I">I</a> <a href="#J">J</a> <a +href="#K">K</a> <a href="#L">L</a> <a href="#M">M</a> <a href="#N">N</a> <a +href="#O">O</a> <a href="#P">P</a> <a href="#Q">Q</a> <a href="#R">R</a> <a +href="#S">S</a> <a href="#T">T</a> <a href="#U">U</a> <a href="#V">V</a> <a +href="#W">W</a> <a href="#X">X</a> <a href="#Y">Y</a> <a +href="#Z">Z</a></b></big></center> +<hr> + +<h2><a name="gloss">Other glossaries</a></h2> + +<p>Other glossaries which overlap this one include:</p> +<ul> + <li>The VPN Consortium's glossary of <a + href="http://www.vpnc.org/terms.html">VPN terms</a>.</li> + <li>glossary portion of the <a + href="http://www.rsa.com/rsalabs/faq/B.html">Cryptography FAQ</a></li> + <li>an extensive crytographic glossary on <a + href="http://www.ciphersbyritter.com/GLOSSARY.HTM">Terry Ritter's</a> + page.</li> + <li>The <a href="#NSA">NSA</a>'s <a + href="http://www.sans.org/newlook/resources/glossary.htm">glossary of + computer security</a> on the <a href="http://www.sans.org">SANS + Institute</a> site.</li> + <li>a small glossary for Internet Security at <a + href="http://www5.zdnet.com/pcmag/pctech/content/special/glossaries/internetsecurity.html"> + PC magazine</a></li> + <li>The <a + href="http://www.visi.com/crypto/inet-crypto/glossary.html">glossary</a> + from Richard Smith's book <a href="#Smith">Internet Cryptography</a></li> +</ul> + +<p>Several Internet glossaries are available as RFCs:</p> +<ul> + <li><a href="http://www.rfc-editor.org/rfc/rfc1208.txt">Glossary of + Networking Terms</a></li> + <li><a href="http://www.rfc-editor.org/rfc/rfc1983.txt">Internet User's + Glossary</a></li> + <li><a href="http://www.rfc-editor.org/rfc/rfc2828.txt">Internet Security + Glossary</a></li> +</ul> + +<p>More general glossary or dictionary information:</p> +<ul> + <li>Free Online Dictionary of Computing (FOLDOC) + <ul> + <li><a href="http://www.nightflight.com/foldoc">North America</a></li> + <li><a + href="http://wombat.doc.ic.ac.uk/foldoc/index.html">Europe</a></li> + <li><a href="http://www.nue.org/foldoc/index.html">Japan</a></li> + </ul> + <p>There are many more mirrors of this dictionary.</p> + </li> + <li>The Jargon File, the definitive resource for hacker slang and folklore + <ul> + <li><a href="http://www.netmeg.net/jargon">North America</a></li> + <li><a href="http://info.wins.uva.nl/~mes/jargon/">Holland</a></li> + <li><a href="http://www.tuxedo.org/~esr/jargon">home page</a></li> + </ul> + <p>There are also many mirrors of this. See the home page for a list.</p> + </li> + <li>A general <a + href="http://www.trinity.edu/~rjensen/245glosf.htm#Navigate"> technology + glossary</a></li> + <li>An <a href="http://www.yourdictionary.com/">online dictionary resource + page</a> with pointers to many dictionaries for many languages</li> + <li>A <a href="http://www.onelook.com/">search engine</a> that accesses + several hundred online dictionaries</li> + <li>O'Reilly <a href="http://www.ora.com/reference/dictionary/">Dictionary + of PC Hardware and Data Communications Terms</a></li> + <li><a href="http://www.FreeSoft.org/CIE/index.htm">Connected</a> Internet + encyclopedia</li> + <li><a href="http://www.whatis.com/">whatis.com</a></li> +</ul> +<hr> + +<h2><a name="definitions">Definitions</a></h2> +<dl> + <dt><a name="0">0</a></dt> + <dt><a name="3DES">3DES (Triple DES)</a></dt> + <dd>Using three <a href="#DES">DES</a> encryptions on a single data + block, with at least two different keys, to get higher security than is + available from a single DES pass. The three-key version of 3DES is the + default encryption algorithm for <a href="#FreeSWAN">Linux + FreeS/WAN</a>. + <p><a href="#IPSEC">IPsec</a> always does 3DES with three different + keys, as required by RFC 2451. For an explanation of the two-key + variant, see <a href="#2key">two key triple DES</a>. Both use an <a + href="#EDE">EDE</a> encrypt-decrypt-encrpyt sequence of operations.</p> + <p>Single <a href="#DES">DES</a> is <a + href="politics.html#desnotsecure">insecure</a>.</p> + <p>Double DES is ineffective. Using two 56-bit keys, one might expect + an attacker to have to do 2<sup>112</sup> work to break it. In fact, + only 2<sup>57</sup> work is required with a <a + href="#meet">meet-in-the-middle attack</a>, though a large amount of + memory is also required. Triple DES is vulnerable to a similar attack, + but that just reduces the work factor from the 2<sup>168</sup> one + might expect to 2<sup>112</sup>. That provides adequate protection + against <a href="#brute">brute force</a> attacks, and no better attack + is known.</p> + <p>3DES can be somewhat slow compared to other ciphers. It requires + three DES encryptions per block. DES was designed for hardware + implementation and includes some operations which are difficult in + software. However, the speed we get is quite acceptable for many uses. + See our <a href="performance.html">performance</a> document for + details.</p> + </dd> + <dt><a name="A">A</a></dt> + <dt><a name="active">Active attack</a></dt> + <dd>An attack in which the attacker does not merely eavesdrop (see <a + href="#passive">passive attack</a>) but takes action to change, delete, + reroute, add, forge or divert data. Perhaps the best-known active + attack is <a href="#middle">man-in-the-middle</a>. In general, <a + href="#authentication">authentication</a> is a useful defense against + active attacks.</dd> + <dt><a name="AES">AES</a></dt> + <dd>The <b>A</b>dvanced <b>E</b>ncryption <b>S</b>tandard -- a new <a + href="#block">block cipher</a> standard to replace <a + href="politics.html#desnotsecure">DES</a> -- developed by <a + href="#NIST">NIST</a>, the US National Institute of Standards and + Technology. DES used 64-bit blocks and a 56-bit key. AES ciphers use a + 128-bit block and 128, 192 or 256-bit keys. The larger block size helps + resist <a href="#birthday">birthday attacks</a> while the large key + size prevents <a href="#brute">brute force attacks</a>. + <p>Fifteen proposals meeting NIST's basic criteria were submitted in + 1998 and subjected to intense discussion and analysis, "round one" + evaluation. In August 1999, NIST narrowed the field to five "round two" + candidates:</p> + <ul> + <li><a href="http://www.research.ibm.com/security/mars.html">Mars</a> + from IBM</li> + <li><a href="http://www.rsa.com/rsalabs/aes/">RC6</a> from RSA</li> + <li><a + href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael/">Rijndael</a> + from two Belgian researchers</li> + <li><a + href="http://www.cl.cam.ac.uk/~rja14/serpent.html">Serpent</a>, a + British-Norwegian-Israeli collaboration</li> + <li><a href="http://www.counterpane.com/twofish.html">Twofish</a> + from the consulting firm <a + href="http://www.counterpane.com">Counterpane</a></li> + </ul> + <p>Three of the five finalists -- Rijndael, Serpent and Twofish -- have + completely open licenses.</p> + <p>In October 2000, NIST announced the winner -- Rijndael.</p> + <p>For more information, see:</p> + <ul> + <li>NIST's <a + href="http://csrc.nist.gov/encryption/aes/aes_home.htm">AES home + page</a></li> + <li>the Block Cipher Lounge <a + href="http://www.ii.uib.no/~larsr/aes.html">AES page</a></li> + <li>Brian Gladman's <a + href="http://fp.gladman.plus.com/cryptography_technology/index.htm">code + and benchmarks</a></li> + <li>Helger Lipmaa's <a + href="http://www.tcs.hut.fi/~helger/aes/">survey of + implementations</a></li> + </ul> + <p>AES will be added to a future release of <a href="#FreeSWAN">Linux + FreeS/WAN</a>. Likely we will add all three of the finalists with good + licenses. User-written <a href="web.html#patch">AES patches</a> are + already available.</p> + <p>Adding AES may also require adding stronger hashes, <a + href="#SHA-256">SHA-256, SHA-384 and SHA-512</a>.</p> + </dd> + <dt><a name="AH">AH</a></dt> + <dd>The <a href="#IPSEC">IPsec</a> <b>A</b>uthentication <b>H</b>eader, + added after the IP header. For details, see our <a + href="ipsec.html#AH.ipsec">IPsec</a> document and/or RFC 2402.</dd> + <dt><a name="alicebob">Alice and Bob</a></dt> + <dd>A and B, the standard example users in writing on cryptography and + coding theory. Carol and Dave join them for protocols which require + more players. + <p>Bruce Schneier extends these with many others such as Eve the + Eavesdropper and Victor the Verifier. His extensions seem to be in the + process of becoming standard as well. See page 23 of <a + href="biblio.html#schneier">Applied Cryptography</a></p> + <p>Alice and Bob have an amusing <a + href="http://www.conceptlabs.co.uk/alicebob.html"> biography</a> on the + web.</p> + </dd> + <dt>ARPA</dt> + <dd>see <a href="#DARPA">DARPA</a></dd> + <dt><a name="ASIO">ASIO</a></dt> + <dd>Australian Security Intelligence Organisation.</dd> + <dt>Asymmetric cryptography</dt> + <dd>See <a href="#public">public key cryptography</a>.</dd> + <dt><a name="authentication">Authentication</a></dt> + <dd>Ensuring that a message originated from the expected sender and has + not been altered on route. <a href="#IPSEC">IPsec</a> uses + authentication in two places: + <ul> + <li>peer authentication, authenticating the players in <a + href="#IKE">IKE</a>'s <a href="#DH">Diffie-Hellman</a> key + exchanges to prevent <a href="#middle">man-in-the-middle + attacks</a>. This can be done in a number of ways. The methods + supported by FreeS/WAN are discussed in our <a + href="adv_config.html#choose">advanced configuration</a> + document.</li> + <li>packet authentication, authenticating packets on an established + <a href="#SA">SA</a>, either with a separate <a + href="#AH">authentication header</a> or with the optional + authentication in the <a href="#ESP">ESP</a> protocol. In either + case, packet authentication uses a <a href="#HMAC">hashed message + athentication code</a> technique.</li> + </ul> + <p>Outside IPsec, passwords are perhaps the most common authentication + mechanism. Their function is essentially to authenticate the person's + identity to the system. Passwords are generally only as secure as the + network they travel over. If you send a cleartext password over a + tapped phone line or over a network with a packet sniffer on it, the + security provided by that password becomes zero. Sending an encrypted + password is no better; the attacker merely records it and reuses it at + his convenience. This is called a <a href="#replay">replay</a> + attack.</p> + <p>A common solution to this problem is a <a + href="#challenge">challenge-response</a> system. This defeats simple + eavesdropping and replay attacks. Of course an attacker might still try + to break the cryptographic algorithm used, or the <a + href="#random">random number</a> generator.</p> + </dd> + <dt><a name="auto">Automatic keying</a></dt> + <dd>A mode in which keys are automatically generated at connection + establisment and new keys automaically created periodically thereafter. + Contrast with <a href="#manual">manual keying</a> in which a single + stored key is used. + <p>IPsec uses the <a href="#DH">Diffie-Hellman key exchange + protocol</a> to create keys. An <a + href="#authentication">authentication</a> mechansim is required for + this. FreeS/WAN normally uses <a href="#RSA">RSA</a> for this. Other + methods supported are discussed in our <a + href="adv_config.html#choose">advanced configuration</a> document.</p> + <p>Having an attacker break the authentication is emphatically not a + good idea. An attacker that breaks authentication, and manages to + subvert some other network entities (DNS, routers or gateways), can use + a <a href="#middle">man-in-the middle attack</a> to break the security + of your IPsec connections.</p> + <p>However, having an attacker break the authentication in automatic + keying is not quite as bad as losing the key in manual keying.</p> + <ul> + <li>An attacker who reads /etc/ipsec.conf and gets the keys for a + manually keyed connection can, without further effort, read all + messages encrypted with those keys, including any old messages he + may have archived.</li> + <li>Automatic keying has a property called <a href="#PFS">perfect + forward secrecy</a>. An attacker who breaks the authentication gets + none of the automatically generated keys and cannot immediately + read any messages. He has to mount a successful <a + href="#middle">man-in-the-middle attack</a> in real time before he + can read anything. He cannot read old archived messages at all and + will not be able to read any future messages not caught by + man-in-the-middle tricks.</li> + </ul> + <p>That said, the secrets used for authentication, stored in <a + href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a>, should + still be protected as tightly as cryptographic keys.</p> + </dd> + <dt><a name="B">B</a></dt> + <dt><a href="http://www.nortelnetworks.com">Bay Networks</a></dt> + <dd>A vendor of routers, hubs and related products, now a subsidiary of + Nortel. Interoperation between their IPsec products and Linux FreeS/WAN + was problematic at last report; see our <a + href="interop.html#bay">interoperation</a> section.</dd> + <dt><a name="benchmarks">benchmarks</a></dt> + <dd>Our default block cipher, <a href="#3DES">triple DES</a>, is slower + than many alternate ciphers that might be used. Speeds achieved, + however, seem adequate for many purposes. For example, the assembler + code from the <a href="#LIBDES">LIBDES</a> library we use encrypts 1.6 + megabytes per second on a Pentium 200, according to the test program + supplied with the library. + <p>For more detail, see our document on <a + href="performance.html">FreeS/WAN performance</a>.</p> + </dd> + <dt><a name="BIND">BIND</a></dt> + <dd><b>B</b>erkeley <b>I</b>nternet <b>N</b>ame <b>D</b>aemon, a widely + used implementation of <a href="#DNS">DNS</a> (Domain Name Service). + See our bibliography for a <a href="#DNS">useful reference</a>. See the + <a href="http://www.isc.org/bind.html">BIND home page</a> for more + information and the latest version.</dd> + <dt><a name="birthday">Birthday attack</a></dt> + <dd>A cryptographic attack based on the mathematics exemplified by the <a + href="#paradox">birthday paradox</a>. This math turns up whenever the + question of two cryptographic operations producing the same result + becomes an issue: + <ul> + <li><a href="#collision">collisions</a> in <a href="#digest">message + digest</a> functions.</li> + <li>identical output blocks from a <a href="#block">block + cipher</a></li> + <li>repetition of a challenge in a <a + href="#challenge">challenge-response</a> system</li> + </ul> + <p>Resisting such attacks is part of the motivation for:</p> + <ul> + <li>hash algorithms such as <a href="#SHA">SHA</a> and <a + href="#RIPEMD">RIPEMD-160</a> giving a 160-bit result rather than + the 128 bits of <a href="#MD4">MD4</a>, <a href="#MD5">MD5</a> and + <a href="#RIPEMD">RIPEMD-128</a>.</li> + <li><a href="#AES">AES</a> block ciphers using a 128-bit block + instead of the 64-bit block of most current ciphers</li> + <li><a href="#IPSEC">IPsec</a> using a 32-bit counter for packets + sent on an <a href="#auto">automatically keyed</a> <a + href="#SA">SA</a> and requiring that the connection always be + rekeyed before the counter overflows.</li> + </ul> + </dd> + <dt><a name="paradox">Birthday paradox</a></dt> + <dd>Not really a paradox, just a rather counter-intuitive mathematical + fact. In a group of 23 people, the chance of a least one pair having + the same birthday is over 50%. + <p>The second person has 1 chance in 365 (ignoring leap years) of + matching the first. If they don't match, the third person's chances of + matching one of them are 2/365. The 4th, 3/365, and so on. The total of + these chances grows more quickly than one might guess.</p> + </dd> + <dt><a name="block">Block cipher</a></dt> + <dd>A <a href="#symmetric">symmetric cipher</a> which operates on + fixed-size blocks of plaintext, giving a block of ciphertext for each. + Contrast with <a href="#stream"> stream cipher</a>. Block ciphers can + be used in various <a href="#mode">modes</a> when multiple block are to + be encrypted. + <p><a href="#DES">DES</a> is among the the best known and widely used + block ciphers, but is now obsolete. Its 56-bit key size makes it <a + href="#desnotsecure">highly insecure</a> today. <a href="#3DES">Triple + DES</a> is the default block cipher for <a href="#FreeSWAN">Linux + FreeS/WAN</a>.</p> + <p>The current generation of block ciphers -- such as <a + href="#Blowfish">Blowfish</a>, <a href="#CAST128">CAST-128</a> and <a + href="#IDEA">IDEA</a> -- all use 64-bit blocks and 128-bit keys. The + next generation, <a href="#AES">AES</a>, uses 128-bit blocks and + supports key sizes up to 256 bits.</p> + <p>The <a href="http://www.ii.uib.no/~larsr/bc.html"> Block Cipher + Lounge</a> web site has more information.</p> + </dd> + <dt><a name="Blowfish">Blowfish</a></dt> + <dd>A <a href="#block">block cipher</a> using 64-bit blocks and keys of + up to 448 bits, designed by <a href="#schneier">Bruce Schneier</a> and + used in several products. + <p>This is not required by the <a href="#IPSEC">IPsec</a> RFCs and not + currently used in <a href="#FreeSWAN">Linux FreeS/WAN</a>.</p> + </dd> + <dt><a name="brute">Brute force attack (exhaustive search)</a></dt> + <dd>Breaking a cipher by trying all possible keys. This is always + possible in theory (except against a <a href="#OTP">one-time pad</a>), + but it becomes practical only if the key size is inadequate. For an + important example, see our document on the <a + href="#desnotsecure">insecurity of DES</a> with its 56-bit key. For an + analysis of key sizes required to resist plausible brute force attacks, + see <a href="http://www.counterpane.com/keylength.html">this paper</a>. + <p>Longer keys protect against brute force attacks. Each extra bit in + the key doubles the number of possible keys and therefore doubles the + work a brute force attack must do. A large enough key defeats + <strong>any</strong> brute force attack.</p> + <p>For example, the EFF's <a href="#EFF">DES Cracker</a> searches a + 56-bit key space in an average of a few days. Let us assume an attacker + that can find a 64-bit key (256 times harder) by brute force search in + a second (a few hundred thousand times faster). For a 96-bit key, that + attacker needs 2<sup>32</sup> seconds, about 135 years. Against a + 128-bit key, he needs 2<sup>32</sup> times that, over 500,000,000,000 + years. Your data is then obviously secure against brute force attacks. + Even if our estimate of the attacker's speed is off by a factor of a + million, it still takes him over 500,000 years to crack a message.</p> + <p>This is why</p> + <ul> + <li>single <a href="#DES">DES</a> is now considered <a + href="#desnotsecure">dangerously insecure</a></li> + <li>all of the current generation of <a href="#block">block + ciphers</a> use a 128-bit or longer key</li> + <li><a href="#AES">AES</a> ciphers support keysizes 128, 192 and 256 + bits</li> + <li>any cipher we add to Linux FreeS/WAN will have <em>at least</em> + a 128-bit key</li> + </ul> + <p><strong>Cautions:</strong><br> + <em>Inadequate keylength always indicates a weak cipher</em> but it is + important to note that <em>adequate keylength does not necessarily + indicate a strong cipher</em>. There are many attacks other than brute + force, and adequate keylength <em>only</em> guarantees resistance to + brute force. Any cipher, whatever its key size, will be weak if design + or implementation flaws allow other attacks.</p> + <p>Also, <em>once you have adequate keylength</em> (somewhere around 90 + or 100 bits), <em>adding more key bits make no practical + difference</em>, even against brute force. Consider our 128-bit example + above that takes 500,000,000,000 years to break by brute force. We + really don't care how many zeroes there are on the end of that, as long + as the number remains ridiculously large. That is, we don't care + exactly how large the key is as long as it is large enough.</p> + <p>There may be reasons of convenience in the design of the cipher to + support larger keys. For example <a href="#Blowfish">Blowfish</a> + allows up to 448 bits and <a href="#RC4">RC4</a> up to 2048, but beyond + 100-odd bits it makes no difference to practical security.</p> + </dd> + <dt>Bureau of Export Administration</dt> + <dd>see <a href="#BXA">BXA</a></dd> + <dt><a name="BXA">BXA</a></dt> + <dd>The US Commerce Department's <b>B</b>ureau of E<b>x</b>port + <b>A</b>dministration which administers the <a href="#EAR">EAR</a> + Export Administration Regulations controling the export of, among other + things, cryptography.</dd> + <dt><a name="C">C</a></dt> + <dt><a name="CA">CA</a></dt> + <dd><b>C</b>ertification <b>A</b>uthority, an entity in a <a + href="#PKI">public key infrastructure</a> that can certify keys by + signing them. Usually CAs form a hierarchy. The top of this hierarchy + is called the <a href="#rootCA">root CA</a>. + <p>See <a href="#web">Web of Trust</a> for an alternate model.</p> + </dd> + <dt><a name="CAST128">CAST-128</a></dt> + <dd>A <a href="#block">block cipher</a> using 64-bit blocks and 128-bit + keys, described in RFC 2144 and used in products such as <a + href="#Entrust">Entrust</a> and recent versions of <a + href="#PGP">PGP</a>. + <p>This is not required by the <a href="#IPSEC">IPsec</a> RFCs and not + currently used in <a href="#FreeSWAN">Linux FreeS/WAN</a>.</p> + </dd> + <dt>CAST-256</dt> + <dd><a href="#Entrust">Entrust</a>'s candidate cipher for the <a + href="#AES">AES standard</a>, largely based on the <a + href="#CAST128">CAST-128</a> design.</dd> + <dt><a name="CBC">CBC mode</a></dt> + <dd><b>C</b>ipher <b>B</b>lock <b>C</b>haining <a href="#mode">mode</a>, + a method of using a <a href="#block">block cipher</a> in which for each + block except the first, the result of the previous encryption is XORed + into the new block before it is encrypted. CBC is the mode used in <a + href="#IPSEC">IPsec</a>. + <p>An <a href="#IV">initialisation vector</a> (IV) must be provided. It + is XORed into the first block before encryption. The IV need not be + secret but should be different for each message and unpredictable.</p> + </dd> + <dt><a name="CIDR">CIDR</a></dt> + <dd><b>C</b>lassless <b>I</b>nter-<b>D</b>omain <b>R</b>outing, + an addressing scheme used to describe networks not + restricted to the old Class A, B, and C sizes. + A CIDR block is written + <VAR>address</VAR>/<VAR>mask</VAR>, where <VAR>address</VAR> is + a 32-bit Internet address. + The first <VAR>mask</VAR> bits of <VAR>address</VAR> + are part of the gateway address, while the remaining bits designate + other host addresses. + For example, the CIDR block 192.0.2.96/27 describes a network with + gateway + 192.0.2.96, hosts 192.0.2.96 through 192.0.2.126 and broadcast + 192.0.2.127. + <p>FreeS/WAN policy group files accept CIDR blocks of the format + <VAR>address</VAR>/[<VAR>mask</VAR>], where <VAR>address</VAR> may + take the form <VAR>name.domain.tld</VAR>. An absent <VAR>mask</VAR> + is assumed to be /32. + </p> + </dd> + + <dt>Certification Authority</dt> + <dd>see <a href="#CA">CA</a></dd> + <dt><a name="challenge">Challenge-response authentication</a></dt> + <dd>An <a href="#authentication">authentication</a> system in which one + player generates a <a href="#random">random number</a>, encrypts it and + sends the result as a challenge. The other player decrypts and sends + back the result. If the result is correct, that proves to the first + player that the second player knew the appropriate secret, required for + the decryption. Variations on this technique exist using <a + href="#public">public key</a> or <a href="#symmetric">symmetric</a> + cryptography. Some provide two-way authentication, assuring each player + of the other's identity. + <p>This is more secure than passwords against two simple attacks:</p> + <ul> + <li>If cleartext passwords are sent across the wire (e.g. for + telnet), an eavesdropper can grab them. The attacker may even be + able to break into other systems if the user has chosen the same + password for them.</li> + <li>If an encrypted password is sent, an attacker can record the + encrypted form and use it later. This is called a replay + attack.</li> + </ul> + <p>A challenge-response system never sends a password, either cleartext + or encrypted. An attacker cannot record the response to one challenge + and use it as a response to a later challenge. The random number is + different each time.</p> + <p>Of course an attacker might still try to break the cryptographic + algorithm used, or the <a href="#random">random number</a> + generator.</p> + </dd> + <dt><a name="mode">Cipher Modes</a></dt> + <dd>Different ways of using a block cipher when encrypting multiple + blocks. + <p>Four standard modes were defined for <a href="#DES">DES</a> in <a + href="#FIPS">FIPS</a> 81. They can actually be applied with any block + cipher.</p> + + <table> + <tbody> + <tr> + <td></td> + <td><a href="#ECB">ECB</a></td> + <td>Electronic CodeBook</td> + <td>encrypt each block independently</td> + </tr> + <tr> + <td></td> + <td><a href="#CBC">CBC</a></td> + <td>Cipher Block Chaining<br> + </td> + <td>XOR previous block ciphertext into new block plaintext before + encrypting new block</td> + </tr> + <tr> + <td></td> + <td>CFB</td> + <td>Cipher FeedBack</td> + <td></td> + </tr> + <tr> + <td></td> + <td>OFB</td> + <td>Output FeedBack</td> + <td></td> + </tr> + </tbody> + </table> + <p><a href="#IPSEC">IPsec</a> uses <a href="#CBC">CBC</a> mode since + this is only marginally slower than <a href="#ECB">ECB</a> and is more + secure. In ECB mode the same plaintext always encrypts to the same + ciphertext, unless the key is changed. In CBC mode, this does not + occur.</p> + <p>Various other modes are also possible, but none of them are used in + IPsec.</p> + </dd> + <dt><a name="ciphertext">Ciphertext</a></dt> + <dd>The encrypted output of a cipher, as opposed to the unencrypted <a + href="#plaintext">plaintext</a> input.</dd> + <dt><a href="http://www.cisco.com">Cisco</a></dt> + <dd>A vendor of routers, hubs and related products. Their IPsec products + interoperate with Linux FreeS/WAN; see our <a + href="interop.html#Cisco">interop</a> section.</dd> + <dt><a name="client">Client</a></dt> + <dd>This term has at least two distinct uses in discussing IPsec: + <ul> + <li>The <strong>clients of an IPsec gateway</strong> are the machines + it protects, typically on one or more subnets behind the gateway. + In this usage, all the machines on an office network are clients of + that office's IPsec gateway. Laptop or home machines connecting to + the office, however, are <em>not</em> clients of that gateway. They + are remote gateways, running the other end of an IPsec connection. + Each of them is also its own client.</li> + <li><strong>IPsec client software</strong> is used to describe + software which runs on various standalone machines to let them + connect to IPsec networks. In this usage, a laptop or home machine + connecting to the office is a client, and the office gateway is the + server.</li> + </ul> + <p>We generally use the term in the first sense. Vendors of Windows + IPsec solutions often use it in the second. See this <a + href="interop.html#client.server">discussion</a>.</p> + </dd> + <dt><a name="cc">Common Criteria</a></dt> + <dd>A set of international security classifications which are replacing + the old US <a href="#rainbow">Rainbow Book</a> standards and similar + standards in other countries. + <p>Web references include this <a href="http://csrc.nist.gov/cc">US + government site</a> and this <a + href="http://www.commoncriteria.org">global home page</a>.</p> + </dd> + <dt>Conventional cryptography</dt> + <dd>See <a href="#symmetric">symmetric cryptography</a></dd> + <dt><a name="collision">Collision resistance</a></dt> + <dd>The property of a <a href="#digest">message digest</a> algorithm + which makes it hard for an attacker to find or construct two inputs + which hash to the same output.</dd> + <dt>Copyleft</dt> + <dd>see GNU <a href="#GPL">General Public License</a></dd> + <dt><a name="CSE">CSE</a></dt> + <dd><a href="http://www.cse-cst.gc.ca/">Communications Security + Establishment</a>, the Canadian organisation for <a + href="#SIGINT">signals intelligence</a>.</dd> + <dt><a name="D">D</a></dt> + <dt><a name="DARPA">DARPA (sometimes just ARPA)</a></dt> + <dd>The US government's <b>D</b>efense <b>A</b>dvanced <b>R</b>esearch + <b>P</b>rojects <b>A</b>gency. Projects they have funded over the years + have included the Arpanet which evolved into the Internet, the TCP/IP + protocol suite (as a replacement for the original Arpanet suite), the + Berkeley 4.x BSD Unix projects, and <a href="#SDNS">Secure DNS</a>. + <p>For current information, see their <a + href="http://www.darpa.mil/ito">web site</a>.</p> + </dd> + <dt><a name="DOS">Denial of service (DoS) attack</a></dt> + <dd>An attack that aims at denying some service to legitimate users of a + system, rather than providing a service to the attacker. + <ul> + <li>One variant is a flooding attack, overwhelming the system with + too many packets, to much email, or whatever.</li> + <li>A closely related variant is a resource exhaustion attack. For + example, consider a "TCP SYN flood" attack. Setting up a TCP + connection involves a three-packet exchange: + <ul> + <li>Initiator: Connection please (SYN)</li> + <li>Responder: OK (ACK)</li> + <li>Initiator: OK here too</li> + </ul> + <p>If the attacker puts bogus source information in the first + packet, such that the second is never delivered, the responder may + wait a long time for the third to come back. If responder has + already allocated memory for the connection data structures, and if + many of these bogus packets arrive, the responder may run out of + memory.</p> + </li> + <li>Another variant is to feed the system undigestible data, hoping + to make it sick. For example, IP packets are limited in size to 64K + bytes and a fragment carries information on where it starts within + that 64K and how long it is. The "ping of death" delivers fragments + that say, for example, that they start at 60K and are 20K long. + Attempting to re-assemble these without checking for overflow can + be fatal.</li> + </ul> + <p>The two example attacks discussed were both quite effective when + first discovered, capable of crashing or disabling many operating + systems. They were also well-publicised, and today far fewer systems + are vulnerable to them.</p> + </dd> + <dt><a name="DES">DES</a></dt> + <dd>The <b>D</b>ata <b>E</b>ncryption <b>S</b>tandard, a <a + href="#block">block cipher</a> with 64-bit blocks and a 56-bit key. + Probably the most widely used <a href="#symmetric">symmetric cipher</a> + ever devised. DES has been a US government standard for their own use + (only for unclassified data), and for some regulated industries such as + banking, since the late 70's. It is now being replaced by <a + href="#AES">AES</a>. + <p><a href="politics.html#desnotsecure">DES is seriously insecure + against current attacks.</a></p> + <p><a href="#FreeSWAN">Linux FreeS/WAN</a> does not include DES, even + though the RFCs specify it. <b>We strongly recommend that single DES + not be used.</b></p> + <p>See also <a href="#3DES">3DES</a> and <a href="#DESX">DESX</a>, + stronger ciphers based on DES.</p> + </dd> + <dt><a name="DESX">DESX</a></dt> + <dd>An improved <a href="#DES">DES</a> suggested by Ron Rivest of RSA + Data Security. It XORs extra key material into the text before and + after applying the DES cipher. + <p>This is not required by the <a href="#IPSEC">IPsec</a> RFCs and not + currently used in <a href="#FreeSWAN">Linux FreeS/WAN</a>. DESX would + be the easiest additional transform to add; there would be very little + code to write. It would be much faster than 3DES and almost certainly + more secure than DES. However, since it is not in the RFCs other IPsec + implementations cannot be expected to have it.</p> + </dd> + <dt>DH</dt> + <dd>see <a href="#DH">Diffie-Hellman</a></dd> + <dt><a name="DHCP">DHCP</a></dt> + <dd><strong>D</strong>ynamic <strong>H</strong>ost + <strong>C</strong>onfiguration <strong>P</strong>rotocol, a method of + assigning <a href="#dynamic">dynamic IP addresses</a>, and providing + additional information such as addresses of DNS servers and of + gateways. See this <a href="http://www.dhcp.org">DHCP resource + page.</a></dd> + <dt><a name="DH">Diffie-Hellman (DH) key exchange protocol</a></dt> + <dd>A protocol that allows two parties without any initial shared secret + to create one in a manner immune to eavesdropping. Once they have done + this, they can communicate privately by using that shared secret as a + key for a block cipher or as the basis for key exchange. + <p>The protocol is secure against all <a href="#passive">passive + attacks</a>, but it is not at all resistant to active <a + href="#middle">man-in-the-middle attacks</a>. If a third party can + impersonate Bob to Alice and vice versa, then no useful secret can be + created. Authentication of the participants is a prerequisite for safe + Diffie-Hellman key exchange. IPsec can use any of several <a + href="#authentication">authentication</a> mechanisims. Those supported + by FreeS/WAN are discussed in our <a + href="config.html#choose">configuration</a> section.</p> + <p>The Diffie-Hellman key exchange is based on the <a + href="#dlog">discrete logarithm</a> problem and is secure unless + someone finds an efficient solution to that problem.</p> + <p>Given a prime <var>p</var> and generator <var>g</var> (explained + under <a href="#dlog">discrete log</a> below), Alice:</p> + <ul> + <li>generates a random number <var>a</var></li> + <li>calculates <var>A = g^a modulo p</var></li> + <li>sends <var>A</var> to Bob</li> + </ul> + <p>Meanwhile Bob:</p> + <ul> + <li>generates a random number <var>b</var></li> + <li>calculates <var>B = g^b modulo p</var></li> + <li>sends <var>B</var> to Alice</li> + </ul> + <p>Now Alice and Bob can both calculate the shared secret <var>s = + g^(ab)</var>. Alice knows <var>a</var> and <var>B</var>, so she + calculates <var>s = B^a</var>. Bob knows <var>A</var> and <var>b</var> + so he calculates <var>s = A^b</var>.</p> + <p>An eavesdropper will know <var>p</var> and <var>g</var> since these + are made public, and can intercept <var>A</var> and <var>B</var> but, + short of solving the <a href="#dlog">discrete log</a> problem, these do + not let him or her discover the secret <var>s</var>.</p> + </dd> + <dt><a name="signature">Digital signature</a></dt> + <dd>Sender: + <ul> + <li>calculates a <a href="#digest">message digest</a> of a + document</li> + <li>encrypts the digest with his or her private key, using some <a + href="#public">public key cryptosystem</a>.</li> + <li>attaches the encrypted digest to the document as a signature</li> + </ul> + <p>Receiver:</p> + <ul> + <li>calculates a digest of the document (not including the + signature)</li> + <li>decrypts the signature with the signer's public key</li> + <li>verifies that the two results are identical</li> + </ul> + <p>If the public-key system is secure and the verification succeeds, + then the receiver knows</p> + <ul> + <li>that the document was not altered between signing and + verification</li> + <li>that the signer had access to the private key</li> + </ul> + <p>Such an encrypted message digest can be treated as a signature since + it cannot be created without <em>both</em> the document <em>and</em> + the private key which only the sender should possess. The <a + href="web.html#legal">legal issues</a> are complex, but several + countries are moving in the direction of legal recognition for digital + signatures.</p> + </dd> + <dt><a name="dlog">discrete logarithm problem</a></dt> + <dd>The problem of finding logarithms in a finite field. Given a field + defintion (such definitions always include some operation analogous to + multiplication) and two numbers, a base and a target, find the power + which the base must be raised to in order to yield the target. + <p>The discrete log problem is the basis of several cryptographic + systems, including the <a href="#DH">Diffie-Hellman</a> key exchange + used in the <a href="#IKE">IKE</a> protocol. The useful property is + that exponentiation is relatively easy but the inverse operation, + finding the logarithm, is hard. The cryptosystems are designed so that + the user does only easy operations (exponentiation in the field) but an + attacker must solve the hard problem (discrete log) to crack the + system.</p> + <p>There are several variants of the problem for different types of + field. The IKE/Oakley key determination protocol uses two variants, + either over a field modulo a prime or over a field defined by an + elliptic curve. We give an example modulo a prime below. For the + elliptic curve version, consult an advanced text such as <a + href="biblio.html#handbook">Handbook of Applied Cryptography</a>.</p> + <p>Given a prime <var>p</var>, a generator <var>g</var> for the field + modulo that prime, and a number <var>x</var> in the field, the problem + is to find <var>y</var> such that <var>g^y = x</var>.</p> + <p>For example, let p = 13. The field is then the integers from 0 to + 12. Any integer equals one of these modulo 13. That is, the remainder + when any integer is divided by 13 must be one of these.</p> + <p>2 is a generator for this field. That is, the powers of two modulo + 13 run through all the non-zero numbers in the field. Modulo 13 we + have:</p> + <pre> y x + 2^0 == 1 + 2^1 == 2 + 2^2 == 4 + 2^3 == 8 + 2^4 == 3 that is, the remainder from 16/13 is 3 + 2^5 == 6 the remainder from 32/13 is 6 + 2^6 == 12 and so on + 2^7 == 11 + 2^8 == 9 + 2^9 == 5 + 2^10 == 10 + 2^11 == 7 + 2^12 == 1</pre> + <p>Exponentiation in such a field is not difficult. Given, say, + <nobr><var>y = 11</var>,</nobr>calculating <nobr><var>x = + 7</var></nobr>is straightforward. One method is just to calculate + <nobr><var>2^11 = 2048</var>,</nobr>then <nobr><var>2048 mod 13 == + 7</var>.</nobr>When the field is modulo a large prime (say a few 100 + digits) you need a silghtly cleverer method and even that is moderately + expensive in computer time, but the calculation is still not + problematic in any basic way.</p> + <p>The discrete log problem is the reverse. In our example, given + <nobr><var>x = 7</var>,</nobr>find the logarithm <nobr><var>y = + 11</var>.</nobr>When the field is modulo a large prime (or is based on + a suitable elliptic curve), this is indeed problematic. No solution + method that is not catastrophically expensive is known. Quite a few + mathematicians have tackled this problem. No efficient method has been + found and mathematicians do not expect that one will be. It seems + likely no efficient solution to either of the main variants the + discrete log problem exists.</p> + <p>Note, however, that no-one has proven such methods do not exist. If + a solution to either variant were found, the security of any crypto + system using that variant would be destroyed. This is one reason <a + href="#IKE">IKE</a> supports two variants. If one is broken, we can + switch to the other.</p> + </dd> + <dt><a name="discretionary">discretionary access control</a></dt> + <dd>access control mechanisms controlled by the user, for example Unix + rwx file permissions. These contrast with <a + href="#mandatory">mandatory access controls</a>.</dd> + <dt><a name="DNS">DNS</a></dt> + <dd><b>D</b>omain <b>N</b>ame <b>S</b>ervice, a distributed database + through which names are associated with numeric addresses and other + information in the Internet Protocol Suite. See also the <a + href="background.html#dns.background">DNS background</a> section of our + documentation.</dd> + <dt>DOS attack</dt> + <dd>see <a href="#DOS">Denial Of Service</a> attack</dd> + <dt><a name="dynamic">dynamic IP address</a></dt> + <dd>an IP address which is automatically assigned, either by <a + href="#DHCP">DHCP</a> or by some protocol such as <a + href="#PPP">PPP</a> or <a href="#PPPoE">PPPoE</a> which the machine + uses to connect to the Internet. This is the opposite of a <a + href="#static">static IP address</a>, pre-set on the machine + itself.</dd> + <dt><a name="E">E</a></dt> + <dt><a name="EAR">EAR</a></dt> + <dd>The US government's <b>E</b>xport <b>A</b>dministration + <b>R</b>egulations, administered by the <a href="#BXA">Bureau of Export + Administration</a>. These have replaced the earlier <a + href="#ITAR">ITAR</a> regulations as the controls on export of + cryptography.</dd> + <dt><a name="ECB">ECB mode</a></dt> + <dd><b>E</b>lectronic <b>C</b>ode<b>B</b>ook mode, the simplest way to + use a block cipher. See <a href="#mode">Cipher Modes</a>.</dd> + <dt><a name="EDE">EDE</a></dt> + <dd>The sequence of operations normally used in either the three-key + variant of <a href="#3DES">triple DES</a> used in <a + href="#IPSEC">IPsec</a> or the <a href="#2key">two-key</a> variant used + in some other systems. + <p>The sequence is:</p> + <ul> + <li><b>E</b>ncrypt with key1</li> + <li><b>D</b>ecrypt with key2</li> + <li><b>E</b>ncrypt with key3</li> + </ul> + <p>For the two-key version, key1=key3.</p> + <p>The "advantage" of this EDE order of operations is that it makes it + simple to interoperate with older devices offering only single DES. Set + key1=key2=key3 and you have the worst of both worlds, the overhead of + triple DES with the "security" of single DES. Since both the <a + href="politics.html#desnotsecure">security of single DES</a> and the + overheads of triple DES are seriously inferior to many other ciphers, + this is a spectacularly dubious "advantage".</p> + </dd> + <dt><a name="Entrust">Entrust</a></dt> + <dd>A Canadian company offerring enterprise <a href="#PKI">PKI</a> + products using <a href="#CAST128">CAST-128</a> symmetric crypto, <a + href="#RSA">RSA</a> public key and <a href="#X509">X.509</a> + directories. <a href="http://www.entrust.com">Web site</a></dd> + <dt><a name="EFF">EFF</a></dt> + <dd><a href="http://www.eff.org">Electronic Frontier Foundation</a>, an + advocacy group for civil rights in cyberspace.</dd> + <dt><a name="encryption">Encryption</a></dt> + <dd>Techniques for converting a readable message (<a + href="#plaintext">plaintext</a>) into apparently random material (<a + href="#ciphertext">ciphertext</a>) which cannot be read if intercepted. + A key is required to read the message. + <p>Major variants include <a href="#symmetric">symmetric</a> encryption + in which sender and receiver use the same secret key and <a + href="#public">public key</a> methods in which the sender uses one of a + matched pair of keys and the receiver uses the other. Many current + systems, including <a href="#IPSEC">IPsec</a>, are <a + href="#hybrid">hybrids</a> combining the two techniques.</p> + </dd> + <dt><a name="ESP">ESP</a></dt> + <dd><b>E</b>ncapsulated <b>S</b>ecurity <b>P</b>ayload, the <a + href="#IPSEC">IPsec</a> protocol which provides <a + href="#encryption">encryption</a>. It can also provide <a + href="#authentication">authentication</a> service and may be used with + null encryption (which we do not recommend). For details see our <a + href="ipsec.html#ESP.ipsec">IPsec</a> document and/or RFC 2406.</dd> + <dt><a name="#extruded">Extruded subnet</a></dt> + <dd>A situation in which something IP sees as one network is actually in + two or more places. + <p>For example, the Internet may route all traffic for a particular + company to that firm's corporate gateway. It then becomes the company's + problem to get packets to various machines on their <a + href="#subnet">subnets</a> in various departments. They may decide to + treat a branch office like a subnet, giving it IP addresses "on" their + corporate net. This becomes an extruded subnet.</p> + <p>Packets bound for it are delivered to the corporate gateway, since + as far as the outside world is concerned, that subnet is part of the + corporate network. However, instead of going onto the corporate LAN (as + they would for, say, the accounting department) they are then + encapsulated and sent back onto the Internet for delivery to the branch + office.</p> + <p>For information on doing this with Linux FreeS/WAN, look in our <a + href="adv_config.html#extruded.config">advanced configuration</a> + section.</p> + </dd> + <dt>Exhaustive search</dt> + <dd>See <a href="#brute">brute force attack</a>.</dd> + <dt><a name="F">F</a></dt> + <dt><a name="FIPS">FIPS</a></dt> + <dd><b>F</b>ederal <b>I</b>nformation <b>P</b>rocessing <b>S</b>tandard, + the US government's standards for products it buys. These are issued by + <a href="#NIST">NIST</a>. Among other things, <a href="#DES">DES</a> + and <a href="#SHA">SHA</a> are defined in FIPS documents. NIST have a + <a href="http://www.itl.nist.gov/div897/pubs">FIPS home page</a>.</dd> + <dt><a name="FSF">Free Software Foundation (FSF)</a></dt> + <dd>An organisation to promote free software, free in the sense of these + quotes from their web pages</dd> + <dd> + <blockquote> + "Free software" is a matter of liberty, not price. To understand the + concept, you should think of "free speech", not "free beer." + <p>"Free software" refers to the users' freedom to run, copy, + distribute, study, change and improve the software.</p> + </blockquote> + <p>See also <a href="#GNU">GNU</a>, <a href="#GPL">GNU General Public + License</a>, and <a href="http://www.fsf.org">the FSF site</a>.</p> + </dd> + <dt>FreeS/WAN</dt> + <dd>see <a href="#FreeSWAN">Linux FreeS/WAN</a></dd> + <dt><a name="fullnet">Fullnet</A></dt> + <dd>The CIDR block containing all IPs of its IP version. + The <A HREF="#IPv4">IPv4</A> fullnet is written 0.0.0.0/0. + Also known as "all" and "default", + fullnet may be used in a routing table + to specify a default route, + and in a FreeS/WAN + <A HREF="policygroups.html#policygroups">policy group</A> file to + specify a default IPsec policy.</dd> + <dt>FSF</dt> + <dd>see <a href="#FSF">Free software Foundation</a></dd> + <dt><a name="G">G</a></dt> + <dt><a name="GCHQ">GCHQ</a></dt> + <dd><a href="http://www.gchq.gov.uk">Government Communications + Headquarters</a>, the British organisation for <a + href="#SIGINT">signals intelligence</a>.</dd> + <dt>generator of a prime field</dt> + <dd>see <a href="#dlog">discrete logarithm problem</a></dd> + <dt><a name="GILC">GILC</a></dt> + <dd><a href="http://www.gilc.org">Global Internet Liberty Campaign</a>, + an international organisation advocating, among other things, free + availability of cryptography. They have a <a + href="http://www.gilc.org/crypto/wassenaar">campaign</a> to remove + cryptographic software from the <a href="#Wassenaar.gloss">Wassenaar + Arrangement</a>.</dd> + <dt>Global Internet Liberty Campaign</dt> + <dd>see <a href="#GILC">GILC</a>.</dd> + <dt><a name="GTR">Global Trust Register</a></dt> + <dd>An attempt to create something like a <a href="#rootCA">root CA</a> + for <a href="#PGP">PGP</a> by publishing both <a + href="biblio.html#GTR">as a book</a> and <a + href="http://www.cl.cam.ac.uk/Research/Security/Trust-Register"> on the + web</a> the fingerprints of a set of verified keys for well-known users + and organisations.</dd> + <dt><a name="GMP">GMP</a></dt> + <dd>The <b>G</b>NU <b>M</b>ulti-<b>P</b>recision library code, used in <a + href="#FreeSWAN">Linux FreeS/WAN</a> by <a href="#Pluto">Pluto</a> for + <a href="#public">public key</a> calculations. See the <a + href="http://www.swox.com/gmp">GMP home page</a>.</dd> + <dt><a name="GNU">GNU</a></dt> + <dd><b>G</b>NU's <b>N</b>ot <b>U</b>nix, the <a href="#FSF">Free Software + Foundation's</a> project aimed at creating a free system with at least + the capabilities of Unix. <a href="#Linux">Linux</a> uses GNU utilities + extensively.</dd> + <dt><a name="#GOST">GOST</a></dt> + <dd>a Soviet government standard <a href="#block">block cipher</a>. <a + href="biblio.html#schneier">Applied Cryptography</a> has details.</dd> + <dt>GPG</dt> + <dd>see <a href="#GPG">GNU Privacy Guard</a></dd> + <dt><a name="GPL">GNU General Public License</a>(GPL, copyleft)</dt> + <dd>The license developed by the <a href="#FSF">Free Software + Foundation</a> under which <a href="#Linux">Linux</a>, <a + href="#FreeSWAN">Linux FreeS/WAN</a> and many other pieces of software + are distributed. The license allows anyone to redistribute and modify + the code, but forbids anyone from distributing executables without + providing access to source code. For more details see the file <a + href="../COPYING">COPYING</a> included with GPLed source distributions, + including ours, or <a href="http://www.fsf.org/copyleft/gpl.html"> the + GNU site's GPL page</a>.</dd> + <dt><a name="GPG">GNU Privacy Guard</a></dt> + <dd>An open source implementation of Open <a href="#PGP">PGP</a> as + defined in RFC 2440. See their <a href="http://www.gnupg.org">web + site</a></dd> + <dt>GPL</dt> + <dd>see <a href="#GPL">GNU General Public License</a>.</dd> + <dt><a name="H">H</a></dt> + <dt><a name="hash">Hash</a></dt> + <dd>see <a href="#digest">message digest</a></dd> + <dt><a name="HMAC">Hashed Message Authentication Code (HMAC)</a></dt> + <dd>using keyed <a href="#digest">message digest</a> functions to + authenticate a message. This differs from other uses of these functions: + <ul> + <li>In normal usage, the hash function's internal variable are + initialised in some standard way. Anyone can reproduce the hash to + check that the message has not been altered.</li> + <li>For HMAC usage, you initialise the internal variables from the + key. Only someone with the key can reproduce the hash. A successful + check of the hash indicates not only that the message is unchanged + but also that the creator knew the key.</li> + </ul> + <p>The exact techniques used in <a href="#IPSEC">IPsec</a> are defined + in RFC 2104. They are referred to as HMAC-MD5-96 and HMAC-SHA-96 + because they output only 96 bits of the hash. This makes some attacks + on the hash functions harder.</p> + </dd> + <dt>HMAC</dt> + <dd>see <a href="#HMAC">Hashed Message Authentication Code</a></dd> + <dt>HMAC-MD5-96</dt> + <dd>see <a href="#HMAC">Hashed Message Authentication Code</a></dd> + <dt>HMAC-SHA-96</dt> + <dd>see <a href="#HMAC">Hashed Message Authentication Code</a></dd> + <dt><a name="hybrid">Hybrid cryptosystem</a></dt> + <dd>A system using both <a href="#public">public key</a> and <a + href="#symmetric">symmetric cipher</a> techniques. This works well. + Public key methods provide key management and <a + href="#signature">digital signature</a> facilities which are not + readily available using symmetric ciphers. The symmetric cipher, + however, can do the bulk of the encryption work much more efficiently + than public key methods.</dd> + <dt><a name="I">I</a></dt> + <dt><a name="IAB">IAB</a></dt> + <dd><a href="http://www.iab.org/iab">Internet Architecture Board</a>.</dd> + <dt><a name="ICMP.gloss">ICMP</a></dt> + <dd><strong>I</strong>nternet <strong>C</strong>ontrol + <strong>M</strong>essage <strong>P</strong>rotocol. This is used for + various IP-connected devices to manage the network.</dd> + <dt><a name="IDEA">IDEA</a></dt> + <dd><b>I</b>nternational <b>D</b>ata <b>E</b>ncrypion <b>A</b>lgorithm, + developed in Europe as an alternative to exportable American ciphers + such as <a href="#DES">DES</a> which were <a href="#desnotsecure">too + weak for serious use</a>. IDEA is a <a href="#block">block cipher</a> + using 64-bit blocks and 128-bit keys, and is used in products such as + <a href="#PGP">PGP</a>. + <p>IDEA is not required by the <a href="#IPSEC">IPsec</a> RFCs and not + currently used in <a href="#FreeSWAN">Linux FreeS/WAN</a>.</p> + <p>IDEA is patented and, with strictly limited exceptions for personal + use, using it requires a license from <a + href="http://www.ascom.com">Ascom</a>.</p> + </dd> + <dt><a name="IEEE">IEEE</a></dt> + <dd><a href="http://www.ieee.org">Institute of Electrical and Electronic + Engineers</a>, a professional association which, among other things, + sets some technical standards</dd> + <dt><a name="IESG">IESG</a></dt> + <dd><a href="http://www.iesg.org">Internet Engineering Steering + Group</a>.</dd> + <dt><a name="IETF">IETF</a></dt> + <dd><a href="http://www.ietf.org">Internet Engineering Task Force</a>, + the umbrella organisation whose various working groups make most of the + technical decisions for the Internet. The IETF <a + href="http://www.ietf.org/html.charters/ipsec-charter.html"> IPsec + working group</a> wrote the <a href="#RFC">RFCs</a> we are + implementing.</dd> + <dt><a name="IKE">IKE</a></dt> + <dd><b>I</b>nternet <b>K</b>ey <b>E</b>xchange, based on the <a + href="#DH">Diffie-Hellman</a> key exchange protocol. For details, see + RFC 2409 and our <a href="ipsec.html">IPsec</a> document. IKE is + implemented in <a href="#FreeSWAN">Linux FreeS/WAN</a> by the <a + href="#Pluto">Pluto daemon</a>.</dd> + <dt>IKE v2</dt> + <dd>A proposed replacement for <a href="#IKE">IKE</a>. There are other + candidates, such as <a href="#JFK">JFK</a>, and at time of writing + (March 2002) the choice between them has not yet been made and does not + appear imminent.</dd> + <dt><a name="iOE">iOE</a></dt> + <dd>See <A HREF="#initiate-only">Initiate-only opportunistic + encryption</A>.</dd> + <dt><a name="IP">IP</a></dt> + <dd><b>I</b>nternet <b>P</b>rotocol.</dd> + <dt><a name="masq">IP masquerade</a></dt> + <dd>A mostly obsolete term for a method of allowing multiple machines to + communicate over the Internet when only one IP address is available for + their use. The more current term is Network Address Translation or <a + href="#NAT.gloss">NAT</a>.</dd> + <dt><a name="IPng">IPng</a></dt> + <dd>"IP the Next Generation", see <a href="#ipv6.gloss">IPv6</a>.</dd> + <dt><a name="IPv4">IPv4</a></dt> + <dd>The current version of the <a href="#IP">Internet protocol + suite</a>.</dd> + <dt><a name="ipv6.gloss">IPv6 (IPng)</a></dt> + <dd>Version six of the <a href="#IP">Internet protocol suite</a>, + currently being developed. It will replace the current <a + href="#IPv4">version four</a>. IPv6 has <a href="#IPSEC">IPsec</a> as a + mandatory component. + <p>See this <a + href="http://playground.sun.com/pub/ipng/html/ipng-main.html">web + site</a> for more details, and our <a + href="compat.html#ipv6">compatibility</a> document for information on + FreeS/WAN and the Linux implementation of IPv6.</p> + </dd> + <dt><a name="IPSEC">IPsec</a> or IPSEC</dt> + <dd><b>I</b>nternet <b>P</b>rotocol <b>SEC</b>urity, security functions + (<a href="#authentication">authentication</a> and <a + href="#encryption">encryption</a>) implemented at the IP level of the + protocol stack. It is optional for <a href="#IPv4">IPv4</a> and + mandatory for <a href="#ipv6.gloss">IPv6</a>. + <p>This is the standard <a href="#FreeSWAN">Linux FreeS/WAN</a> is + implementing. For more details, see our <a href="ipsec.html">IPsec + Overview</a>. For the standards, see RFCs listed in our <a + href="rfc.html#RFC">RFCs document</a>.</p> + </dd> + <dt><a name="IPX">IPX</a></dt> + <dd>Novell's Netware protocol tunnelled over an IP link. Our <a + href="firewall.html#user.scripts">firewalls</a> document includes an + example of using this through an IPsec tunnel.</dd> + <dt><a name="ISAKMP">ISAKMP</a></dt> + <dd><b>I</b>nternet <b>S</b>ecurity <b>A</b>ssociation and <b>K</b>ey + <b>M</b>anagement <b>P</b>rotocol, defined in RFC 2408.</dd> + <dt><a name="ITAR">ITAR</a></dt> + <dd><b>I</b>nternational <b>T</b>raffic in <b>A</b>rms + <b>R</b>egulations, US regulations administered by the State Department + which until recently limited export of, among other things, + cryptographic technology and software. ITAR still exists, but the + limits on cryptography have now been transferred to the <a + href="#EAR">Export Administration Regulations</a> under the Commerce + Department's <a href="#BXA">Bureau of Export Administration</a>.</dd> + <dt>IV</dt> + <dd>see <a href="#IV">Initialisation vector</a></dd> + <dt><a name="IV">Initialisation Vector (IV)</a></dt> + <dd>Some cipher <a href="#mode">modes</a>, including the <a + href="#CBC">CBC</a> mode which IPsec uses, require some extra data at + the beginning. This data is called the initialisation vector. It need + not be secret, but should be different for each message. Its function + is to prevent messages which begin with the same text from encrypting + to the same ciphertext. That might give an analyst an opening, so it is + best prevented.</dd> + <dt><a name="initiate-only">Initiate-only opportunistic + encryption (iOE)</a></dt> + <dd>A form of + <A HREF="#carpediem">opportunistic encryption</A> (OE) in which + a host proposes opportunistic connections, but lacks the reverse DNS + records necessary to support incoming opportunistic connection requests. + Common among hosts on cable or pppoe connections where the system + administrator does not have write access to the DNS reverse map + for the host's external IP. + <p>Configuring for initiate-only opportunistic encryption + is described in our + <a href="quickstart.html#opp.client">quickstart</a> document.</p> + </dd> + <dt><a name="J">J</a></dt> + <dt><a name="JFK">JFK</a></dt> + <dd><strong>J</strong>ust <strong>F</strong>ast <strong>K</strong>eying, + a proposed simpler replacement for <a href="#IKE">IKE.</a></dd> + <dt><a name="K">K</a></dt> + <dt><a name="kernel">Kernel</a></dt> + <dd>The basic part of an operating system (e.g. Linux) which controls the + hardware and provides services to all other programs. + <p>In the Linux release numbering system, an even second digit as in + 2.<strong>2</strong>.x indicates a stable or production kernel while an + odd number as in 2.<strong>3</strong>.x indicates an experimental or + development kernel. Most users should run a recent kernel version from + the production series. The development kernels are primarily for people + doing kernel development. Others should consider using development + kernels only if they have an urgent need for some feature not yet + available in production kernels.</p> + </dd> + <dt>Keyed message digest</dt> + <dd>See <a href="#HMAC">HMAC</a>.</dd> + <dt>Key length</dt> + <dd>see <a href="#brute">brute force attack</a></dd> + <dt><a name="KLIPS">KLIPS</a></dt> + <dd><b>K</b>erne<b>l</b> <b>IP</b> <b>S</b>ecurity, the <a + href="#FreeSWAN">Linux FreeS/WAN</a> project's changes to the <a + href="#Linux">Linux</a> kernel to support the <a + href="#IPSEC">IPsec</a> protocols.</dd> + <dt><a name="L">L</a></dt> + <dt><a name="LDAP">LDAP</a></dt> + <dd><b>L</b>ightweight <b>D</b>irectory <b>A</b>ccess <b>P</b>rotocol, + defined in RFCs 1777 and 1778, a method of accessing information + stored in directories. LDAP is used by several <a href="#PKI">PKI</a> + implementations, often with X.501 directories and <a + href="#X509">X.509</a> certificates. It may also be used by <a + href="#IPSEC">IPsec</a> to obtain key certifications from those PKIs. + This is not yet implemented in <a href="#FreeSWAN">Linux + FreeS/WAN</a>.</dd> + <dt><a name="LIBDES">LIBDES</a></dt> + <dd>A publicly available library of <a href="#DES">DES</a> code, written + by Eric Young, which <a href="#FreeSWAN">Linux FreeS/WAN</a> uses in + both <a href="#KLIPS">KLIPS</a> and <a href="#Pluto">Pluto</a>.</dd> + <dt><a name="Linux">Linux</a></dt> + <dd>A freely available Unix-like operating system based on a kernel + originally written for the Intel 386 architecture by (then) student + Linus Torvalds. Once his 32-bit kernel was available, the <a + href="#GNU">GNU</a> utilities made it a usable system and contributions + from many others led to explosive growth. + <p>Today Linux is a complete Unix replacement available for several CPU + architectures -- Intel, DEC/Compaq Alpha, Power PC, both 32-bit SPARC + and the 64-bit UltraSPARC, SrongARM, . . . -- with support for multiple + CPUs on some architectures.</p> + <p><a href="#FreeSWAN">Linux FreeS/WAN</a> is intended to run on all + CPUs supported by Linux and is known to work on several. See our <a + href="compat.html#CPUs">compatibility</a> section for a list.</p> + </dd> + <dt><a name="FreeSWAN">Linux FreeS/WAN</a></dt> + <dd>Our implementation of the <a href="#IPSEC">IPsec</a> protocols, + intended to be freely redistributable source code with <a href="#GPL">a + GNU GPL license</a> and no constraints under US or other <a + href="politics.html#exlaw">export laws</a>. Linux FreeS/WAN is intended + to interoperate with other <a href="#IPSEC">IPsec</a> implementations. + The name is partly taken, with permission, from the <a + href="#SWAN">S/WAN</a> multi-vendor IPsec compatability effort. Linux + FreeS/WAN has two major components, <a href="#KLIPS">KLIPS</a> (KerneL + IPsec Support) and the <a href="#Pluto">Pluto</a> daemon which manages + the whole thing. + <p>See our <a href="ipsec.html">IPsec section</a> for more detail. For + the code see our <a href="http://freeswan.org"> primary site</a> or one + of the mirror sites on <a href="intro.html#mirrors">this list</a>.</p> + </dd> + <dt><a name="LSM">Linux Security Modules (LSM)</a></dt> + <dd>a project to create an interface in the Linux kernel that supports + plug-in modules for various security policies. + <p>This allows multiple security projects to take different approaches + to security enhancement without tying the kernel down to one particular + approach. As I understand the history, several projects were pressing + Linus to incorporate their changes, the various sets of changes were + incompatible, and his answer was more-or-less "a plague on all your + houses; I'll give you an interface, but I won't incorporate + anything".</p> + <p>It seems to be working. There is a fairly active <a + href="http://mail.wirex.com/mailman/listinfo/linux-security-module">LSM + mailing list</a>, and several projects are already using the + interface.</p> + </dd> + <dt>LSM</dt> + <dd>see <a href="#LSM">Linux Security Modules</a></dd> + <dt><a name="M">M</a></dt> + <dt><a name="list">Mailing list</a></dt> + <dd>The <a href="#FreeSWAN">Linux FreeS/WAN</a> project has several + public email lists for bug reports and software development + discussions. See our document on <a href="mail.html">mailing + lists</a>.</dd> + <dt><a name="middle">Man-in-the-middle attack</a></dt> + <dd>An <a href="#active">active attack</a> in which the attacker + impersonates each of the legitimate players in a protocol to the other. + <p>For example, if <a href="#alicebob">Alice and Bob</a> are + negotiating a key via the <a href="#DH">Diffie-Hellman</a> key + agreement, and are not using <a + href="#authentication">authentication</a> to be certain they are + talking to each other, then an attacker able to insert himself in the + communication path can deceive both players.</p> + <p>Call the attacker Mallory. For Bob, he pretends to be Alice. For + Alice, he pretends to be Bob. Two keys are then negotiated, + Alice-to-Mallory and Bob-to-Mallory. Alice and Bob each think the key + they have is Alice-to-Bob.</p> + <p>A message from Alice to Bob then goes to Mallory who decrypts it, + reads it and/or saves a copy, re-encrypts using the Bob-to-Mallory key + and sends it along to Bob. Bob decrypts successfully and sends a reply + which Mallory decrypts, reads, re-encrypts and forwards to Alice.</p> + <p>To make this attack effective, Mallory must</p> + <ul> + <li>subvert some part of the network in some way that lets him carry + out the deception<br> + possible targets: DNS, router, Alice or Bob's machine, mail server, + ...</li> + <li>beat any authentication mechanism Alice and Bob use<br> + strong authentication defeats the attack entirely; this is why <a + href="#IKE">IKE</a> requires authentication</li> + <li>work in real time, delivering messages without introducing a + delay large enough to alert the victims<br> + not hard if Alice and Bob are using email; quite difficult in some + situations.</li> + </ul> + <p>If he manages it, however, it is devastating. He not only gets to + read all the messages; he can alter messages, inject his own, forge + anything he likes, . . . In fact, he controls the communication + completely.</p> + </dd> + <dt><a name="mandatory">mandatory access control</a></dt> + <dd>access control mechanisims which are not settable by the user (see <a + href="#discretionary">discretionary access control</a>), but are + enforced by the system. + <p>For example, a document labelled "secret, zebra" might be readable + only by someone with secret clearance working on Project Zebra. + Ideally, the system will prevent any transfer outside those boundaries. + For example, even if you can read it, you should not be able to e-mail + it (unless the recipient is appropriately cleared) or print it (unless + certain printers are authorised for that classification).</p> + <p>Mandatory access control is a required feature for some levels of <a + href="#rainbow">Rainbow Book</a> or <a href="#cc">Common Criteria</a> + classification, but has not been widely used outside the military and + government. There is a good discussion of the issues in Anderson's <a + href="biblio.html#anderson">Security Engineering</a>.</p> + <p>The <a href="#SElinux">Security Enhanced Linux</a> project is adding + mandatory access control to Linux.</p> + </dd> + <dt><a name="manual">Manual keying</a></dt> + <dd>An IPsec mode in which the keys are provided by the administrator. In + FreeS/WAN, they are stored in /etc/ipsec.conf. The alternative, <a + href="#auto">automatic keying</a>, is preferred in most cases. See this + <a href="adv_config.html#man-auto">discussion</a>.</dd> + <dt><a name="MD4">MD4</a></dt> + <dd><a href="#digest">Message Digest Algorithm</a> Four from Ron Rivest + of <a href="#RSAco">RSA</a>. MD4 was widely used a few years ago, but + is now considered obsolete. It has been replaced by its descendants <a + href="#MD5">MD5</a> and <a href="#SHA">SHA</a>.</dd> + <dt><a name="MD5">MD5</a></dt> + <dd><a href="#digest">Message Digest Algorithm</a> Five from Ron Rivest + of <a href="#RSAco">RSA</a>, an improved variant of his <a + href="#MD4">MD4</a>. Like MD4, it produces a 128-bit hash. For details + see RFC 1321. + <p>MD5 is one of two message digest algorithms available in IPsec. The + other is <a href="#SHA">SHA</a>. SHA produces a longer hash and is + therefore more resistant to <a href="#birthday">birthday attacks</a>, + but this is not a concern for IPsec. The <a href="#HMAC">HMAC</a> + method used in IPsec is secure even if the underlying hash is not + particularly strong against this attack.</p> + <p>Hans Dobbertin found a weakness in MD5, and people often ask whether + this means MD5 is unsafe for IPsec. It doesn't. The IPsec RFCs discuss + Dobbertin's attack and conclude that it does not affect MD5 as used for + HMAC in IPsec.</p> + </dd> + <dt><a name="meet">Meet-in-the-middle attack</a></dt> + <dd>A divide-and-conquer attack which breaks a cipher into two parts, + works against each separately, and compares results. Probably the best + known example is an attack on double DES. This applies in principle to + any pair of block ciphers, e.g. to an encryption system using, say, + CAST-128 and Blowfish, but we will describe it for double DES. + <p>Double DES encryption and decryption can be written:</p> + <pre> C = E(k2,E(k1,P)) + P = D(k1,D(k2,C))</pre> + <p>Where C is ciphertext, P is plaintext, E is encryption, D is + decryption, k1 is one key, and k2 is the other key. If we know a P, C + pair, we can try and find the keys with a brute force attack, trying + all possible k1, k2 pairs. Since each key is 56 bits, there are + 2<sup>112</sup> such pairs and this attack is painfully inefficient.</p> + <p>The meet-in-the middle attack re-writes the equations to calculate a + middle value M:</p> + <pre> M = E(k1,P) + M = D(k2,C)</pre> + <p>Now we can try some large number of D(k2,C) decryptions with various + values of k2 and store the results in a table. Then start doing E(k1,P) + encryptions, checking each result to see if it is in the table.</p> + <p>With enough table space, this breaks double DES with + <nobr>2<sup>56</sup> + 2<sup>56</sup> = 2<sup>57</sup></nobr>work. + Against triple DES, you need <nobr>2<sup>56</sup> + 2<sup>112</sup> ~= + 2<sup>112</sup></nobr>.</p> + <p>The memory requirements for such attacks can be prohibitive, but + there is a whole body of research literature on methods of reducing + them.</p> + </dd> + <dt><a name="digest">Message Digest Algorithm</a></dt> + <dd>An algorithm which takes a message as input and produces a hash or + digest of it, a fixed-length set of bits which depend on the message + contents in some highly complex manner. Design criteria include making + it extremely difficult for anyone to counterfeit a digest or to change + a message without altering its digest. One essential property is <a + href="#collision">collision resistance</a>. The main applications are + in message <a href="#authentication">authentication</a> and <a + href="#signature">digital signature</a> schemes. Widely used algorithms + include <a href="#MD5">MD5</a> and <a href="#SHA">SHA</a>. In IPsec, + message digests are used for <a href="#HMAC">HMAC</a> authentication of + packets.</dd> + <dt><a name="MTU">MTU</a></dt> + <dd><strong>M</strong>aximum <strong>T</strong>ransmission + <strong>U</strong>nit, the largest size of packet that can be sent over + a link. This is determined by the underlying network, but must be taken + account of at the IP level. + <p>IP packets, which can be up to 64K bytes each, must be packaged into + lower-level packets of the appropriate size for the underlying + network(s) and re-assembled on the other end. When a packet must pass + over multiple networks, each with its own MTU, and many of the MTUs are + unknown to the sender, this becomes a fairly complex problem. See <a + href="#pathMTU">path MTU discovery</a> for details.</p> + <p>Often the MTU is a few hundred bytes on serial links and 1500 on + Ethernet. There are, however, serial link protocols which use a larger + MTU to avoid fragmentation at the ethernet/serial boundary, and newer + (especially gigabit) Ethernet networks sometimes support much larger + packets because these are more efficient in some applications.</p> + </dd> + <dt><a name="N">N</a></dt> + <dt><a name="NAI">NAI</a></dt> + <dd><a href="http://www.nai.com">Network Associates</a>, a conglomerate + formed from <a href="#PGPI">PGP Inc.</a>, TIS (Trusted Information + Systems, a firewall vendor) and McAfee anti-virus products. Among other + things, they offer an IPsec-based VPN product.</dd> + <dt><a name="NAT.gloss">NAT</a></dt> + <dd><b>N</b>etwork <b>A</b>ddress <b>T</b>ranslation, a process by which + firewall machines may change the addresses on packets as they go + through. For discussion, see our <a + href="background.html#nat.background">background</a> section.</dd> + <dt><a name="NIST">NIST</a></dt> + <dd>The US <a href="http://www.nist.gov"> National Institute of Standards + and Technology</a>, responsible for <a href="#FIPS">FIPS standards</a> + including <a href="#DES">DES</a> and its replacement, <a + href="#AES">AES</a>.</dd> + <dt><a name="nonce">Nonce</a></dt> + <dd>A <a href="#random">random</a> value used in an <a + href="#authentication">authentication</a> protocol.</dd> + <dt></dt> + <dt><a name="non-routable">Non-routable IP address</a></dt> + <dd>An IP address not normally allowed in the "to" or "from" IP address + field header of IP packets. + <p>Almost invariably, the phrase "non-routable address" means one of + the addresses reserved by RFC 1918 for private networks:</p> + <ul> + <li>10.anything</li> + <li>172.x.anything with 16 <= x <= 31</li> + <li>192.168.anything</li> + </ul> + <p>These addresses are commonly used on private networks, e.g. behind a + Linux machines doing <a href="#masq">IP masquerade</a>. Machines within + the private network can address each other with these addresses. All + packets going outside that network, however, have these addresses + replaced before they reach the Internet.</p> + <p>If any packets using these addresses do leak out, they do not go + far. Most routers automatically discard all such packets.</p> + <p>Various other addresses -- the 127.0.0.0/8 block reserved for local + use, 0.0.0.0, various broadcast and network addresses -- cannot be + routed over the Internet, but are not normally included in the meaning + when the phrase "non-routable address" is used.</p> + </dd> + <dt><a name="NSA">NSA</a></dt> + <dd>The US <a href="http://www.nsa.gov"> National Security Agency</a>, + the American organisation for <a href="#SIGINT">signals + intelligence</a>, the protection of US government messages and the + interception and analysis of other messages. For details, see Bamford's + <a href="biblio.html#puzzle">"The Puzzle Palace"</a>. + <p>Some <a + href="http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/index.html">history + of NSA</a> documents were declassified in response to a FOIA (Freedom + of Information Act) request.</p> + </dd> + <dt><a name="O">O</a></dt> + <dt><a name="oakley">Oakley</a></dt> + <dd>A key determination protocol, defined in RFC 2412.</dd> + <dt>Oakley groups</dt> + <dd>The groups used as the basis of <a href="#DH">Diffie-Hellman</a> key + exchange in the Oakley protocol, and in <a href="#IKE">IKE</a>. Four + were defined in the original RFC, and a fifth has been <a + href="http://www.lounge.org/ike_doi_errata.html">added since</a>. + <p>Linux FreeS/WAN currently supports the three groups based on finite + fields modulo a prime (Groups 1, 2 and 5) and does not support the + elliptic curve groups (3 and 4). For a description of the difference of + the types, see <a href="#dlog">discrete logarithms</a>.</p> + </dd> + <dt><a name="OTP">One time pad</a></dt> + <dd>A cipher in which the key is: + <ul> + <li>as long as the total set of messages to be enciphered</li> + <li>absolutely <a href="#random">random</a></li> + <li>never re-used</li> + </ul> + <p>Given those three conditions, it can easily be proved that the + cipher is perfectly secure, in the sense that an attacker with + intercepted message in hand has no better chance of guessing the + message than an attacker who has not intercepted the message and only + knows the message length. No such proof exists for any other cipher.</p> + <p>There are, however, several problems with this "perfect" cipher.</p> + <p>First, it is <strong>wildly impractical</strong> for most + applications. Key management is at best difficult, often completely + impossible.</p> + <p>Second, it is <strong>extremely fragile</strong>. Small changes + which violate the conditions listed above do not just weaken the cipher + liitle. Quite often they destroy its security completely.</p> + <ul> + <li>Re-using the pad weakens the cipher to the point where it can be + broken with pencil and paper. With a computer, the attack is + trivially easy.</li> + <li>Using <em>anything</em> less than truly <a + href="#random">random</a> numbers <em>completely</em> invalidates + the security proof.</li> + <li>In particular, using computer-generated pseudo-random numbers may + give an extremely weak cipher. It might also produce a good stream + cipher, if the pseudo-random generator is both well-designed and + properely seeded.</li> + </ul> + <p>Marketing claims about the "unbreakable" security of various + products which somewhat resemble one-time pads are common. Such claims + are one of the surest signs of cryptographic <a href="#snake">snake + oil</a>; most systems marketed with such claims are worthless.</p> + <p>Finally, even if the system is implemented and used correctly, it is + <strong>highly vulnerable to a substitution attack</strong>. If an + attacker knows some plaintext and has an intercepted message, he can + discover the pad.</p> + <ul> + <li>This does not matter if the attacker is just a <a + href="#passive">passive</a> eavesdropper. It gives him no plaintext + he didn't already know and we don't care that he learns a pad which + we will never re-use.</li> + <li>However, an <a href="#active">active</a> attacker who knows the + plaintext can recover the pad, then use it to encode with whatever + he chooses. If he can get his version delivered instead of yours, + this may be a disaster. If you send "attack at dawn", the delivered + message can be anything the same length -- perhaps "retreat to + east" or "shoot generals".</li> + <li>An active attacker with only a reasonable guess at the plaintext + can try the same attack. If the guess is correct, this works and + the attacker's bogus message is delivered. If the guess is wrong, a + garbled message is delivered.</li> + </ul> + <p>In general then, despite its theoretical perfection, the + one-time-pad has very limited practical application.</p> + <p>See also the <a href="http://pubweb.nfr.net/~mjr/pubs/otpfaq/">one + time pad FAQ</a>.</p> + </dd> + <dt><a name="carpediem">Opportunistic encryption (OE)</a></dt> + <dd>A situation in which any two IPsec-aware machines can secure their + communications, without a pre-shared secret and without a common <a + href="#PKI">PKI</a> or previous exchange of public keys. This is one of + the goals of the Linux FreeS/WAN project, discussed in our <a + href="intro.html#goals">introduction</a> section. + <p>Setting up for opportunistic encryption is described in our <a + href="quickstart.html#quickstart">quickstart</a> document.</p> + </dd> + <dt><a name="responder">Opportunistic responder</a></dt> + <dd>A host which accepts, but does not initiate, requests for + <A HREF="#carpediem">opportunistic encryption</A> (OE). + An opportunistic responder has enabled OE in its + <A HREF="#passive.OE">passive</A> form (pOE) only. + A web server or file server may be usefully set up as an opportunistic + responder. + <p>Configuring passive OE is described in our + <a href="policygroups.html#policygroups">policy groups</a> document.</p> + </dd> + <dt><a name="orange">Orange book</a></dt> + <dd>the most basic and best known of the US government's <a + href="#rainbow">Rainbow Book</a> series of computer security + standards.</dd> + <dt><a name="P">P</a></dt> + <dt><a name="P1363">P1363 standard</a></dt> + <dd>An <a href="#IEEE">IEEE</a> standard for public key cryptography. <a + href="http://grouper.ieee.org/groups/1363">Web page</a>.</dd> + <dt><a name="pOE">pOE</a></dt> + <dd>See <a href="#passive.OE">Passive opportunistic encryption</a>.</dd> + <dt><a name="passive">Passive attack</a></dt> + <dd>An attack in which the attacker only eavesdrops and attempts to + analyse intercepted messages, as opposed to an <a href="#active">active + attack</a> in which he diverts messages or generates his own.</dd> + <dt><a name="passive.OE">Passive opportunistic encryption (pOE)</a></dt> + <dd>A form of + <A HREF="#carpediem">opportunistic encryption</A> (OE) in which the + host will accept opportunistic connection requests, but will not + initiate such requests. A host which runs OE in its passive form only + is known as an <A HREF="#responder">opportunistic responder</A>. + <p>Configuring passive OE is described in our + <a href="policygroups.html#policygroups">policy groups</a> document.</p> + </dd> + <dt><a name="pathMTU">Path MTU discovery</a></dt> + <dd>The process of discovering the largest packet size which all links on + a path can handle without fragmentation -- that is, without any router + having to break the packet up into smaller pieces to match the <a + href="#MTU">MTU</a> of its outgoing link. + <p>This is done as follows:</p> + <ul> + <li>originator sends the largest packets allowed by <a + href="#MTU">MTU</a> of the first link, setting the DF + (<strong>d</strong>on't <strong>f</strong>ragment) bit in the + packet header</li> + <li>any router which cannot send the packet on (outgoing MTU is too + small for it, and DF prevents fragmenting it to match) sends back + an <a href="#ICMP.gloss">ICMP</a> packet reporting the problem</li> + <li>originator looks at ICMP message and tries a smaller size</li> + <li>eventually, you settle on a size that can pass all routers</li> + <li>thereafter, originator just sends that size and no-one has to + fragment</li> + </ul> + <p>Since this requires co-operation of many systems, and since the next + packet may travel a different path, this is one of the trickier areas + of IP programming. Bugs that have shown up over the years have + included:</p> + <ul> + <li>malformed ICMP messages</li> + <li>hosts that ignore or mishandle these ICMP messages</li> + <li>firewalls blocking the ICMP messages so host does not see + them</li> + </ul> + <p>Since IPsec adds a header, it increases packet size and may require + fragmentation even where incoming and outgoing MTU are equal.</p> + </dd> + <dt><a name="PFS">Perfect forward secrecy (PFS)</a></dt> + <dd>A property of systems such as <a href="#DH">Diffie-Hellman</a> key + exchange which use a long-term key (such as the shared secret in IKE) + and generate short-term keys as required. If an attacker who acquires + the long-term key <em>provably</em> can + <ul> + <li><em>neither</em> read previous messages which he may have + archived</li> + <li><em>nor</em> read future messages without performing additional + successful attacks</li> + </ul> + <p>then the system has PFS. The attacker needs the short-term keys in + order to read the trafiic and merely having the long-term key does not + allow him to infer those. Of course, it may allow him to conduct + another attack (such as <a href="#middle">man-in-the-middle</a>) which + gives him some short-term keys, but he does not automatically get them + just by acquiring the long-term key.</p> + <p>See also +<a href="http://sandelman.ottawa.on.ca/ipsec/1996/08/msg00123.html">Phil +Karn's definition</a>. + </dd> + <dt>PFS</dt> + <dd>see Perfect Forward Secrecy</dd> + <dt><a name="PGP">PGP</a></dt> + <dd><b>P</b>retty <b>G</b>ood <b>P</b>rivacy, a personal encryption + system for email based on public key technology, written by Phil + Zimmerman. + <p>The 2.xx versions of PGP used the <a href="#RSA">RSA</a> public key + algorithm and used <a href="#IDEA">IDEA</a> as the symmetric cipher. + These versions are described in RFC 1991 and in <a + href="#PGP">Garfinkel's book</a>. Since version 5, the products from <a + href="#PGPI">PGP Inc</a>. have used <a href="#DH">Diffie-Hellman</a> + public key methods and <a href="#CAST128">CAST-128</a> symmetric + encryption. These can verify signatures from the 2.xx versions, but + cannot exchange encryted messages with them.</p> + <p>An <a href="#IETF">IETF</a> working group has issued RFC 2440 for an + "Open PGP" standard, similar to the 5.x versions. PGP Inc. staff were + among the authors. A free <a href="#GPG">Gnu Privacy Guard</a> based on + that standard is now available.</p> + <p>For more information on PGP, including how to obtain it, see our + cryptography <a href="web.html#tools">links</a>.</p> + </dd> + <dt><a name="PGPI">PGP Inc.</a></dt> + <dd>A company founded by Zimmerman, the author of <a href="#PGP">PGP</a>, + now a division of <a href="#NAI">NAI</a>. See the <a + href="http://www.pgp.com">corporate website</a>. Zimmerman left in + 2001, and early in 2002 NAI announced that they would no longer sell + PGP.. + <p>Versions 6.5 and later of the PGP product include PGPnet, an IPsec + client for Macintosh or for Windows 95/98/NT. See our <a + href="interop.html#pgpnet">interoperation documen</a>t.</p> + </dd> + <dt><a name="photuris">Photuris</a></dt> + <dd>Another key negotiation protocol, an alternative to <a + href="#IKE">IKE</a>, described in RFCs 2522 and 2523.</dd> + <dt><a name="PPP">PPP</a></dt> + <dd><b>P</b>oint-to-<b>P</b>oint <b>P</b>rotocol, originally a method of + connecting over modems or serial lines, but see also PPPoE.</dd> + <dt><a name="PPPoE">PPPoE</a></dt> + <dd><b>PPP</b> <b>o</b>ver <b>E</b>thernet, a somewhat odd protocol that + makes Ethernet look like a point-to-point serial link. It is widely + used for cable or ADSL Internet services, apparently mainly because it + lets the providers use access control and address assignmment + mechanisms developed for dialup networks. <a + href="http://www.roaringpenguin.com">Roaring Penguin</a> provide a + widely used Linux implementation.</dd> + <dt><a name="PPTP">PPTP</a></dt> + <dd><b>P</b>oint-to-<b>P</b>oint <b>T</b>unneling <b>P</b>rotocol, used + in some Microsoft VPN implementations. Papers discussing weaknesses in + it are on <a + href="http://www.counterpane.com/publish.html">counterpane.com</a>. It + is now largely obsolete, replaced by L2TP.</dd> + <dt><a name="PKI">PKI</a></dt> + <dd><b>P</b>ublic <b>K</b>ey <b>I</b>nfrastructure, the things an + organisation or community needs to set up in order to make <a + href="#public">public key</a> cryptographic technology a standard part + of their operating procedures. + <p>There are several PKI products on the market. Typically they use a + hierarchy of <a href="#CA">Certification Authorities (CAs)</a>. Often + they use <a href="#LDAP">LDAP</a> access to <a href="#X509">X.509</a> + directories to implement this.</p> + <p>See <a href="#web">Web of Trust</a> for a different sort of + infrastructure.</p> + </dd> + <dt><a name="PKIX">PKIX</a></dt> + <dd><b>PKI</b> e<b>X</b>change, an <a href="#IETF">IETF</a> standard that + allows <a href="#PKI">PKI</a>s to talk to each other. + <p>This is required, for example, when users of a corporate PKI need to + communicate with people at client, supplier or government + organisations, any of which may have a different PKI in place. I should + be able to talk to you securely whenever:</p> + <ul> + <li>your organisation and mine each have a PKI in place</li> + <li>you and I are each set up to use those PKIs</li> + <li>the two PKIs speak PKIX</li> + <li>the configuration allows the conversation</li> + </ul> + <p>At time of writing (March 1999), this is not yet widely implemented + but is under quite active development by several groups.</p> + </dd> + <dt><a name="plaintext">Plaintext</a></dt> + <dd>The unencrypted input to a cipher, as opposed to the encrypted <a + href="#ciphertext">ciphertext</a> output.</dd> + <dt><a name="Pluto">Pluto</a></dt> + <dd>The <a href="#FreeSWAN">Linux FreeS/WAN</a> daemon which handles key + exchange via the <a href="#IKE">IKE</a> protocol, connection + negotiation, and other higher-level tasks. Pluto calls the <a + href="#KLIPS">KLIPS</a> kernel code as required. For details, see the + manual page ipsec_pluto(8).</dd> + <dt><a name="public">Public Key Cryptography</a></dt> + <dd>In public key cryptography, keys are created in matched pairs. + Encrypt with one half of a pair and only the matching other half can + decrypt it. This contrasts with <a href="#symmetric">symmetric or + secret key cryptography</a> in which a single key known to both parties + is used for both encryption and decryption. + <p>One half of each pair, called the public key, is made public. The + other half, called the private key, is kept secret. Messages can then + be sent by anyone who knows the public key to the holder of the private + key. Encrypt with the public key and you know that only someone with + the matching private key can decrypt.</p> + <p>Public key techniques can be used to create <a + href="#signature">digital signatures</a> and to deal with key + management issues, perhaps the hardest part of effective deployment of + <a href="#symmetric"> symmetric ciphers</a>. The resulting <a + href="#hybrid">hybrid cryptosystems</a> use public key methods to + manage keys for symmetric ciphers.</p> + <p>Many organisations are currently creating <a href="#PKI">PKIs, + public key infrastructures</a> to make these benefits widely + available.</p> + </dd> + <dt>Public Key Infrastructure</dt> + <dd>see <a href="#PKI">PKI</a></dd> + <dt><a name="Q">Q</a></dt> + <dt><a name="R">R</a></dt> + <dt><a name="rainbow">Rainbow books</a></dt> + <dd>A set of US government standards for evaluation of "trusted computer + systems", of which the best known was the <a href="#orange">Orange + Book</a>. One fairly often hears references to "C2 security" or a + product "evaluated at B1". The Rainbow books define the standards + referred to in those comments. + <p>See this <a href="http://www.fas.org/irp/nsa/rainbow.htm">reference + page</a>.</p> + <p>The Rainbow books are now mainly obsolete, replaced by the + international <a href="#cc">Common Criteria</a> standards.</p> + </dd> + <dt><a name="random">Random</a></dt> + <dd>A remarkably tricky term, far too much so for me to attempt a + definition here. Quite a few cryptosystems have been broken via attacks + on weak random number generators, even when the rest of the system was + sound. + <p>See <a + href="http://nis.nsf.net/internet/documents/rfc/rfc1750.txt">RFC + 1750</a> for the theory.</p> + <p>See the manual pages for <a + href="manpage.d/ipsec_ranbits.8.html">ipsec_ranbits(8)</a> and + ipsec_prng(3) for more on FreeS/WAN's use of randomness. Both depend on + the random(4) device driver..</p> + <p>A couple of years ago, there was extensive mailing list discussion + (archived <a + href="http://www.openpgp.net/random/index.html">here</a>)of Linux + /dev/random and FreeS/WAN. Since then, the design of the random(4) + driver has changed considerably. Linux 2.4 kernels have the new + driver..</p> + </dd> + <dt>Raptor</dt> + <dd>A firewall product for Windows NT offerring IPsec-based VPN services. + Linux FreeS/WAN interoperates with Raptor; see our <a + href="interop.html#Raptor">interop</a> document for details. Raptor + have recently merged with Axent.</dd> + <dt><a name="RC4">RC4</a></dt> + <dd><b>R</b>ivest <b>C</b>ipher four, designed by Ron Rivest of <a + href="#RSAco">RSA</a> and widely used. Believed highly secure with + adequate key length, but often implemented with inadequate key length + to comply with export restrictions.</dd> + <dt><a name="RC6">RC6</a></dt> + <dd><b>R</b>ivest <b>C</b>ipher six, <a href="#RSAco">RSA</a>'s <a + href="#AES">AES</a> candidate cipher.</dd> + <dt><a name="replay">Replay attack</a></dt> + <dd>An attack in which the attacker records data and later replays it in + an attempt to deceive the recipient.</dd> + <dt><a name="reverse">Reverse map</a></dt> + <dd>In <a href="#DNS">DNS</a>, a table where IP addresses can be used as + the key for lookups which return a system name and/or other + information.</dd> + <dt>RFC</dt> + <dd><b>R</b>equest <b>F</b>or <b>C</b>omments, an Internet document. Some + RFCs are just informative. Others are standards. + <p>Our list of <a href="#IPSEC">IPsec</a> and other security-related + RFCs is <a href="rfc.html#RFC">here</a>, along with information on + methods of obtaining them.</p> + </dd> + <dt><a name="rijndael">Rijndael</a></dt> + <dd>a <a href="#block">block cipher</a> designed by two Belgian + cryptographers, winner of the US government's <a href="#AES">AES</a> + contest to pick a replacement for <a href="#DES">DES</a>. See the <a + href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael">Rijndael home + page</a>.</dd> + <dt><a name="RIPEMD">RIPEMD</a></dt> + <dd>A <a href="#digest">message digest</a> algorithm. The current version + is RIPEMD-160 which gives a 160-bit hash.</dd> + <dt><a name="rootCA">Root CA</a></dt> + <dd>The top level <a href="#CA">Certification Authority</a> in a hierachy + of such authorities.</dd> + <dt><a name="routable">Routable IP address</a></dt> + <dd>Most IP addresses can be used as "to" and "from" addresses in packet + headers. These are the routable addresses; we expect routing to be + possible for them. If we send a packet to one of them, we expect (in + most cases; there are various complications) that it will be delivered + if the address is in use and will cause an <a + href="#ICMP.gloss">ICMP</a> error packet to come back to us if not. + <p>There are also several classes of <a + href="#non-routable">non-routable</a> IP addresses.</p> + </dd> + <dt><a name="RSA">RSA algorithm</a></dt> + <dd><b>R</b>ivest <b>S</b>hamir <b>A</b>dleman <a href="#public">public + key</a> algorithm, named for its three inventors. It is widely used and + likely to become moreso since it became free of patent encumbrances in + September 2000. + <p>RSA can be used to provide either <a + href="#encryption">encryption</a> or <a href="#signature">digital + signatures</a>. In IPsec, it is used only for signatures. These provide + gateway-to-gateway <a href="#authentication">authentication</a> for <a + href="#IKE">IKE </a>negotiations.</p> + <p>For a full explanation of the algorithm, consult one of the standard + references such as <a href="biblio.html#schneier">Applied + Cryptography</a>. A simple explanation is:</p> + <p>The great 17th century French mathematician <a + href="http://www-groups.dcs.st-andrews.ac.uk/~history/Mathematicians/Fermat.html">Fermat</a> + proved that,</p> + <p>for any prime p and number x, 0 <= x < p:</p> + <pre> x^p == x modulo p + x^(p-1) == 1 modulo p, non-zero x + </pre> + <p>From this it follows that if we have a pair of primes p, q and two + numbers e, d such that:</p> + <pre> ed == 1 modulo lcm( p-1, q-1) + </pre> + where lcm() is least common multiple, then<br> + for all x, 0 <= x < pq: + <pre> x^ed == x modulo pq + </pre> + <p>So we construct such as set of numbers p, q, e, d and publish the + product N=pq and e as the public key. Using c for <a + href="#ciphertext">ciphertext</a> and i for the input <a + href="#plaintext">plaintext</a>, encryption is then:</p> + <pre> c = i^e modulo N + </pre> + <p>An attacker cannot deduce i from the cyphertext c, short of either + factoring N or solving the <a href="#dlog">discrete logarithm</a> + problem for this field. If p, q are large primes (hundreds or thousands + of bits) no efficient solution to either problem is known.</p> + <p>The receiver, knowing the private key (N and d), can readily recover + the plaintext p since:</p> + <pre> c^d == (i^e)^d modulo N + == i^ed modulo N + == i modulo N + </pre> + <p>This gives an effective public key technique, with only a couple of + problems. It uses a good deal of computer time, since calculations with + large integers are not cheap, and there is no proof it is necessarily + secure since no-one has proven either factoring or discrete log cannot + be done efficiently. Quite a few good mathematicians have tried both + problems, and no-one has announced success, but there is no proof they + are insoluble.</p> + </dd> + <dt><a name="RSAco">RSA Data Security</a></dt> + <dd>A company founded by the inventors of the <a href="#RSA">RSA</a> + public key algorithm.</dd> + <dt><a name="S">S</a></dt> + <dt><a name="SA">SA</a></dt> + <dd><b>S</b>ecurity <b>A</b>ssociation, the channel negotiated by the + higher levels of an <a href="#IPSEC">IPsec</a> implementation (<a + href="#IKE">IKE</a>) and used by the lower (<a href="#ESP">ESP</a> and + <a href="#AH">AH</a>). SAs are unidirectional; you need a pair of them + for two-way communication. + <p>An SA is defined by three things -- the destination, the protocol + (<a href="#AH">AH</a> or<a href="#ESP">ESP</a>) and the <a + href="SPI">SPI</a>, security parameters index. It is used as an index + to look up other things such as session keys and intialisation + vectors.</p> + <p>For more detail, see our section on <a href="ipsec.html">IPsec</a> + and/or RFC 2401.</p> + </dd> + <dt><a name="SElinux">SE Linux</a></dt> + <dd><strong>S</strong>ecurity <strong>E</strong>nhanced Linux, an <a + href="#NSA">NSA</a>-funded project to add <a + href="#mandatory">mandatory access control</a> to Linux. See the <a + href="http://www.nsa.gov/selinux">project home page</a>. + <p>According to their web pages, this work will include extending + mandatory access controls to IPsec tunnels.</p> + <p>Recent versions of SE Linux code use the <a href="#LSM">Linux + Security Module</a> interface.</p> + </dd> + <dt><a name="SDNS">Secure DNS</a></dt> + <dd>A version of the <a href="#DNS">DNS or Domain Name Service</a> + enhanced with authentication services. This is being designed by the <a + href="#IETF">IETF</a> DNS security <a + href="http://www.ietf.org/ids.by.wg/dnssec.html">working group</a>. + Check the <a href="http://www.isc.org/bind.html">Internet Software + Consortium</a> for information on implementation progress and for the + latest version of <a href="#BIND">BIND</a>. Another site has <a + href="http://www.toad.com/~dnssec">more information</a>. + <p><a href="#IPSEC">IPsec</a> can use this plus <a + href="#DH">Diffie-Hellman key exchange</a> to bootstrap itself. This + allows <a href="#carpediem">opportunistic encryption</a>. Any pair of + machines which can authenticate each other via DNS can communicate + securely, without either a pre-existing shared secret or a shared <a + href="#PKI">PKI</a>.</p> + </dd> + <dt>Secret key cryptography</dt> + <dd>See <a href="#symmetric">symmetric cryptography</a></dd> + <dt>Security Association</dt> + <dd>see <a href="#SA">SA</a></dd> + <dt>Security Enhanced Linux</dt> + <dd>see <a href="#SElinux">SE Linux</a></dd> + <dt><a name="sequence">Sequence number</a></dt> + <dd>A number added to a packet or message which indicates its position in + a sequence of packets or messages. This provides some security against + <a href="#replay">replay attacks</a>. + <p>For <a href="#auto">automatic keying</a> mode, the <a + href="#IPSEC">IPsec</a> RFCs require that the sender generate sequence + numbers for each packet, but leave it optional whether the receiver + does anything with them.</p> + </dd> + <dt><a name="SHA">SHA</a></dt> + <dt>SHA-1</dt> + <dd><b>S</b>ecure <b>H</b>ash <b>A</b>lgorithm, a <a + href="#digest">message digest algorithm</a> developed by the <a + href="#NSA">NSA</a> for use in the Digital Signature standard, <a + href="#FIPS">FIPS</a> number 186 from <a href="#NIST">NIST</a>. SHA is + an improved variant of <a href="#MD4">MD4</a> producing a 160-bit hash. + <p>SHA is one of two message digest algorithms available in IPsec. The + other is <a href="#MD5">MD5</a>. Some people do not trust SHA because + it was developed by the <a href="#NSA">NSA</a>. There is, as far as we + know, no cryptographic evidence that SHA is untrustworthy, but this + does not prevent that view from being strongly held.</p> + <p>The NSA made one small change after the release of the original SHA. + They did not give reasons. Iit may be a defense against some attack + they found and do not wish to disclose. Technically the modified + algorithm should be called SHA-1, but since it has replaced the + original algorithm in nearly all applications, it is generally just + referred to as SHA..</p> + </dd> + <dt><a name="SHA-256">SHA-256</a></dt> + <dt>SHA-384</dt> + <dt>SHA-512</dt> + <dd>Newer variants of SHA designed to match the strength of the 128, 192 + and 256-bit keys of <a href="#AES">AES</a>. The work to break an + encryption algorithm's strength by <a href="#brute">brute force</a> is + 2 + <math xmlns="http://www.w3.org/1998/Math/MathML"> + <msup> + <mi>keylength</mi> + </msup> + </math> + operations but a <a href="birthday">birthday attack </a>on a hash + needs only 2 + <math xmlns="http://www.w3.org/1998/Math/MathML"> + <msup> + <mrow> + <mi>hashlength</mi> + <mo>/</mo> + <mn>2</mn> + </mrow> + </msup> + </math> + , so as a general rule you need a hash twice the size of the key to + get similar strength. SHA-256, SHA-384 and SHA-512 are designed to + match the 128, 192 and 256-bit key sizes of AES, respectively.</dd> + <dt><a name="SIGINT">Signals intelligence (SIGINT)</a></dt> + <dd>Activities of government agencies from various nations aimed at + protecting their own communications and reading those of others. + Cryptography, cryptanalysis, wiretapping, interception and monitoring + of various sorts of signals. The players include the American <a + href="#NSA">NSA</a>, British <a href="#GCHQ">GCHQ</a> and Canadian <a + href="#CSE">CSE</a>.</dd> + <dt><a name="SKIP">SKIP</a></dt> + <dd><b>S</b>imple <b>K</b>ey management for <b>I</b>nternet + <b>P</b>rotocols, an alternative to <a href="#IKE">IKE</a> developed by + Sun and being marketed by their <a + href="http://skip.incog.com">Internet Commerce Group</a>.</dd> + <dt><a name="snake">Snake oil</a></dt> + <dd>Bogus cryptography. See the <a + href="http://www.interhack.net/people/cmcurtin/snake-oil-faq.html"> + Snake Oil FAQ</a> or <a + href="http://www.counterpane.com/crypto-gram-9902.html#snakeoil">this + paper</a> by Schneier.</dd> + <dt><a name="SPI">SPI</a></dt> + <dd><b>S</b>ecurity <b>P</b>arameter <b>I</b>ndex, an index used within + <a href="#IPSEC">IPsec</a> to keep connections distinct. A <a + href="#SA">Security Association (SA)</a> is defined by destination, + protocol and SPI. Without the SPI, two connections to the same gateway + using the same protocol could not be distinguished. + <p>For more detail, see our <a href="ipsec.html">IPsec</a> section + and/or RFC 2401.</p> + </dd> + <dt><a name="SSH">SSH</a></dt> + <dd><b>S</b>ecure <b>SH</b>ell, an encrypting replacement for the + insecure Berkeley commands whose names begin with "r" for "remote": + rsh, rlogin, etc. + <p>For more information on SSH, including how to obtain it, see our + cryptography <a href="web.html#tools">links</a>.</p> + </dd> + <dt><a name="SSHco">SSH Communications Security</a></dt> + <dd>A company founded by the authors of <a href="#SSH">SSH</a>. Offices + are in <a href="http://www.ssh.fi">Finland</a> and <a + href="http://www.ipsec.com">California</a>. They have a toolkit for + developers of IPsec applications.</dd> + <dt><a name="SSL">SSL</a></dt> + <dd><a href="http://home.netscape.com/eng/ssl3">Secure Sockets Layer</a>, + a set of encryption and authentication services for web browsers, + developed by Netscape. Widely used in Internet commerce. Also known as + <a href="#TLS">TLS</a>.</dd> + <dt>SSLeay</dt> + <dd>A free implementation of <a href="#SSL">SSL</a> by Eric Young (eay) + and others. Developed in Australia; not subject to US export + controls.</dd> + <dt><a name="static">static IP address</a></dt> + <dd>an IP adddress which is pre-set on the machine itself, as opposed to + a <a href="#dynamic">dynamic address</a> which is assigned by a <a + href="#DHCP">DHCP</a> server or obtained as part of the process of + establishing a <a href="#PPP">PPP</a> or <a href="#PPPoE">PPPoE</a> + connection</dd> + <dt><a name="stream">Stream cipher</a></dt> + <dd>A <a href="#symmetric">symmetric cipher</a> which produces a stream + of output which can be combined (often using XOR or bytewise addition) + with the plaintext to produce ciphertext. Contrasts with <a + href="#block">block cipher</a>. + <p><a href="#IPSEC">IPsec</a> does not use stream ciphers. Their main + application is link-level encryption, for example of voice, video or + data streams on a wire or a radio signal.</p> + </dd> + <dt><a name="subnet">subnet</a></dt> + <dd>A group of IP addresses which are logically one network, typically + (but not always) assigned to a group of physically connected machines. + The range of addresses in a subnet is described using a subnet mask. + See next entry.</dd> + <dt>subnet mask</dt> + <dd>A method of indicating the addresses included in a subnet. Here are + two equivalent examples: + <ul> + <li>101.101.101.0/24</li> + <li>101.101.101.0 with mask 255.255.255.0</li> + </ul> + <p>The '24' is shorthand for a mask with the top 24 bits one and the + rest zero. This is exactly the same as 255.255.255.0 which has three + all-ones bytes and one all-zeros byte.</p> + <p>These indicate that, for this range of addresses, the top 24 bits + are to be treated as naming a network (often referred to as "the + 101.101.101.0/24 subnet") while most combinations of the low 8 bits can + be used to designate machines on that network. Two addresses are + reserved; 101.101.101.0 refers to the subnet rather than a specific + machine while 101.101.101.255 is a broadcast address. 1 to 254 are + available for machines.</p> + <p>It is common to find subnets arranged in a hierarchy. For example, a + large company might have a /16 subnet and allocate /24 subnets within + that to departments. An ISP might have a large subnet and allocate /26 + subnets (64 addresses, 62 usable) to business customers and /29 subnets + (8 addresses, 6 usable) to residential clients.</p> + </dd> + <dt><a name="SWAN">S/WAN</a></dt> + <dd>Secure Wide Area Network, a project involving <a href="#RSAco">RSA + Data Security</a> and a number of other companies. The goal was to + ensure that all their <a href="#IPSEC">IPsec</a> implementations would + interoperate so that their customers can communicate with each other + securely.</dd> + <dt><a name="symmetric">Symmetric cryptography</a></dt> + <dd>Symmetric cryptography, also referred to as conventional or secret + key cryptography, relies on a <em>shared secret key</em>, identical for + sender and receiver. Sender encrypts with that key, receiver decrypts + with it. The idea is that an eavesdropper without the key be unable to + read the messages. There are two main types of symmetric cipher, <a + href="#block">block ciphers</a> and <a href="#stream">stream + ciphers</a>. + <p>Symmetric cryptography contrasts with <a href="#public">public + key</a> or asymmetric systems where the two players use different + keys.</p> + <p>The great difficulty in symmetric cryptography is, of course, key + management. Sender and receiver <em>must</em> have identical keys and + those keys <em>must</em> be kept secret from everyone else. Not too + much of a problem if only two people are involved and they can + conveniently meet privately or employ a trusted courier. Quite a + problem, though, in other circumstances.</p> + <p>It gets much worse if there are many people. An application might be + written to use only one key for communication among 100 people, for + example, but there would be serious problems. Do you actually trust all + of them that much? Do they trust each other that much? Should they? + What is at risk if that key is compromised? How are you going to + distribute that key to everyone without risking its secrecy? What do + you do when one of them leaves the company? Will you even know?</p> + <p>On the other hand, if you need unique keys for every possible + connection between a group of 100, then each user must have 99 keys. + You need either 99*100/2 = 4950 <em>secure</em> key exchanges between + users or a central authority that <em>securely</em> distributes 100 key + packets, each with a different set of 99 keys.</p> + <p>Either of these is possible, though tricky, for 100 users. Either + becomes an administrative nightmare for larger numbers. Moreover, keys + <em>must</em> be changed regularly, so the problem of key distribution + comes up again and again. If you use the same key for many messages + then an attacker has more text to work with in an attempt to crack that + key. Moreover, one successful crack will give him or her the text of + all those messages.</p> + <p>In short, the <em>hardest part of conventional cryptography is key + management</em>. Today the standard solution is to build a <a + href="#hybrid">hybrid system</a> using <a href="#public">public key</a> + techniques to manage keys.</p> + </dd> + <dt><a name="T">T</a></dt> + <dt><a name="TIS">TIS</a></dt> + <dd>Trusted Information Systems, a firewall vendor now part of <a + href="#NAI">NAI</a>. Their Gauntlet product offers IPsec VPN services. + TIS implemented the first version of <a href="#SDNS">Secure DNS</a> on + a <a href="#DARPA">DARPA</a> contract.</dd> + <dt><a name="TLS">TLS</a></dt> + <dd><b>T</b>ransport <b>L</b>ayer <b>S</b>ecurity, a newer name for <a + href="#SSL">SSL</a>.</dd> + <dt><a name="TOS">TOS field</a></dt> + <dd>The <strong>T</strong>ype <strong>O</strong>f + <strong>S</strong>ervice field in an IP header, used to control + qualkity of service routing.</dd> + <dt><a name="traffic">Traffic analysis</a></dt> + <dd>Deducing useful intelligence from patterns of message traffic, + without breaking codes or reading the messages. In one case during + World War II, the British guessed an attack was coming because all + German radio traffic stopped. The "radio silence" order, intended to + preserve security, actually gave the game away. + <p>In an industrial espionage situation, one might deduce something + interesting just by knowing that company A and company B were talking, + especially if one were able to tell which departments were involved, or + if one already knew that A was looking for acquisitions and B was + seeking funds for expansion.</p> + <p>In general, traffic analysis by itself is not very useful. However, + in the context of a larger intelligence effort where quite a bit is + already known, it can be very useful. When you are solving a complex + puzzle, every little bit helps.</p> + <p><a href="#IPSEC">IPsec</a> itself does not defend against traffic + analysis, but carefully thought out systems using IPsec can provide at + least partial protection. In particular, one might want to encrypt more + traffic than was strictly necessary, route things in odd ways, or even + encrypt dummy packets, to confuse the analyst. We discuss this <a + href="ipsec.html#traffic.resist">here</a>.</p> + </dd> + <dt><a name="transport">Transport mode</a></dt> + <dd>An IPsec application in which the IPsec gateway is the destination of + the protected packets, a machine acts as its own gateway. Contrast with + <a href="#tunnel">tunnel mode</a>.</dd> + <dt>Triple DES</dt> + <dd>see <a href="#3DES">3DES</a></dd> + <dt><a name="TTL">TTL</a></dt> + <dd><strong>T</strong>ime <strong>T</strong>o <strong>L</strong>ive, used + to control <a href="#DNS">DNS</a> caching. Servers discard cached + records whose TTL expires</dd> + <dt><a name="tunnel">Tunnel mode</a></dt> + <dd>An IPsec application in which an IPsec gateway provides protection + for packets to and from other systems. Contrast with <a + href="#transport">transport mode</a>.</dd> + <dt><a name="2key">Two-key Triple DES</a></dt> + <dd>A variant of <a href="#3DES">triple DES or 3DES</a> in which only two + keys are used. As in the three-key version, the order of operations is + <a href="#EDE">EDE</a> or encrypt-decrypt-encrypt, but in the two-key + variant the first and third keys are the same. + <p>3DES with three keys has 3*56 = 168 bits of key but has only 112-bit + strength against a <a href="#meet">meet-in-the-middle</a> attack, so it + is possible that the two key version is just as strong. Last I looked, + this was an open question in the research literature.</p> + <p>RFC 2451 defines triple DES for <a href="#IPSEC">IPsec</a> as the + three-key variant. The two-key variant should not be used and is not + implemented directly in <a href="#FreeSWAN">Linux FreeS/WAN</a>. It + cannot be used in automatically keyed mode without major fiddles in the + source code. For manually keyed connections, you could make Linux + FreeS/WAN talk to a two-key implementation by setting two keys the same + in /etc/ipsec.conf.</p> + </dd> + <dt><a name="U">U</a></dt> + <dt><a name="V">V</a></dt> + <dt><a name="virtual">Virtual Interface</a></dt> + <dd>A <a href="#Linux">Linux</a> feature which allows one physical + network interface to have two or more IP addresses. See the <cite>Linux + Network Administrator's Guide</cite> in <a + href="biblio.html#kirch">book form</a> or <a + href="http://metalab.unc.edu/LDP/LDP/nag/node1.html">on the web</a> for + details.</dd> + <dt>Virtual Private Network</dt> + <dd>see <a href="#VPN">VPN</a></dd> + <dt><a name="VPN">VPN</a></dt> + <dd><b>V</b>irtual <b>P</b>rivate <b>N</b>etwork, a network which can + safely be used as if it were private, even though some of its + communication uses insecure connections. All traffic on those + connections is encrypted. + <p><a href="#IPSEC">IPsec</a> is not the only technique available for + building VPNs, but it is the only method defined by <a + href="#RFC">RFCs</a> and supported by many vendors. VPNs are by no + means the only thing you can do with IPsec, but they may be the most + important application for many users.</p> + </dd> + <dt><a name="VPNC">VPNC</a></dt> + <dd><a href="http://www.vpnc.org">Virtual Private Network Consortium</a>, + an association of vendors of VPN products.</dd> + <dt><a name="W">W</a></dt> + <dt><a name="Wassenaar.gloss">Wassenaar Arrangement</a></dt> + <dd>An international agreement restricting export of munitions and other + tools of war. Unfortunately, cryptographic software is also restricted + under the current version of the agreement. <a + href="politics.html#Wassenaar">Discussion</a>.</dd> + <dt><a name="web">Web of Trust</a></dt> + <dd><a href="#PGP">PGP</a>'s method of certifying keys. Any user can sign + a key; you decide which signatures or combinations of signatures to + accept as certification. This contrasts with the hierarchy of <a + href="#CA">CAs (Certification Authorities)</a> used in many <a + href="#PKI">PKIs (Public Key Infrastructures)</a>. + <p>See <a href="#GTR">Global Trust Register</a> for an interesting + addition to the web of trust.</p> + </dd> + <dt><a name="WEP">WEP (Wired Equivalent Privacy)</a></dt> + <dd>The cryptographic part of the <a href="#IEEE">IEEE</a> standard for + wireless LANs. As the name suggests, this is designed to be only as + secure as a normal wired ethernet. Anyone with a network conection can + tap it. Its advocates would claim this is good design, refusing to + build in complex features beyond the actual requirements. + <p>Critics refer to WEP as "Wire<em>tap</em> Equivalent Privacy", and + consider it a horribly flawed design based on bogus "requirements". You + do not control radio waves as you might control your wires, so the + metaphor in the rationale is utterly inapplicable. A security policy + that chooses not to invest resources in protecting against certain + attacks which can only be conducted by people physically plugged into + your LAN may or may not be reasonable. The same policy is completely + unreasonable when someone can "plug in" from a laptop half a block + away..</p> + <p>There has been considerable analysis indicating that WEP is + seriously flawed. A FAQ on attacks against WEP is available. Part of it + reads:</p> + + <blockquote> + ... attacks are practical to mount using only inexpensive + off-the-shelf equipment. We recommend that anyone using an 802.11 + wireless network not rely on WEP for security, and employ other + security measures to protect their wireless network. Note that our + attacks apply to both 40-bit and the so-called 128-bit versions of + WEP equally well.</blockquote> + <p>WEP appears to be yet another instance of governments, and + unfortunately some vendors and standards bodies, deliberately promoting + hopelessly flawed "security" products, apparently mainly for the + benefit of eavesdropping agencies. See this <a + href="politics.html#weak">discussion</a>.</p> + </dd> + <dt><a name="X">X</a></dt> + <dt><a name="X509">X.509</a></dt> + <dd>A standard from the <a href="http://www.itu.int">ITU (International + Telecommunication Union)</a>, for hierarchical directories with + authentication services, used in many <a href="#PKI">PKI</a> + implementations. + <p>Use of X.509 services, via the <a href="#LDAP">LDAP protocol</a>, + for certification of keys is allowed but not required by the <a + href="#IPSEC">IPsec</a> RFCs. It is not yet implemented in <a + href="#FreeSWAN">Linux FreeS/WAN</a>.</p> + </dd> + <dt>Xedia</dt> + <dd>A vendor of router and Internet access products, now part of Lucent. + Their QVPN products interoperate with Linux FreeS/WAN; see our <a + href="interop.html#Xedia">interop document</a>.</dd> + <dt><a name="Y">Y</a></dt> + <dt><a name="Z">Z</a></dt> +</dl> +</body> +</html> |