diff options
Diffstat (limited to 'doc/glossary.html')
| -rw-r--r-- | doc/glossary.html | 2132 |
1 files changed, 2132 insertions, 0 deletions
diff --git a/doc/glossary.html b/doc/glossary.html new file mode 100644 index 000000000..3ca33810f --- /dev/null +++ b/doc/glossary.html @@ -0,0 +1,2132 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> +<HTML> +<HEAD> +<TITLE>Introduction to FreeS/WAN</TITLE> +<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1"> +<STYLE TYPE="text/css"><!-- +BODY { font-family: serif } +H1 { font-family: sans-serif } +H2 { font-family: sans-serif } +H3 { font-family: sans-serif } +H4 { font-family: sans-serif } +H5 { font-family: sans-serif } +H6 { font-family: sans-serif } +SUB { font-size: smaller } +SUP { font-size: smaller } +PRE { font-family: monospace } +--></STYLE> +</HEAD> +<BODY> +<A HREF="toc.html">Contents</A> +<A HREF="web.html">Previous</A> +<A HREF="biblio.html">Next</A> +<HR> +<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="biblio.html#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="web.html#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="web.html#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="ipsec.html#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="ipsec.html#DNS"> DNS</A> (Domain Name + Service). See our bibliography for a<A href="ipsec.html#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="ipsec.html#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="politics.html#desnotsecure"> + highly insecure</A> today.<A href="#3DES"> Triple DES</A> is the + default block cipher for<A href="web.html#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="biblio.html#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="web.html#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="politics.html#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="politics.html#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="web.html#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></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> +</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="web.html#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="web.html#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>,calculating<NOBR><VAR> x = 7</VAR>is straightforward. One + method is just to calculate<NOBR><VAR> 2^11 = 2048</VAR>,then<NOBR><VAR> + 2048 mod 13 == 7</VAR>.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>,find the logarithm<NOBR><VAR> y = 11</VAR>.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="web.html#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="web.html#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="web.html#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="politics.html#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="web.html#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.html#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="web.html#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="web.html#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="web.html#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="web.html#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="web.html#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="web.html#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="web.html#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="ipsec.html#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>work. Against triple DES, you need<NOBR> + 2<SUP>56</SUP> + 2<SUP>112</SUP> ~= 2<SUP>112</SUP>.</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>.</P> +</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="mail.html#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="mail.html#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="web.html#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="ipsec.html#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="ipsec.html#DNS"> DNS or Domain Name Service</A> + enhanced with authentication services. This is being designed by the<A href="mail.html#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="ipsec.html#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</(null)></(null)></(null)> 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</(null)> +<!--mo--> + /</(null)> +<!--mn--> + + 2</(null)></(null)></(null)></(null)> , 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="ipsec.html#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="web.html#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.html#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="web.html#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> +<HR> +<A HREF="toc.html">Contents</A> +<A HREF="web.html">Previous</A> +<A HREF="biblio.html">Next</A> +</BODY> +</HTML> |