diff options
Diffstat (limited to 'doc/glossary.html')
| -rw-r--r-- | doc/glossary.html | 2132 |
1 files changed, 0 insertions, 2132 deletions
diff --git a/doc/glossary.html b/doc/glossary.html deleted file mode 100644 index 3ca33810f..000000000 --- a/doc/glossary.html +++ /dev/null @@ -1,2132 +0,0 @@ -<!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> |