freeswan/doc/glossary.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <HTML>
   3 <HEAD>
   4 <TITLE> Introduction to FreeS/WAN</TITLE>
   5 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   6 </HEAD>
   7 <BODY>
   8 <A HREF="toc.html">Contents</a>
   9 <A HREF="web.html">Previous</a>
  10 <A HREF="biblio.html">Next</a>
  11 <HR>
  12 <H1><A name="ourgloss">Glossary for the Linux FreeS/WAN project</A></H1>
  13 <P> Entries are in alphabetical order. Some entries are only one line
  14 or one paragraph long. Others run to several paragraphs. I have tried
  15 to put the essential information in the first paragraph so you can skip
  16 the other paragraphs if that seems appropriate.</P>
  17 <HR>
  18 <H2><A name="jump">Jump to a letter in the glossary</A></H2>
  19 <CENTER><BIG><B><A href="#0"> numeric</A><A href="#A"> A</A><A href="#B">
  20  B</A><A href="#C"> C</A><A href="#D"> D</A><A href="#E"> E</A><A href="#F">
  21  F</A><A href="#G"> G</A><A href="#H"> H</A><A href="#I"> I</A><A href="#J">
  22  J</A><A href="#K"> K</A><A href="#L"> L</A><A href="#M"> M</A><A href="#N">
  23  N</A><A href="#O"> O</A><A href="#P"> P</A><A href="#Q"> Q</A><A href="#R">
  24  R</A><A href="#S"> S</A><A href="#T"> T</A><A href="#U"> U</A><A href="#V">
  25  V</A><A href="#W"> W</A><A href="#X"> X</A><A href="#Y"> Y</A><A href="#Z">
  26  Z</A></B></BIG></CENTER>
  27 <HR>
  28 <H2><A name="gloss">Other glossaries</A></H2>
  29 <P>Other glossaries which overlap this one include:</P>
  30 <UL>
  31 <LI>The VPN Consortium's glossary of <A href="http://www.vpnc.org/terms.html">
  32 VPN terms</A>.</LI>
  33 <LI>glossary portion of the <A href="http://www.rsa.com/rsalabs/faq/html/glossary.html">
  34 Cryptography  FAQ</A></LI>
  35 <LI>an extensive crytographic glossary on <A href="http://www.io.com/~ritter/GLOSSARY.HTM">
  36 Terry Ritter's</A> page.</LI>
  37 <LI>The <A href="#NSA">NSA</A>'s <A href="http://www.sans.org/newlook/resources/glossary.htm">
  38 glossary of  computer security</A> on the <A href="http://www.sans.org">
  39 SANS  Institute</A> site.</LI>
  40 <LI>an <A href="http://www.ietf.org/internet-drafts/draft-shirey-security-glossary-01.txt">
  41 Internet  Draft</A> Crypto Glossary</LI>
  42 <LI>a small glossary for Internet Security at <A href="http://www5.zdnet.com/pcmag/pctech/content/special/glossaries/internetsecurity.html">
  43  PC magazine</A></LI>
  44 <LI>The <A href="http://www.visi.com/crypto/inet-crypto/glossary.html">
  45 glossary</A> from Richard Smith's book <A href="biblio.html#Smith">
  46 Internet  Cryptography</A></LI>
  47 </UL>
  48 <P>Three Internet glossaries are available as RFCs:</P>
  49 <UL>
  50 <LI><A href="http://www.rfc-editor.org/rfc/rfc1208.txt">Glossary of
  51  Networking Terms</A></LI>
  52 <LI><A href="http://www.rfc-editor.org/rfc/rfc1983.txt">Internet User's
  53  Glossary</A></LI>
  54 <LI><A href="http://www.rfc-editor.org/rfc/rfc2828.txt">Internet
  55 Security  Glossary</A></LI>
  56 </UL>
  57 <P>More general glossary or dictionary information:</P>
  58 <UL>
  59 <LI>Free Online Dictionary of Computing (FOLDOC)
  60 <UL>
  61 <LI><A href="http://www.nightflight.com/foldoc">North America</A></LI>
  62 <LI><A href="http://wombat.doc.ic.ac.uk/foldoc/index.html">Europe</A></LI>
  63 <LI><A href="http://www.nue.org/foldoc/index.html">Japan</A></LI>
  64 </UL>
  65 </LI>
  66 <P>There are many more mirrors of this dictionary.</P>
  67 <LI><A href="http://hissa.ncsl.nist.gov/~black/CRCDict/">CRC dictionary
  68 of  Computer Science</A></LI>
  69 <LI>The Jargon File, the definitive resource for hacker slang and
  70 folklore
  71 <UL>
  72 <LI><A href="http://www.netmeg.net/jargon">North America</A></LI>
  73 <LI><A href="http://info.wins.uva.nl/~mes/jargon/">Holland</A></LI>
  74 <LI><A href="http://www.tuxedo.org/~esr/jargon">home page</A></LI>
  75 </UL>
  76 </LI>
  77 <P>There are also many mirrors of this. See the home page for a list.</P>
  78 <LI>A general <A href="http://www.trinity.edu/~rjensen/245glosf.htm#Navigate">
  79  technology  glossary</A></LI>
  80 <LI>An <A href="http://www.yourdictionary.com/">online  dictionary
  81 resource page</A> with pointers to many dictionaries for many  languages</LI>
  82 <LI>A <A href="http://www.onelook.com/">search engine</A> that accesses
  83  several hundred online dictionaries</LI>
  84 <LI>O'Reilly <A href="http://www.ora.com/reference/dictionary/">
  85 Dictionary  of PC Hardware and Data Communications Terms</A></LI>
  86 </UL>
  87 <P>Internet encyclopedias include:</P>
  88 <UL>
  89 <LI><A href="http://www.FreeSoft.org/CIE/index.htm">Connected</A></LI>
  90 <LI><A href="http://www.whatis.com/">whatis.com</A></LI>
  91 </UL>
  92 <HR>
  93 <H2><A name="definitions">Definitions</A></H2>
  94 <DL>
  95 <DT><A name="3DES"><A name="0">3DES (Triple DES)</A></A></DT>
  96 <DD>Using three <A href="#DES">DES</A> encryptions on a single data
  97  block, with at least two different keys, to get higher security than
  98  is available from a single DES pass. The three-key version of 3DES is
  99  the default encryption algorithm for <A href="web.html#FreeSWAN">Linux
 100  FreeS/WAN</A>. </DD>
 101 <P><A href="#IPSEC">IPSEC</A> always does 3DES with three different
 102  keys, as required by RFC 2451. For an explanation of the two-key
 103  variant, see <A href="#2key">two key triple DES</A>. Both use an <A href="#EDE">
 104 EDE</A> encrypt-decrypt-encrpyt sequence of  operations.</P>
 105 <P>Single <A href="#DES">DES</A> is <A href="politics.html#desnotsecure">
 106 insecure</A>.</P>
 107 <P>Double DES is ineffective. Using two 56-bit keys, one might expect
 108  an attacker to have to do 2<SUP>112</SUP> work to break it. In fact,
 109  only 2<SUP>57</SUP> work is required with a <A href="#meet">
 110 meet-in-the-middle attack</A>, though a large amount of  memory is also
 111 required. Triple DES is vulnerable to a similar attack,  but that just
 112 reduces the work factor from the 2<SUP>168</SUP> one  might expect to 2<SUP>
 113 112</SUP>. That provides adequate protection  against <A href="#brute">
 114 brute force</A> attacks, and no better attack  is known.</P>
 115 <P>3DES can be somewhat slow compared to other ciphers. It requires
 116  three DES encryptions per block. DES was designed for hardware
 117  implementation and includes some operations which are difficult in
 118  software. However, the speed we get is quite acceptable for many uses.
 119  See <A href="#benchmarks">benchmarks</A> below for details.</P>
 120 <DT><A name="A">A</A></DT>
 121 <DT><A name="active"><A name="A">Active attack</A></A></DT>
 122 <DD>An attack in which the attacker does not merely eavesdrop (see <A href="#passive">
 123 passive attack</A>) but takes action to change,  delete, reroute, add,
 124 forge or divert data. Perhaps the best-known  active attack is <A href="#middle">
 125 man-in-the-middle</A>. In general, <A href="#authentication">
 126  authentication</A> is a useful defense  against active attacks.</DD>
 127 <DT><A name="AES">AES</A></DT>
 128 <DD>The <B>A</B>dvanced <B>E</B>ncryption <B>S</B>tandard, a new <A href="#block">
 129 block cipher</A> standard to replace <A href="politics.html#desnotsecure">
 130 DES</A> being developed by <A href="#NIST">NIST</A>, the US National
 131 Institute of Standards and  Technology. DES used 64-bit blocks and a
 132 56-bit key. AES ciphers use a  128-bit block and are required to
 133 support 128, 192 and 256-bit keys.  Some of them support other sizes as
 134 well. The larger block size helps  resist <A href="#birthday">birthday
 135 attacks</A> while the large key  size prevents <A href="#brute">brute
 136 force attacks</A>. </DD>
 137 <P>Fifteen proposals meeting NIST's basic criteria were submitted in
 138  1998 and subjected to intense discussion and analysis, &quot;round one&quot;
 139  evaluation. In August 1999, NIST narrowed the field to five &quot;round
 140  two&quot; candidates:</P>
 141 <UL>
 142 <LI><A href="http://www.research.ibm.com/security/mars.html">Mars</A>
 143  from IBM</LI>
 144 <LI><A href="http://www.rsa.com/rsalabs/aes/">RC6</A> from RSA</LI>
 145 <LI><A href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael/">Rijndael</A>
 146  from two Belgian researchers</LI>
 147 <LI><A href="http://www.cl.cam.ac.uk/~rja14/serpent.html">Serpent</A>,
 148 a  British-Norwegian-Israeli research collaboration</LI>
 149 <LI><A href="http://www.counterpane.com/twofish.html">Twofish</A> from
 150 the consulting firm Counterpane</LI>
 151 </UL>
 152 <P> In October 2000, NIST announced the winner -- Rijndael.</P>
 153 <P>Adding one or more AES ciphers to <A href="web.html#FreeSWAN">Linux
 154  FreeS/WAN</A> would be useful undertaking, and considerable freely
 155  available code exists to start from. One complication is that our code
 156  is built for a 64-bit block cipher and AES uses a 128-bit block.
 157  Volunteers via the <A href="#list">mailing lists</A> would be  welcome.</P>
 158 <P>For more information, see the <A href="http://csrc.nist.gov/encryption/aes/aes_home.htm">
 159  NIST AES home  page</A> or the <A href="http://www.ii.uib.no/~larsr/aes.html">
 160  Block  Cipher Lounge AES page</A>. For code and benchmarks see <A href="http://www.btinternet.com/~brian.gladman/">
 161  Brian Gladman's page </A> .</P>
 162 <DT><A name="AH">AH</A></DT>
 163 <DD>The <A href="#IPSEC">IPSEC</A><B> A</B>uthentication <B>H</B>eader,
 164  added after the IP header. For details, see our <A href="web.html#overview">
 165 IPSEC Overview</A> document and/or RFC 2402.</DD>
 166 <DT><A name="alicebob">Alice and Bob</A></DT>
 167 <DD>A and B, the standard example users in writing on cryptography and
 168  coding theory. Carol and Dave join them for protocols which require
 169  more players. </DD>
 170 <P><A href="biblio.html#schneier">Bruce Schneier</A> extends these with
 171 many  others such as Eve the Eavesdropper and Victor the Verifier. His
 172  extensions seem to be in the process of becoming standard as well. See
 173  page 23 of <A href="biblio.html#schneier"> Applied Cryptography</A></P>
 174 <P>Alice and Bob have an amusing <A href="http://www.conceptlabs.co.uk/alicebob.html">
 175  biography</A> on  the web.</P>
 176 <DT>ARPA</DT>
 177 <DD>see <A href="#DARPA">DARPA</A></DD>
 178 <DT><A name="ASIO">ASIO</A></DT>
 179 <DD>Australian Security Intelligence Organisation.</DD>
 180 <DT>Asymmetric cryptography</DT>
 181 <DD>See <A href="#public">public key cryptography</A>.</DD>
 182 <DT><A name="authentication">Authentication</A></DT>
 183 <DD>Ensuring that a message originated from the expected sender and has
 184  not been altered on route. <A href="#IPSEC">IPSEC</A> uses
 185  authentication in two places: </DD>
 186 <P>
 187 <UL>
 188 <LI>peer authentication, authenticating the players in <A href="#IKE">
 189 IKE</A>'s <A href="#DH">Diffie-Hellman</A> key  exchanges to prevent <A href="#middle">
 190 man-in-the-middle  attacks</A>. This can be done in a number of ways.
 191 The methods  supported by FreeS/WAN are discussed in our <A href="config.html#choose">
 192 configuration</A> document.</LI>
 193 <LI>packet authentication, authenticating packets on an established <A href="#SA">
 194  SA</A>, either with a separate <A href="#AH">authentication header</A>
 195  or with the optional  authentication in the <A href="#ESP">ESP</A>
 196  protocol. In either  case, packet authentication uses a <A href="#HMAC">
 197 hashed message  athentication code</A> technique.</LI>
 198 </UL>
 199 <P>Outside IPSEC, passwords are perhaps the most common authentication
 200  mechanism. Their function is essentially to authenticate the person's
 201  identity to the system. Passwords are generally only as secure as the
 202  network they travel over. If you send a cleartext password over a
 203  tapped phone line or over a network with a packet sniffer on it, the
 204  security provided by that password becomes zero. Sending an encrypted
 205  password is no better; the attacker merely records it and reuses it at
 206  his convenience. This is called a <A href="#replay">replay</A> attack.</P>
 207 <P>A common solution to this problem is a <A href="#challenge">
 208 challenge-response</A> system. This defeats simple  eavesdropping and
 209 replay attacks. Of course an attacker might still  try to break the
 210 cryptographic algorithm used, or the <A href="#random"> random number</A>
 211  generator.</P>
 212 <DT><A name="auto">Automatic keying</A></DT>
 213 <DD>A mode in which keys are automatically generated at connection
 214  establisment and new keys automaically created periodically
 215  thereafter. Contrast with <A href="ipsec.html#manual">manual keying</A>
 216  in which  a single stored key is used. </DD>
 217 <P>IPSEC uses the <A href="#DH">Diffie-Hellman key exchange  protocol</A>
 218  to create keys. An <A href="authentication">authentication</A>
 219  mechansim is required for  this. The methods supported by FreeS/WAN
 220 are discussed in our <A href="config.html#choose">configuration</A>
 221  document.</P>
 222 <P>Having an attacker break the authentication is emphatically not a
 223  good idea. An attacker that breaks authentication, and manages to
 224  subvert some other network entities (DNS, routers or gateways), can
 225  use a <A href="#middle">man-in-the middle attack</A> to break the
 226  security of your IPSEC connections.</P>
 227 <P>However, having an attacker break the authentication in automatic
 228  keying is not quite as bad as losing the key in manual keying.</P>
 229 <UL>
 230 <LI>An attacker who reads /etc/ipsec.conf and gets the keys for a
 231  manually keyed connection can, without further effort, read all
 232  messages encrypted with those keys, including any old messages he  may
 233 have archived.</LI>
 234 <LI>Automatic keying has a property called <A href="#PFS">perfect
 235  forward secrecy</A>. An attacker who breaks the authentication  gets
 236 none of the automatically generated keys and cannot  immediately read
 237 any messages. He has to mount a successful <A href="#middle">
 238 man-in-the-middle attack</A> in real time before he  can read anything.
 239 He cannot read old archived messages at all and  will not be able to
 240 read any future messages not caught by  man-in-the-middle tricks.</LI>
 241 </UL>
 242 <P>That said, the secrets used for authentication, stored in <A href="manpage.d/ipsec.secrets.5.html">
 243 ipsec.secrets(5)</A>, should  still be protected as tightly as
 244 cryptographic keys.</P>
 245 <DT><A name="B">B</A></DT>
 246 <DT><A href="http://www.nortelnetworks.com">Bay  Networks</A></DT>
 247 <DD>A vendor of routers, hubs and related products, now a subsidiary of
 248  Nortel. Interoperation between their IPSEC products and Linux
 249  FreeS/WAN was problematic at last report; see our <A href="interop.html#bay">
 250 interoperation</A> section.</DD>
 251 <DT><A name="benchmarks">benchmarks</A></DT>
 252 <DD>Our default block cipher, <A href="#3DES">triple DES</A>, is slower
 253  than many alternate ciphers that might be used. Speeds achieved,
 254  however, seem adequate for many purposes. For example, the assembler
 255  code from the <A href="#LIBDES">LIBDES</A> library we use encrypts 1.6
 256  megabytes per second on a Pentium 200, according to the test program
 257  supplied with the library. </DD>
 258 <P> For more detail, see our document on <A href="performance.html">
 259 FreeS/WAN performance</A>. </P>
 260 <DT><A name="BIND">BIND</A></DT>
 261 <DD><B>B</B>erkeley <B>I</B>nternet <B>N</B>ame <B>D</B>aemon, a widely
 262  used implementation of <A href="#DNS">DNS</A> (Domain Name Service).
 263  See our bibliography for a <A href="#DNS">useful reference</A>. See
 264  the <A href="http://www.isc.org/bind.html">BIND home page</A> for more
 265  information and the latest version.</DD>
 266 <DT><A name="birthday">Birthday attack</A></DT>
 267 <DD>A cryptographic attack based on the mathematics exemplified by the <A
 268 href="#paradox"> birthday paradox</A>. This math turns up whenever  the
 269 question of two cryptographic operations producing the same result
 270  becomes an issue:
 271 <UL>
 272 <LI><A href="#collision">collisions</A> in <A href="#digest">message
 273  digest</A> functions.</LI>
 274 <LI>identical output blocks from a <A href="#block">block  cipher</A></LI>
 275 <LI>repetition of a challenge in a <A href="#challenge">
 276 challenge-response</A> system</LI>
 277 </UL>
 278 </DD>
 279 <P>Resisting such attacks is part of the motivation for:</P>
 280 <UL>
 281 <LI>hash algorithms such as <A href="#SHA">SHA</A> and <A href="#RIPEMD">
 282 RIPEMD-160</A> giving a 160-bit result rather than  the 128 bits of <A href="#MD4">
 283 MD4</A>, <A href="#MD5">MD5</A> and <A href="#RIPEMD"> RIPEMD-128</A>.</LI>
 284 <LI><A href="#AES">AES</A> block ciphers using a 128-bit block  instead
 285 of the 64-bit block of most current ciphers</LI>
 286 <LI><A href="#IPSEC">IPSEC</A> using a 32-bit counter for packets  sent
 287 on an <A href="ipsec.html#auto">automatically keyed</A><A href="#SA"> SA</A>
 288  and requiring that the connection always be  rekeyed before the
 289 counter overflows.</LI>
 290 </UL>
 291 <DT><A name="paradox">Birthday paradox</A></DT>
 292 <DD>Not really a paradox, just a rather counter-intuitive mathematical
 293  fact. In a group of 23 people, the chance of a least one pair having
 294  the same birthday is over 50%. </DD>
 295 <P>The second person has 1 chance in 365 (ignoring leap years) of
 296  matching the first. If they don't match, the third person's chances of
 297  matching one of them are 2/365. The 4th, 3/365, and so on. The total
 298  of these chances grows more quickly than one might guess.</P>
 299 <DT><A name="block">Block cipher</A></DT>
 300 <DD>A <A href="#symmetric">symmetric cipher</A> which operates on
 301  fixed-size blocks of plaintext, giving a block of ciphertext for each.
 302  Contrast with <A href="#stream"> stream cipher</A>. Block ciphers can
 303  be used in various <A href="#mode">modes</A> when multiple block are
 304  to be encrypted. </DD>
 305 <P><A href="#DES">DES</A> is among the the best known and widely used
 306  block ciphers, but is now obsolete. Its 56-bit key size makes it <A href="politics.html#desnotsecure">
 307 highly insecure</A> today. <A href="#3DES">Triple  DES</A> is the
 308 default transform for <A href="web.html#FreeSWAN">Linux  FreeS/WAN</A>
 309  because it is the only cipher which is both required in  the <A href="rfc.html#RFC">
 310 RFCs</A> and apparently secure.</P>
 311 <P>The current generation of block ciphers -- such as <A href="#Blowfish">
 312 Blowfish</A>, <A href="#CAST128">CAST-128</A> and <A href="#IDEA">IDEA</A>
 313  -- all use 64-bit blocks and 128-bit keys. The  next generation, <A href="#AES">
 314 AES</A>, uses 128-bit blocks and  supports key sizes up to 256 bits.</P>
 315 <P>The <A href="http://www.ii.uib.no/~larsr/bc.html"> Block Cipher
 316  Lounge</A> web site has more information.</P>
 317 <DT><A name="Blowfish">Blowfish</A></DT>
 318 <DD>A <A href="#block">block cipher</A> using 64-bit blocks and keys of
 319  up to 448 bits, designed by <A href="biblio.html#schneier">Bruce
 320 Schneier</A> and  used in several products. </DD>
 321 <P>This is not required by the <A href="#IPSEC">IPSEC</A> RFCs and not
 322  currently used in <A href="web.html#FreeSWAN">Linux FreeS/WAN</A>.</P>
 323 <DT><A name="brute">Brute force attack (exhaustive search)</A></DT>
 324 <DD>Breaking a cipher by trying all possible keys. This is always
 325  possible in theory (except against a <A href="#OTP">one-time pad</A>),
 326  but it becomes practical only if the key size is inadequate. For an
 327  important example, see our document on the <A href="politics.html#desnotsecure">
 328 insecurity of DES</A> with its 56-bit key. For an  analysis of key
 329 sizes required to resist plausible brute force  attacks, see <A href="http://www.counterpane.com/keylength.html">
 330 this  paper</A>. </DD>
 331 <P>Longer keys protect against brute force attacks. Each extra bit in
 332  the key doubles the number of possible keys and therefore doubles the
 333  work a brute force attack must do. A large enough key defeats <STRONG>
 334  any</STRONG> brute force attack.</P>
 335 <P>For example, the EFF's <A href="#EFF">DES Cracker</A> searches a
 336  56-bit key space in an average of a few days. Let us assume an
 337  attacker that can find a 64-bit key (256 times harder) by brute force
 338  search in a second (a few hundred thousand times faster). For a 96-bit
 339  key, that attacker needs 2<SUP>32</SUP> seconds, just over a century.
 340  Against a 128-bit key, he needs 2<SUP>32</SUP> centuries or about
 341  400,000,000,000 years. Your data is then obviously secure against
 342  brute force attacks. Even if our estimate of the attacker's speed is
 343  off by a factor of a million, it still takes him 400,000 years to
 344  crack a message.</P>
 345 <P>This is why</P>
 346 <UL>
 347 <LI>single <A href="#DES">DES</A> is now considered <A href="politics.html#desnotsecure">
 348 dangerously insecure</A></LI>
 349 <LI>all of the current generation of <A href="#block">block  ciphers</A>
 350  use a 128-bit or longer key</LI>
 351 <LI><A href="#AES">AES</A> ciphers support keysizes 128, 192 and 256
 352  bits</LI>
 353 <LI>any cipher we add to Linux FreeS/WAN will have <EM>at least</EM> a
 354 128-bit key</LI>
 355 </UL>
 356 <P><STRONG>Cautions:</STRONG>
 357 <BR><EM> Inadequate keylength always indicates a weak cipher</EM> but
 358 it is  important to note that <EM>adequate keylength does not
 359 necessarily  indicate a strong cipher</EM>. There are many attacks
 360 other than brute  force, and adequate keylength <EM>only</EM>
 361  guarantees resistance to  brute force. Any cipher, whatever its key
 362 size, will be weak if design  or implementation flaws allow other
 363 attacks.</P>
 364 <P>Also, <EM>once you have adequate keylength</EM> (somewhere around
 365  90 or 100 bits), <EM>adding more key bits make no practical  difference</EM>
 366 , even against brute force. Consider our 128-bit  example above that
 367 takes 400 billion years to break by brute force. Do  we care if an
 368 extra 16 bits of key put that into the quadrillions? No.  What about 16
 369 fewer bits reducing it to the 112-bit security level of <A href="#3DES">
 370  Triple DES</A>, which our example attacker could break  in just over a
 371 billion years? No again, unless we're being really  paranoid about
 372 safety margins.</P>
 373 <P>There may be reasons of convenience in the design of the cipher to
 374  support larger keys. For example <A href="#Blowfish">Blowfish</A>
 375  allows up to 448 bits and <A href="#RC4">RC4</A> up to 2048, but
 376  beyond 100-odd bits it makes no difference to practical security.</P>
 377 <DT>Bureau of Export Administration</DT>
 378 <DD>see <A href="#BXA">BXA</A></DD>
 379 <DT><A name="BXA">BXA</A></DT>
 380 <DD>The US Commerce Department's <B>B</B>ureau of E<B>x</B>port <B> A</B>
 381 dministration which administers the <A href="#EAR">EAR</A> Export
 382 Administration Regulations controling the export of, among  other
 383 things, cryptography.</DD>
 384 <DT><A name="C">C</A></DT>
 385 <DT><A name="CA"><A name="C">CA</A></A></DT>
 386 <DD><B>C</B>ertification <B>A</B>uthority, an entity in a <A href="ipsec.html#PKI">
 387 public key infrastructure</A> that can certify keys by  signing them.
 388 Usually CAs form a hierarchy. The top of this hierarchy  is called the <A
 389 href="#rootCA">root CA</A>. </DD>
 390 <P>See <A href="#web">Web of Trust</A> for an alternate model.</P>
 391 <DT><A name="CAST128">CAST-128</A></DT>
 392 <DD>A <A href="#block">block cipher</A> using 64-bit blocks and 128-bit
 393  keys, described in RFC 2144 and used in products such as <A href="#Entrust">
 394 Entrust</A> and recent versions of <A href="#PGP">PGP</A>. </DD>
 395 <P>This is not required by the <A href="#IPSEC">IPSEC</A> RFCs and not
 396  currently used in <A href="web.html#FreeSWAN">Linux FreeS/WAN</A>.</P>
 397 <DT>CAST-256</DT>
 398 <DD><A href="#Entrust">Entrust</A>'s candidate cipher for the <A href="#AES">
 399 AES standard</A>, largely based on the <A href="#CAST128">CAST-128</A>
 400  design.</DD>
 401 <DT><A name="CBC">CBC mode</A></DT>
 402 <DD><B>C</B>ipher <B>B</B>lock <B>C</B>haining <A href="#mode">mode</A>
 403 ,  a method of using a <A href="#block">block cipher</A> in which for
 404  each block except the first, the result of the previous encryption is
 405  XORed into the new block before it is encrypted. CBC is the mode used
 406  in <A href="#IPSEC">IPSEC</A>. </DD>
 407 <P>An <A href="#IV">initialisation vector</A> (IV) must be provided.
 408  It is XORed into the first block before encryption. The IV need not be
 409  secret but should be different for each message and unpredictable.</P>
 410 <DT>Certification Authority</DT>
 411 <DD>see <A href="#CA">CA</A></DD>
 412 <DT><A name="mode">Cipher Modes</A></DT>
 413 <DD>Different ways of using a block cipher when encrypting multiple
 414  blocks. </DD>
 415 <P>Four standard modes were defined for <A href="#DES">DES</A> in <A href="#FIPS">
 416 FIPS</A> 81. They can actually be applied with any block  cipher.</P>
 417 <TABLE><TBODY>
 418 <TR><TD><TD><A href="#ECB">ECB</A></TD><TD>Electronic CodeBook</TD><TD>
 419 encrypt each block independently</TD></TR>
 420 <TR><TD><TD><A href="#CBC">CBC</A></TD><TD>Cipher Block Chaining
 421 <BR></TD><TD>XOR previous block ciphertext into new block plaintext
 422  before encrypting new block</TD></TR>
 423 <TR><TD><TD>CFB</TD><TD>Cipher FeedBack</TD><TD></TR>
 424 <TR><TD><TD>OFB</TD><TD>Output FeedBack</TD><TD></TR>
 425 </TABLE>
 426 <P><A href="#IPSEC">IPSEC</A> uses <A href="#CBC">CBC</A> mode since
 427  this is only marginally slower than <A href="#ECB">ECB</A> and is more
 428  secure. In ECB mode the same plaintext always encrypts to the same
 429  ciphertext, unless the key is changed. In CBC mode, this does not
 430  occur.</P>
 431 <P>Various other modes are also possible, but none of them are used in
 432  IPSEC.</P>
 433 <DT><A name="challenge">Challenge-response authentication</A></DT>
 434 <DD>An <A href="#authentication">authentication</A> system in which one
 435  player generates a <A href="#random">random number</A>, encrypts it
 436  and sends the result as a challenge. The other player decrypts and
 437  sends back the result. If the result is correct, that proves to the
 438  first player that the second player knew the appropriate secret,
 439  required for the decryption. Variations on this technique exist using <A
 440 href="#public"> public key</A> or <A href="#symmetric">symmetric</A>
 441  cryptography. Some provide two-way authentication, assuring each
 442  player of the other's identity. </DD>
 443 <P>This is more secure than passwords against two simple attacks:</P>
 444 <UL>
 445 <LI>If cleartext passwords are sent across the wire (e.g. for  telnet),
 446 an eavesdropper can grab them. The attacker may even be  able to break
 447 into other systems if the user has chosen the same  password for them.</LI>
 448 <LI>If an encrypted password is sent, an attacker can record the
 449  encrypted form and use it later. This is called a replay  attack.</LI>
 450 </UL>
 451 <P>A challenge-response system never sends a password, either
 452  cleartext or encrypted.  An attacker cannot record the response to one
 453  challenge and use it as a response to a later challenge. The random
 454  number is different each time.</P>
 455 <P>Of course an attacker might still try to break the cryptographic
 456  algorithm used, or the <A href="#random">random number</A> generator.</P>
 457 <DT><A name="ciphertext">Ciphertext</A></DT>
 458 <DD>The encrypted output of a cipher, as opposed to the unencrypted <A href="#plaintext">
 459 plaintext</A> input.</DD>
 460 <DT><A href="http://www.cisco.com">Cisco</A></DT>
 461 <DD>A vendor of routers, hubs and related products. Their IPSEC
 462 products  interoperate with Linux FreeS/WAN; see our <A href="interop.html#Cisco">
 463 interop</A> section.</DD>
 464 <DT><A name="client">Client</A></DT>
 465 <DD>This term has at least two distinct uses in discussing IPSEC:
 466 <UL>
 467 <LI>The <STRONG>clients of an IPSEC gateway</STRONG> are the  machines
 468 it protects, typically on one or more subnets behind the  gateway. In
 469 this usage, all the machines on an office network are  clients of that
 470 office's IPSEC gateway. Laptop or home machines  connecting to the
 471 office, however, are <EM>not</EM> clients of  that gateway. They are
 472 remote gateways, running the other end of  an IPSEC connection. Each of
 473 them is also its own client.</LI>
 474 <LI><STRONG>IPSEC client software</STRONG> is used to describe
 475  software which runs on various standalone machines to let them
 476  connect to IPSEC networks. In this usage, a laptop or home machine
 477  connecting to the office <EM>is</EM> a client machine.</LI>
 478 </UL>
 479 </DD>
 480 <P>We generally use the term in the first sense. Vendors of Windows
 481  IPSEC solutions often use it in the second.</P>
 482 <DT>Conventional cryptography</DT>
 483 <DD>See <A href="#symmetric">symmetric cryptography</A></DD>
 484 <DT><A name="collision">Collision resistance</A></DT>
 485 <DD>The property of a <A href="#digest">message digest</A> algorithm
 486  which makes it hard for an attacker to find or construct two inputs
 487  which hash to the same output.</DD>
 488 <DT>Copyleft</DT>
 489 <DD>see GNU <A href="#GPL">General Public License</A></DD>
 490 <DT><A name="CSE">CSE</A></DT>
 491 <DD><A href="http://www.cse-cst.gc.ca/cse/english/home_1.html">
 492 Communications  Security Establishment</A>, the Canadian organisation
 493 for <A href="#SIGINT">signals intelligence</A>.</DD>
 494 <DT><A name="D">D</A></DT>
 495 <DT><A name="DARPA"><A name="D">DARPA (sometimes just ARPA)</A></A></DT>
 496 <DD>The US government's <B>D</B>efense <B>A</B>dvanced <B>R</B>esearch <B>
 497  P</B>rojects <B>A</B>gency. Projects they have funded over the  years
 498 have included the Arpanet which evolved into the Internet, the  TCP/IP
 499 protocol suite (as a replacement for the original Arpanet  suite), the
 500 Berkeley 4.x BSD Unix projects, and <A href="#SDNS">Secure  DNS</A>. </DD>
 501 <P>For current information, see their <A href="http://www.darpa.mil/ito">
 502 web site</A>.</P>
 503 <DT><A name="DOS">Denial of service (DoS) attack</A></DT>
 504 <DD>An attack that aims at denying some service to legitimate users of
 505 a  system, rather than providing a service to the attacker.
 506 <UL>
 507 <LI>One variant is a flooding attack, overwhelming the system with  too
 508 many packets, to much email, or whatever.</LI>
 509 <LI>A closely related variant is a resource exhaustion attack. For
 510  example, consider a &quot;TCP SYN flood&quot; attack. Setting up a TCP
 511  connection involves a three-packet exchange:
 512 <UL>
 513 <LI>Initiator: Connection please (SYN)</LI>
 514 <LI>Responder: OK (ACK)</LI>
 515 <LI>Initiator: OK here too</LI>
 516 </UL>
 517 </LI>
 518 <P>If the attacker puts bogus source information in the first  packet,
 519 such that the second is never delivered, the responder may  wait a long
 520 time for the third to come back. If responder has  already allocated
 521 memory for the connection data structures, and  if many of these bogus
 522 packets arrive, the responder may run out  of memory.</P>
 523 <LI>Another variant is to feed the system undigestible data, hoping  to
 524 make it sick. For example, IP packets are limited in size to  64K bytes
 525 and a fragment carries information on where it starts  within that 64K
 526 and how long it is. The &quot;ping of death&quot; delivers  fragments that say,
 527 for example, that they start at 60K and are  20K long. Attempting to
 528 re-assemble these without checking for  overflow can be fatal.</LI>
 529 </UL>
 530 </DD>
 531 <P>The two example attacks discussed were both quite effective when
 532  first discovered, capable of crashing or disabling many operating
 533  systems. They were also well-publicised, and today far fewer systems
 534  are vulnerable to them.</P>
 535 <DT><A name="DES">DES</A></DT>
 536 <DD>The <B>D</B>ata <B>E</B>ncryption <B>S</B>tandard, a <A href="#block">
 537 block cipher</A> with 64-bit blocks and a 56-bit key.  Probably the
 538 most widely used <A href="#symmetric">symmetric  cipher</A> ever
 539 devised. DES has been a US government standard for  their own use (only
 540 for unclassified data), and for some regulated  industries such as
 541 banking, since the late 70's. </DD>
 542 <P><A href="politics.html#desnotsecure">DES is seriously insecure
 543 against current  attacks.</A></P>
 544 <P><A href="web.html#FreeSWAN">Linux FreeS/WAN</A> does not include
 545 DES, even  though the RFCs specify it. <B>We strongly recommend that
 546 single DES  not be used.</B></P>
 547 <P>See also <A href="#3DES">3DES</A> and <A href="#DESX">DESX</A>,
 548  stronger ciphers based on DES.</P>
 549 <DT><A name="DESX">DESX</A></DT>
 550 <DD>An improved <A href="#DES">DES</A> suggested by Ron Rivest of RSA
 551  Data Security. It XORs extra key material into the text before and
 552  after applying the DES cipher. </DD>
 553 <P>This is not required by the <A href="#IPSEC">IPSEC</A> RFCs and not
 554  currently used in <A href="web.html#FreeSWAN">Linux FreeS/WAN</A>.
 555 DESX would  be the easiest additional transform to add; there would be
 556 very little  code to write. It would be much faster than 3DES and
 557 almost certainly  more secure than DES. However, since it is not in the
 558 RFCs other IPSEC  implementations cannot be expected to have it.</P>
 559 <DT>DH</DT>
 560 <DD>see <A href="#DH">Diffie-Hellman</A></DD>
 561 <DT><A name="DH">Diffie-Hellman (DH) key exchange protocol</A></DT>
 562 <DD>A protocol that allows two parties without any initial shared
 563 secret  to create one in a manner immune to eavesdropping. Once they
 564 have done  this, they can communicate privately by using that shared
 565 secret as a  key for a block cipher or as the basis for key exchange. </DD>
 566 <P>The protocol is secure against all <A href="#passive">passive
 567  attacks</A>, but it is not at all resistant to active <A href="#middle">
 568 man-in-the-middle attacks</A>. If a third party can  impersonate Bob to
 569 Alice and vice versa, then no useful secret can be  created.
 570 Authentication of the participants is a prerequisite for safe
 571  Diffie-Hellman key exchange. IPSEC can use any of several <A href="#authentication">
 572 authentication</A> mechanisims. Those supported  by FreeS/WAN are
 573 discussed in our <A href="config.html#choose">configuration</A> section.</P>
 574 <P>The Diffie-Hellman key exchange is based on the <A href="#dlog">
 575 discrete logarithm</A> problem and is secure unless  someone finds an
 576 efficient solution to that problem.</P>
 577 <P>Given a prime <VAR>p</VAR> and generator <VAR>g</VAR> (explained
 578  under <A href="#dlog">discrete log</A> below), Alice:</P>
 579 <UL>
 580 <LI>generates a random number <VAR>a</VAR></LI>
 581 <LI>calculates <VAR>A = g^a modulo p</VAR></LI>
 582 <LI>sends <VAR>A</VAR> to Bob</LI>
 583 </UL>
 584 <P>Meanwhile Bob:</P>
 585 <UL>
 586 <LI>generates a random number <VAR>b</VAR></LI>
 587 <LI>calculates <VAR>B = g^b modulo p</VAR></LI>
 588 <LI>sends <VAR>B</VAR> to Alice</LI>
 589 </UL>
 590 <P>Now Alice and Bob can both calculate the shared secret <VAR>s =
 591  g^(ab)</VAR>. Alice knows <VAR>a</VAR> and <VAR>B</VAR>, so she
 592  calculates <VAR>s = B^a</VAR>. Bob knows <VAR>A</VAR> and <VAR>b</VAR>
 593  so he calculates <VAR>s = A^b</VAR>.</P>
 594 <P>An eavesdropper will know <VAR>p</VAR> and <VAR>g</VAR> since these
 595  are made public, and can intercept <VAR>A</VAR> and <VAR>B</VAR> but,
 596  short of solving the <A href="#dlog">discrete log</A> problem, these
 597  do not let him or her discover the secret <VAR>s</VAR>.</P>
 598 <DT><A name="signature">Digital signature</A></DT>
 599 <DD>Sender:
 600 <UL>
 601 <LI>calculates a <A href="#digest">message digest</A> of a  document</LI>
 602 <LI>encrypts the digest with his or her private key, using some <A href="#public">
 603 public key cryptosystem</A>.</LI>
 604 <LI>attaches the encrypted digest to the document as a  signature</LI>
 605 </UL>
 606 </DD>
 607 <P>Receiver:</P>
 608 <UL>
 609 <LI>calculates a digest of the document (not including the  signature)</LI>
 610 <LI>decrypts the signature with the signer's public key</LI>
 611 <LI>verifies that the two results are identical</LI>
 612 </UL>
 613 <P>If the public-key system is secure and the verification succeeds,
 614  then the receiver knows</P>
 615 <UL>
 616 <LI>that the document was not altered between signing and  verification</LI>
 617 <LI>that the signer had access to the private key</LI>
 618 </UL>
 619 <P>Such an encrypted message digest can be treated as a signature
 620  since it cannot be created without <EM>both</EM> the document <EM> and</EM>
 621  the private key which only the sender should possess. The <A href="web.html#legal">
 622  legal issues</A> are complex, but several countries  are moving in the
 623 direction of legal recognition for digital  signatures.</P>
 624 <DT><A name="dlog">discrete logarithm problem</A></DT>
 625 <DD>The problem of finding logarithms in a finite field. Given a field
 626  defintion (such definitions always include some operation analogous to
 627  multiplication) and two numbers, a base and a target, find the power
 628  which the base must be raised to in order to yield the target. </DD>
 629 <P>The discrete log problem is the basis of several cryptographic
 630  systems, including the <A href="#DH">Diffie-Hellman</A> key exchange
 631  used in the <A href="#IKE">IKE</A> protocol. The useful property is
 632  that exponentiation is relatively easy but the inverse operation,
 633  finding the logarithm, is hard. The cryptosystems are designed so that
 634  the user does only easy operations (exponentiation in the field) but
 635  an attacker must solve the hard problem (discrete log) to crack the
 636  system.</P>
 637 <P>There are several variants of the problem for different types of
 638  field. The IKE/Oakley key determination protocol uses two variants,
 639  either over a field modulo a prime or over a field defined by an
 640  elliptic curve. We give an example modulo a prime below. For the
 641  elliptic curve version, consult an advanced text such as <A href="biblio.html#handbook">
 642 Handbook of Applied Cryptography</A>.</P>
 643 <P>Given a prime <VAR>p</VAR>, a generator <VAR>g</VAR> for the field
 644  modulo that prime, and a number <VAR>x</VAR> in the field, the problem
 645  is to find <VAR>y</VAR> such that <VAR>g^y = x</VAR>.</P>
 646 <P>For example, let p = 13. The field is then the integers from 0 to
 647  12. Any integer equals one of these modulo 13. That is, the remainder
 648  when any integer is divided by 13 must be one of these.</P>
 649 <P>2 is a generator for this field.  That is, the powers of two modulo
 650  13 run through all the non-zero numbers in the field. Modulo 13 we
 651  have:</P>
 652 <PRE>          y      x
 653         2^0  ==  1
 654         2^1  ==  2
 655         2^2  ==  4
 656         2^3  ==  8
 657         2^4  ==  3 that is, the remainder from 16/13 is 3
 658         2^5  ==  6          the remainder from 32/13 is 6
 659         2^6  == 12 and so on
 660         2^7  == 11
 661         2^8  ==  9
 662         2^9  ==  5
 663         2^10 == 10
 664         2^11 ==  7
 665         2^12 ==  1</PRE>
 666 <P> Exponentiation in such a field is not difficult. Given, say, <NOBR><VAR>
 667 y = 11</VAR>,</NOBR> calculating <NOBR><VAR>x = 7</VAR></NOBR> is
 668 straightforward. One method is just to calculate <NOBR><VAR>2^11 = 2048</VAR>
 669 ,</NOBR> then <NOBR><VAR>2048 mod 13 == 7</VAR>.</NOBR> When the field
 670 is modulo a large prime (say a few 100 digits) you need a silghtly
 671 cleverer method and even that is moderately expensive in computer time,
 672 but the calculation is still not  problematic in any basic way.</P>
 673 <P> The discrete log problem is the reverse. In our example, given <NOBR>
 674 <VAR>x = 7</VAR>,</NOBR> find the logarithm <NOBR><VAR>y = 11</VAR>.</NOBR>
 675  When the  field is modulo a large prime (or is based on a suitable
 676 elliptic  curve), this is indeed problematic. No solution method that
 677 is not  catastrophically expensive is known. Quite a few mathematicians
 678 have  tackled this problem. No efficient method has been found and
 679 mathematicians  do not expect that one will be. It seems likely no
 680 efficient solution  to either of the main variants the discrete log
 681 problem exists.</P>
 682 <P>Note, however, that no-one has proven such methods do not exist. If
 683  a solution to either variant were found, the security of any crypto
 684  system using that variant would be destroyed.  This is one reason <A href="#IKE">
 685  IKE</A> supports two variants. If one is broken, we can  switch to the
 686 other.</P>
 687 <DT><A name="DNS">DNS</A></DT>
 688 <DD><B>D</B>omain <B>N</B>ame <B>S</B>ervice, a distributed database
 689  through which names are associated with numeric addresses and other
 690  information in the Internet Protocol Suite. See also <A href="#BIND">
 691 BIND</A>, the Berkeley Internet Name Daemon which  implements DNS
 692 services and <A href="#SDNS">Secure DNS</A>. See our  bibliography for
 693 a <A href="biblio.html#DNS.book">useful reference</A> on  both.</DD>
 694 <DT>DOS attack</DT>
 695 <DD>see <A href="ipsec.html#DOS">Denial Of Service</A> attack</DD>
 696 <DT><A name="E">E</A></DT>
 697 <DT><A name="EAR"><A name="E2"></A><A name="E">EAR</A></DT>
 698 <DD>The US government's <B>E</B>xport <B>A</B>dministration <B> R</B>
 699 egulations, administered by the <A href="#BXA">Bureau of  Export
 700 Administration</A>. These have replaced the earlier <A href="#ITAR">ITAR</A>
 701  regulations as the controls on export of  cryptography.</DD>
 702 <DT><A name="ECB">ECB mode</A></DT>
 703 <DD><B>E</B>lectronic <B>C</B>ode<B>B</B>ook mode, the simplest way to
 704  use a block cipher. See <A href="#mode">Cipher Modes</A>.</DD>
 705 <DT><A name="EDE">EDE</A></DT>
 706 <DD>The sequence of operations normally used in either the three-key
 707  variant of <A href="#3DES">triple DES</A> used in <A href="#IPSEC">
 708 IPSEC</A> or the <A href="#2key">two-key</A> variant  used in some
 709 other systems. </DD>
 710 <P>The sequence is:</P>
 711 <UL>
 712 <LI><B>E</B>ncrypt with key1</LI>
 713 <LI><B>D</B>ecrypt with key2</LI>
 714 <LI><B>E</B>ncrypt with key3</LI>
 715 </UL>
 716 <P>For the two-key version, key1=key3.</P>
 717 <P>The &quot;advantage&quot; of this EDE order of operations is that it makes it
 718  simple to interoperate with older devices offering only single DES.
 719  Set key1=key2=key3 and you have the worst of both worlds, the overhead
 720  of triple DES with the security of single DES. Since <A href="politics.html#desnotsecure">
 721 single DES is insecure</A>, this is an extremely  dubious &quot;advantage&quot;.</P>
 722 <P>The EDE two-key variant can also interoperate with the EDE
 723  three-key variant used in <A href="#IPSEC">IPSEC</A>; just set  k1=k3.</P>
 724 <DT><A name="Entrust"><A href="http://www.entrust.com">Entrust</A></A></DT>
 725 <DD>A Canadian company offerring enterprise <A href="ipsec.html#PKI">PKI</A>
 726  products using <A href="#CAST128">CAST-128</A> symmetric crypto, <A href="#RSA">
 727 RSA</A> public key and <A href="#X509">X.509</A> directories.</DD>
 728 <DT><A name="EFF">EFF</A></DT>
 729 <DD><A href="http://www.eff.org">Electronic Frontier Foundation</A>, an
 730  advocacy group for civil rights in cyberspace.</DD>
 731 <DT><A name="encryption">Encryption</A></DT>
 732 <DD>Techniques for converting a readable message (<A href="#plaintext">
 733 plaintext</A>) into apparently random material (<A href="#ciphertext">
 734 ciphertext</A>) which cannot be read if  intercepted. A key is required
 735 to read the message. </DD>
 736 <P>Major variants include <A href="#symmetric">symmetric</A> encryption
 737 in which sender and receiver use the same secret key and <A href="#public">
 738 public key</A> methods in which the sender uses one of  a matched pair
 739 of keys and the receiver uses the other. Many current  systems,
 740 including <A href="#IPSEC">IPSEC</A>, are <A href="#hybrid">hybrids</A>
 741  combining the two techniques.</P>
 742 <DT><A name="ESP">ESP</A></DT>
 743 <DD><B>E</B>ncapsulated <B>S</B>ecurity <B>P</B>ayload, the <A href="#IPSEC">
 744 IPSEC</A> protocol which provides <A href="#encryption">encryption</A>.
 745 It can also provide <A href="#authentication">authentication</A>
 746  service and may be used with  null encryption (which we do not
 747 recommend). For details see our <A href="#ESP">IPSEC Overview</A>
 748  document and/or RFC 2406.</DD>
 749 <DT><A name="extruded">Extruded subnet</A></DT>
 750 <DD>A situation in which something IP sees as one network is actually
 751 in  two or more places. </DD>
 752 <P>For example, the Internet may route all traffic for a particular
 753  company to that firm's corporate gateway. It then becomes the
 754  company's problem to get packets to various machines on their <A href="#subnet">
 755 subnets</A> in various departments. They may decide to  treat a branch
 756 office like a subnet, giving it IP addresses &quot;on&quot; their  corporate net.
 757 This becomes an extruded subnet.</P>
 758 <P>Packets bound for it are delivered to the corporate gateway, since
 759  as far as the outside world is concerned, that subnet is part of the
 760  corporate network. However, instead of going onto the corporate LAN
 761  (as they would for, say, the accounting department) they are then
 762  encapsulated and sent back onto the Internet for delivery to the
 763  branch office.</P>
 764 <P>For information on doing this with Linux FreeS/WAN, look in our <A href="#extruded">
 765 Configuration</A> file.</P>
 766 <DT>Exhaustive search</DT>
 767 <DD>See <A href="#brute">brute force attack</A>.</DD>
 768 <DT><A name="F">F</A></DT>
 769 <DT><A name="FIPS"><A name="F">FIPS</A></A></DT>
 770 <DD><B>F</B>ederal <B>I</B>nformation <B>P</B>rocessing <B>S</B>
 771 tandard,  the US government's standards for products it buys. These are
 772 issued  by <A href="#NIST">NIST</A>. Among other things, <A href="#DES">
 773 DES</A> and <A href="#SHA">SHA</A> are defined in FIPS  documents. NIST
 774 have a <A href="http://www.itl.nist.gov/div897/pubs">FIPS home page</A>.</DD>
 775 <DT><A name="FSF">Free Software Foundation (FSF)</A></DT>
 776 <DD>An organisation to promote free software, free in the sense of
 777 these  quotes from their web pages</DD>
 778 <DD><BLOCKQUOTE> &quot;Free software&quot; is a matter of liberty, not price. To
 779 understand the  concept, you should think of &quot;free speech&quot;, not &quot;free
 780 beer.&quot;
 781 <P>&quot;Free software&quot; refers to the users' freedom to run, copy,
 782  distribute, study, change and improve the software.</P>
 783 </BLOCKQUOTE></DD>
 784 <P>See also <A href="#GNU">GNU</A>, <A href="#GPL">GNU General Public
 785  License</A>, and <A href="http://www.fsf.org">the FSF site</A>.</P>
 786 <DT>FreeSWAN</DT>
 787 <DD>see <A href="web.html#FreeSWAN">Linux FreeS/WAN</A></DD>
 788 <DT>FSF</DT>
 789 <DD>see <A href="#FSF">Free software Foundation</A></DD>
 790 <DT><A name="G">G</A></DT>
 791 <DT><A name="GCHQ"><A name="G">GCHQ</A></A></DT>
 792 <DD><A href="http://www.gchq.gov.uk">Government Communications
 793  Headquarters</A>, the British organisation for <A href="#SIGINT">
 794 signals intelligence</A>.</DD>
 795 <DT>generator of a prime field</DT>
 796 <DD>see <A href="#dlog">discrete logarithm problem</A></DD>
 797 <DT><A name="GILC">GILC</A></DT>
 798 <DD><A href="http://www.gilc.org">Global Internet Liberty Campaign</A>,
 799  an international organisation advocating, among other things, free
 800  availability of cryptography. They have a <A href="http://www.gilc.org/crypto/wassenaar">
 801 campaign</A> to remove  cryptographic software from the <A href="politics.html#Wassenaar">
 802 Wassenaar  Arrangement</A>.</DD>
 803 <DT>Global Internet Liberty Campaign</DT>
 804 <DD>see <A href="#GILC">GILC</A>.</DD>
 805 <DT><A name="GTR"><A href="http://www.cl.cam.ac.uk/Research/Security/Trust-Register">
 806 Global  Trust Register</A></A></DT>
 807 <DD>An attempt to create something like a <A href="#rootCA">root CA</A>
 808  for <A href="#PGP">PGP</A> by publishing both <A href="#GTR">as a  book</A>
 809  and <A href="http://www.cl.cam.ac.uk/Research/Security/Trust-Register">
 810  on  the web</A> the fingerprints of a set of verified keys for
 811 well-known  users and organisations.</DD>
 812 <DT>GMP</DT>
 813 <DD>The <B>G</B>NU <B>M</B>ulti-<B>P</B>recision library code, used in <A
 814 href="web.html#FreeSWAN"> Linux FreeS/WAN</A> by <A href="#Pluto">Pluto</A>
 815  for <A href="#public">public key</A> calculations.</DD>
 816 <DT><A name="GNU">GNU</A></DT>
 817 <DD><B>G</B>NU's <B>N</B>ot <B>U</B>nix, the <A href="#FSF">Free
 818  Software Foundation's</A> project aimed at creating a free system with
 819  at least the capabilities of Unix. <A href="#Linux">Linux</A> uses GNU
 820  utilities extensively.</DD>
 821 <DT>GPG</DT>
 822 <DD>see <A href="#GPG">GNU Privacy Guard</A></DD>
 823 <DT><A name="GPL">GNU <A href="http://www.fsf.org/copyleft/gpl.html">
 824  General  Public License</A>(GPL, copyleft)</A></DT>
 825 <DD>The license developed by the <A href="#FSF">Free Software
 826  Foundation</A> under which <A href="#Linux">Linux</A>, <A href="web.html#FreeSWAN">
 827 Linux FreeS/WAN</A> and many other pieces of software  are distributed.
 828 The license allows anyone to redistribute and modify  the code, but
 829 forbids anyone from distributing executables without  providing access
 830 to source code. For more details see the file <A href="../COPYING">
 831 COPYING</A> included with GPLed source  distributions, including ours,
 832 or <A href="http://www.fsf.org/copyleft/gpl.html"> the GNU site's GPL
 833  page</A>.</DD>
 834 <DT><A name="GPG"><A href="http://www.gnupg.org">GNU Privacy Guard</A></A>
 835 </DT>
 836 <DD>An open source implementation of Open <A href="#PGP">PGP</A> as
 837  defined in RFC 2440.</DD>
 838 <DT>GPL</DT>
 839 <DD>see <A href="#GPL">GNU General Public License</A>.</DD>
 840 <DT><A name="H">H</A></DT>
 841 <DT><A name="hash">Hash</A></DT>
 842 <DD>see <A href="#digest">message digest</A></DD>
 843 <DT><A name="HMAC">Hashed Message Authentication Code (HMAC)</A></DT>
 844 <DD>using keyed <A href="#digest">message digest</A> functions to
 845  authenticate a message. This differs from other uses of these
 846  functions:
 847 <UL>
 848 <LI>In normal usage, the hash function's internal variable are
 849  initialised in some standard way. Anyone can reproduce the hash to
 850  check that the message has not been altered.</LI>
 851 <LI>For HMAC usage, you initialise the internal variables from the
 852  key. Only someone with the key can reproduce the hash. A  successful
 853 check of the hash indicates not only that the message  is unchanged but
 854 also that the creator knew the key.</LI>
 855 </UL>
 856 </DD>
 857 <P>The exact techniques used in <A href="#IPSEC">IPSEC</A> are defined
 858  in RFC 2104. They are referred to as HMAC-MD5-96 and HMAC-SHA-96
 859  because they output only 96 bits of the hash. This makes some attacks
 860  on the hash functions harder.</P>
 861 <DT>HMAC</DT>
 862 <DD>see <A href="#HMAC">Hashed Message Authentication Code</A></DD>
 863 <DT>HMAC-MD5-96</DT>
 864 <DD>see <A href="#HMAC">Hashed Message Authentication Code</A></DD>
 865 <DT>HMAC-SHA-96</DT>
 866 <DD>see <A href="#HMAC">Hashed Message Authentication Code</A></DD>
 867 <DT><A name="hybrid">Hybrid cryptosystem</A></DT>
 868 <DD>A system using both <A href="#public">public key</A> and <A href="#symmetric">
 869 symmetric cipher</A> techniques. This works well.  Public key methods
 870 provide key management and <A href="#signature">digital signature</A>
 871  facilities which are not  readily available using symmetric ciphers.
 872 The symmetric cipher,  however, can do the bulk of the encryption work
 873 much more efficiently  than public key methods.</DD>
 874 <DT><A name="I">I</A></DT>
 875 <DT><A name="IAB">IAB</A></DT>
 876 <DD><A href="http://www.iab.org/iab">Internet Architecture  Board</A>.</DD>
 877 <DT><A name="icmp">ICMP</A></DT>
 878 <DD><STRONG>I</STRONG>nternet <STRONG>C</STRONG>ontrol <STRONG> M</STRONG>
 879 essage <STRONG>P</STRONG>rotocol. This is used for  various
 880 IP-connected devices to manage the network.</DD>
 881 <DT><A name="IDEA">IDEA</A></DT>
 882 <DD><B>I</B>nternational <B>D</B>ata <B>E</B>ncrypion <B>A</B>lgorithm,
 883  developed in Europe as an alternative to exportable American ciphers
 884  such as <A href="#DES">DES</A> which were <A href="politics.html#desnotsecure">
 885 too  weak for serious use</A>. IDEA is a <A href="#block">block cipher</A>
 886  using 64-bit blocks and 128-bit keys, and is used in products such as <A
 887 href="#PGP"> PGP</A>. </DD>
 888 <P>IDEA is not required by the <A href="#IPSEC">IPSEC</A> RFCs and not
 889  currently used in <A href="web.html#FreeSWAN">Linux FreeS/WAN</A>.</P>
 890 <P>IDEA is patented and, with strictly limited exceptions for personal
 891  use, using it requires a license from <A href="http://www.ascom.com">
 892 Ascom</A>.</P>
 893 <DT><A name="IESG">IESG</A></DT>
 894 <DD><A href="http://www.ietf.org">Internet Engineering Steering  Group</A>
 895 .</DD>
 896 <DT><A name="IETF">IETF</A></DT>
 897 <DD><A href="http://www.ietf.org">Internet Engineering Task Force</A>,
 898  the umbrella organisation whose various working groups make most of
 899  the technical decisions for the Internet. The IETF <A href="http://www.ietf.org/html.charters/ipsec-charter.html">
 900  IPSEC  working group</A> wrote the <A href="rfc.html#RFC">RFCs</A> we
 901 are  implementing.</DD>
 902 <DT><A name="IKE">IKE</A></DT>
 903 <DD><B>I</B>nternet <B>K</B>ey <B>E</B>xchange, based on the <A href="#DH">
 904 Diffie-Hellman</A> key exchange protocol. IKE is  implemented in <A href="web.html#FreeSWAN">
 905 Linux FreeS/WAN</A> by the <A href="#Pluto">Pluto daemon</A>.</DD>
 906 <DT><A name="IV">Initialisation Vector (IV)</A></DT>
 907 <DD>Some cipher <A href="#mode">modes</A>, including the <A href="#CBC">
 908 CBC</A> mode which IPSEC uses, require some extra data at  the
 909 beginning. This data is called the initialisation vector. It need  not
 910 be secret, but should be different for each message. Its function  is
 911 to prevent messages which begin with the same text from encrypting  to
 912 the same ciphertext. That might give an analyst an opening, so it  is
 913 best prevented.</DD>
 914 <DT><A name="IP">IP</A></DT>
 915 <DD><B>I</B>nternet <B>P</B>rotocol.</DD>
 916 <DT><A name="masq">IP masquerade</A></DT>
 917 <DD>A method of allowing multiple machines to communicate over the
 918  Internet when only one IP address is available for their use. See the
 919  Linux masquerade <A href="http://www.tor.shaw.wave.ca/~ambrose">
 920 resource page</A> for  details. </DD>
 921 <P>The client machines are set up with reserved <A href="non-routable">
 922 non-routable</A> IP addresses defined in RFC 1918.  The masquerading
 923 gateway, the machine with the actual link to the  Internet, rewrites
 924 packet headers so that all packets going onto the  Internet appear to
 925 come from one IP address, that of its Internet  interface. It then gets
 926 all the replies, does some table lookups and  more header rewriting,
 927 and delivers the replies to the appropriate  client machines.</P>
 928 <P> For information on using masquerade with Linux FreeS/WAN, see our <A href="firewall.html#NAT">
 929  firewall document</A> and the <A href="faq.html#masq.faq">FAQ</A> and.</P>
 930 <DT><A name="IPng">IPng</A></DT>
 931 <DD>&quot;IP the Next Generation&quot;, see <A href="#ipv6.gloss">IPv6</A>.</DD>
 932 <DT><A name="IPv4">IPv4</A></DT>
 933 <DD>The current version of the <A href="#IP">Internet protocol  suite</A>
 934 .</DD>
 935 <DT><A name="ipv6.gloss">IPv6 (IPng)</A></DT>
 936 <DD>Version six of the <A href="#IP">Internet protocol suite</A>,
 937  currently being developed. It will replace the current <A href="#IPv4">
 938 version four</A>. IPv6 has <A href="#IPSEC">IPSEC</A> as  a mandatory
 939 component. </DD>
 940 <P>See this <A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">
 941 web  site</A> for more details, and our <A href="compat.html#ipv6">
 942 compatibility</A> document for information on FreeS/WAN and the Linux
 943 implementation of  IPv6.</P>
 944 <DT><A name="IPSEC">IPSEC</A></DT>
 945 <DD><B>I</B>nternet <B>P</B>rotocol <B>SEC</B>urity, security functions
 946  (<A href="#authentication">authentication</A> and <A href="#encryption">
 947 encryption</A>) implemented at the IP level of the  protocol stack. It
 948 is optional for <A href="#IPv4">IPv4</A> and  mandatory for <A href="#ipv6.gloss">
 949 IPv6</A>. </DD>
 950 <P>This is the standard <A href="web.html#FreeSWAN">Linux FreeS/WAN</A>
 951  is  implementing. For more details, see our <A href="web.html#overview">
 952 IPSEC  Overview</A>. For the standards, see RFCs listed in our <A href="rfc.html#RFC">
 953 RFCs document</A>.</P>
 954 <DT><A name="ISAKMP">ISAKMP</A></DT>
 955 <DD><B>I</B>nternet <B>S</B>ecurity <B>A</B>ssociation and <B>K</B>ey <B>
 956  M</B>anagement <B>P</B>rotocol, defined in RFC 2408.</DD>
 957 <DT><A name="ITAR">ITAR</A></DT>
 958 <DD><B>I</B>nternational <B>T</B>raffic in <B>A</B>rms <B> R</B>
 959 egulations, US regulations administered by the State  Department which
 960 until recently limited export of, among other things,  cryptographic
 961 technology and software. ITAR still exists, but the  limits on
 962 cryptography have now been transferred to the <A href="#EAR">Export
 963 Administration Regulations</A> under the Commerce  Department's <A href="#BXA">
 964 Bureau of Export Administration</A>.</DD>
 965 <DT>IV</DT>
 966 <DD>see <A href="#IV">Initialisation vector</A></DD>
 967 <DT><A name="J">J</A></DT>
 968 <DT><A name="K">K</A></DT>
 969 <DT><A name="kernel">Kernel</A></DT>
 970 <DD>The basic part of an operating system (e.g. Linux) which controls
 971  the hardware and provides services to all other programs. </DD>
 972 <P>In the Linux release numbering system, an even second digit as in  2.<STRONG>
 973 2</STRONG>.x indicates a stable or production kernel while  an odd
 974 number as in 2.<STRONG>3</STRONG>.x indicates an experimental  or
 975 development kernel. Most users should run a recent kernel version  from
 976 the production series. The development kernels are primarily for
 977  people doing kernel development. Others should consider using
 978  development kernels only if they have an urgent need for some feature
 979  not yet available in production kernels.</P>
 980 <DT>Keyed message digest</DT>
 981 <DD>See <A href="#HMAC">HMAC</A>.</DD>
 982 <DT>Key length</DT>
 983 <DD>see <A href="#brute">brute force attack</A></DD>
 984 <DT><A name="KLIPS">KLIPS</A></DT>
 985 <DD><B>K</B>erne<B>l</B><B> IP</B><B> S</B>ecurity, the <A href="web.html#FreeSWAN">
 986 Linux FreeS/WAN</A> project's changes to the <A href="#Linux">Linux</A>
 987  kernel to support the <A href="#IPSEC">IPSEC</A> protocols.</DD>
 988 <DT><A name="L">L</A></DT>
 989 <DT><A name="LDAP">LDAP</A></DT>
 990 <DD><B>L</B>ightweight <B>D</B>irectory <B>A</B>ccess <B>P</B>rotocol,
 991  defined in RFCs 1777 and 1778,  a method of accessing information
 992  stored in directories. LDAP is used by several <A href="ipsec.html#PKI">
 993 PKI</A> implementations, often with X.501 directories and <A href="#X509">
 994 X.509</A> certificates. It may also be used by <A href="#IPSEC">IPSEC</A>
 995  to obtain key certifications from those PKIs.  This is not yet
 996 implemented in <A href="web.html#FreeSWAN">Linux  FreeS/WAN</A>.</DD>
 997 <DT><A name="LIBDES">LIBDES</A></DT>
 998 <DD>A publicly available library of <A href="#DES">DES</A> code,
 999 written  by Eric Young, which <A href="web.html#FreeSWAN">Linux
1000 FreeS/WAN</A> uses in  both <A href="#KLIPS">KLIPS</A> and <A href="#Pluto">
1001 Pluto</A>.</DD>
1002 <DT><A name="Linux">Linux</A></DT>
1003 <DD>A freely available Unix-like operating system based on a kernel
1004  originally written for the Intel 386 architecture by (then) student
1005  Linus Torvalds. Once his 32-bit kernel was available, the <A href="#GNU">
1006 GNU</A> utilities made it a usable system and  contributions from many
1007 others led to explosive growth. </DD>
1008 <P>Today Linux is a complete Unix replacement available for several
1009  CPU architectures -- Intel, DEC/Compaq Alpha, Power PC, both 32-bit
1010  SPARC and the 64-bit UltraSPARC, SrongARM, . . . -- with support for
1011  multiple CPUs on some architectures.</P>
1012 <P><A href="web.html#FreeSWAN">Linux FreeS/WAN</A> is intended to run
1013 on all  CPUs supported by Linux and is known to work on several. See
1014 our <A href="compat.html#CPUs"> compatibility</A> section for a list.</P>
1015 <DT><A name="FreeSWAN">Linux FreeS/WAN</A></DT>
1016 <DD>Our implementation of the <A href="#IPSEC">IPSEC</A> protocols,
1017  intended to be freely redistributable source code with <A href="#GPL">
1018 a GNU GPL license</A> and no constraints under US or other <A href="politics.html#exlaw">
1019  export laws</A>. Linux FreeS/WAN is intended to  interoperate with
1020 other <A href="#IPSEC">IPSEC</A> implementations.  The name is partly
1021 taken, with permission, from the <A href="#SWAN">S/WAN</A> multi-vendor
1022 IPSEC compatability effort. Linux  FreeS/WAN has two major components, <A
1023 href="#KLIPS">KLIPS</A> (KerneL  IPSEC Support) and the <A href="#Pluto">
1024 Pluto</A> daemon which manages  the whole thing. </DD>
1025 <P>See our <A href="web.html#overview">IPSEC Overview</A> for more
1026 detail. For  the code see our <A href="http://freeswan.org"> primary
1027 distribution  site</A> or one of the mirror sites on <A href="intro.html#mirrors">
1028  this  list</A>.</P>
1029 <DT><A name="M">M</A></DT>
1030 <DT><A name="list">Mailing list</A></DT>
1031 <DD>The <A href="web.html#FreeSWAN">Linux FreeS/WAN</A> project has
1032 several  public email lists for bug reports and software development
1033  discussions. See our document on <A href="mail.html">mailing lists</A>.</DD>
1034 <DT><A name="middle">Man-in-the-middle attack</A></DT>
1035 <DD>An <A href="#active">active attack</A> in which the attacker
1036  impersonates each of the legitimate players in a protocol to the
1037  other. </DD>
1038 <P>For example, if <A href="#alicebob">Alice and Bob</A> are
1039  negotiating a key via the <A href="#DH">Diffie-Hellman</A> key
1040  agreement, and are not using <A href="#authentication">authentication</A>
1041  to be certain they are  talking to each other, then an attacker able
1042 to insert himself in the  communication path can deceive both players.</P>
1043 <P>Call the attacker Mallory. For Bob, he pretends to be Alice. For
1044  Alice, he pretends to be Bob. Two keys are then negotiated,
1045  Alice-to-Mallory and Bob-to-Mallory. Alice and Bob each think the key
1046  they have is Alice-to-Bob.</P>
1047 <P>A message from Alice to Bob then goes to Mallory who decrypts it,
1048  reads it and/or saves a copy, re-encrypts using the Bob-to-Mallory key
1049  and sends it along to Bob. Bob decrypts successfully and sends a reply
1050  which Mallory decrypts, reads, re-encrypts and forwards to Alice.</P>
1051 <P>To make this attack effective, Mallory must</P>
1052 <UL>
1053 <LI>subvert some part of the network in some way that lets him carry
1054  out the deception
1055 <BR> possible targets: DNS, router, Alice or Bob's machine, mail
1056  server, ...</LI>
1057 <LI>beat any authentication mechanism Alice and Bob use
1058 <BR> strong authentication defeats the attack entirely; this is why <A href="#IKE">
1059 IKE</A> requires authentication</LI>
1060 <LI>work in real time, delivering messages without introducing  a delay
1061 large enough to alert the victims
1062 <BR> not hard if Alice and Bob are using email; quite difficult in some
1063  situations.</LI>
1064 </UL>
1065 <P>If he manages it, however, it is devastating. He not only gets to
1066  read all the messages; he can alter messages, inject his own, forge
1067  anything he likes, . . . In fact, he controls the communication
1068  completely.</P>
1069 <DT><A name="manual">Manual keying</A></DT>
1070 <DD>An IPSEC mode in which the keys are provided by the administrator.
1071  In FreeS/WAN, they are stored in /etc/ipsec.conf. The alternative, <A href="ipsec.html#auto">
1072 automatic keying</A>, is preferred in most cases.</DD>
1073 <DT><A name="MD4">MD4</A></DT>
1074 <DD><A href="#digest">Message Digest Algorithm</A> Four from Ron Rivest
1075  of <A href="#RSAco">RSA</A>. MD4 was widely used a few years ago, but
1076  is now considered obsolete. It has been replaced by its descendants <A href="#MD5">
1077 MD5</A> and <A href="#SHA">SHA</A>.</DD>
1078 <DT><A name="MD5">MD5</A></DT>
1079 <DD><A href="#digest">Message Digest Algorithm</A> Five from Ron Rivest
1080  of <A href="#RSAco">RSA</A>, an improved variant of his <A href="#MD4">
1081 MD4</A>. Like MD4, it produces a 128-bit hash. For details  see RFC
1082 1321. </DD>
1083 <P>MD5 is one of two message digest algorithms available in IPSEC. The
1084  other is <A href="#SHA">SHA</A>. SHA produces a longer hash and is
1085  therefore more resistant to <A href="#birthday">birthday attacks</A>,
1086  but this is not a concern for IPSEC. The <A href="#HMAC">HMAC</A>
1087  method used in IPSEC is secure even if the underlying hash is not
1088  particularly strong against this attack.</P>
1089 <DT><A name="meet">Meet-in-the-middle attack</A></DT>
1090 <DD>A divide-and-conquer attack which breaks a cipher into two parts,
1091  works against each separately, and compares results. Probably the best
1092  known example is an attack on double DES. This applies in principle to
1093  any pair of block ciphers, e.g. to an encryption system using, say,
1094  CAST-128 and Blowfish, but we will describe it for double DES. </DD>
1095 <P>Double DES encryption and decryption can be written:</P>
1096 <PRE>        C = E(k2,E(k1,P))
1097         P = D(k1,D(k2,C))</PRE>
1098 <P>Where C is ciphertext, P is plaintext, E is encryption, D is
1099  decryption, k1 is one key, and k2 is the other key. If we know a P, C
1100  pair, we can try and find the keys with a brute force attack, trying
1101  all possible k1, k2 pairs. Since each key is 56 bits, there are  2<SUP>
1102 112</SUP> such pairs and this attack is painfully  inefficient.</P>
1103 <P>The meet-in-the middle attack re-writes the equations to calculate
1104  a middle value M:</P>
1105 <PRE>        M = E(k1,P)
1106         M = D(k2,C)</PRE>
1107 <P>Now we can try some large number of D(k2,C) decryptions with
1108  various values of k2 and store the results in a table. Then start
1109  doing E(k1,P) encryptions, checking each result to see if it is in the
1110  table.</P>
1111 <P>With enough table space, this breaks double DES with 2<SUP>57</SUP>
1112  work. The memory requirements of such attacks can be prohibitive, but
1113  there is a whole body of research literature on methods of reducing
1114  them.</P>
1115 <DT><A name="digest">Message Digest Algorithm</A></DT>
1116 <DD>An algorithm which takes a message as input and produces a hash or
1117  digest of it, a fixed-length set of bits which depend on the message
1118  contents in some highly complex manner. Design criteria include making
1119  it extremely difficult for anyone to counterfeit a digest or to change
1120  a message without altering its digest. One essential property is <A href="#collision">
1121 collision resistance</A>. The main applications are  in message <A href="#authentication">
1122 authentication</A> and <A href="#signature">digital signature</A>
1123  schemes. Widely used  algorithms include <A href="#MD5">MD5</A> and <A href="#SHA">
1124 SHA</A>.  In IPSEC, message digests are used for <A href="#HMAC">HMAC</A>
1125  authentication of packets.</DD>
1126 <DT><A name="MTU">MTU</A></DT>
1127 <DD><STRONG>M</STRONG>aximum <STRONG>T</STRONG>ransmission <STRONG> U</STRONG>
1128 nit, the largest size of packet that can be sent  over a link. This is
1129 determined by the underlying network, but must be  taken account of at
1130 the IP level. </DD>
1131 <P>IP packets, which can be up to 64K bytes each, must be packaged
1132  into lower-level packets of the appropriate size for the underlying
1133  network(s) and re-assembled on the other end. When a packet must pass
1134  over multiple networks, each with its own MTU, and many of the MTUs
1135  are unknown to the sender, this becomes a fairly complex problem. See <A
1136 href="#pathMTU"> path MTU discovery</A> for details.</P>
1137 <P>Often the MTU is a few hundred bytes on serial links and 1500  on
1138 Ethernet. There are, however, serial link protocols which use a  larger
1139 MTU to avoid fragmentation at the ethernet/serial  boundary, and newer
1140 (especially gigabit) Ethernet networks sometimes  support much larger
1141 packets because these are more efficient in some  applications.</P>
1142 <DT><A name="N">N</A></DT>
1143 <DT><A name="NAI">NAI</A></DT>
1144 <DD><A href="http://www.nai.com">Network Associates</A>, a conglomerate
1145  formed from <A href="#PGPI">PGP Inc.</A>, <A href="firewall.html#">TIS</A>
1146 ,  Macaffee Anti-virus products and several others. Among other things,
1147  they offer an IPSEC-based <A href="http://www.nai.com/products/security/prodserv/gauntlet/vpn/index.asp">
1148 VPN</A>.</DD>
1149 <DT><A name="NAT.gloss">NAT</A></DT>
1150 <DD><B>N</B>etwork <B>A</B>ddress <B>T</B>ranslation.</DD>
1151 <DT><A name="NIST">NIST</A></DT>
1152 <DD>The US <A href="http://www.nist.gov"> National Institute of
1153  Standards and Technology</A>, responsible for <A href="#FIPS">FIPS
1154  standards</A> including <A href="#DES">DES</A> and its replacement, <A href="#AES">
1155 AES</A>.</DD>
1156 <DT><A name="nonce">Nonce</A></DT>
1157 <DD>A <A href="#random">random</A> value used in an <A href="#authentication">
1158 authentication</A> protocol.</DD>
1159 <DT>
1160 <DT><A name="non-routable">Non-routable IP address</A></DT>
1161 <DD>An IP address not normally allowed in the &quot;to&quot; or &quot;from&quot; IP address
1162  field header of IP packets. </DD>
1163 <P>Almost invariably, the phrase &quot;non-routable address&quot; means one of
1164  the addresses reserved by RFC 1918 for private networks:</P>
1165 <UL>
1166 <LI>10.anything</LI>
1167 <LI>172.x.anything with 16 &lt;= x &lt;= 31</LI>
1168 <LI>192.168.anything</LI>
1169 </UL>
1170 <P>These addresses are commonly used on private networks, e.g. behind
1171  a Linux machines doing <A href="#masq">IP masquerade</A>. Machines
1172  within the private network can address each other with these
1173  addresses. All packets going outside that network, however, have these
1174  addresses replaced before they reach the Internet.</P>
1175 <P>If any packets using these addresses do leak out, they do not go
1176  far. Most routers automatically discard all such packets.</P>
1177 <P>Various other addresses -- the 127.0.0.0/8 block reserved for local
1178  use, 0.0.0.0, various broadcast and network addresses -- cannot be
1179  routed over the Internet, but are not normally included in the meaning
1180  when the phrase &quot;non-routable address&quot; is used.</P>
1181 <DT><A name="NSA">NSA</A></DT>
1182 <DD>The US <A href="http://www.nsa.gov"> National Security Agency</A>,
1183  the American organisation for <A href="#SIGINT">signals  intelligence</A>
1184 , the protection of US government messages and the  interception and
1185 analysis of other messages. For details, see  Bamford's <A href="biblio.html#puzzle">
1186 &quot;The Puzzle Palace&quot;</A>. </DD>
1187 <P>Some <A href="http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/index.html">
1188 history  of NSA</A> documents were declassified in response to a FOIA
1189 (Freedom  of Information Act) request.</P>
1190 <DT><A name="O">O</A></DT>
1191 <DT><A name="oakley">Oakley</A></DT>
1192 <DD>A key determination protocol, defined in RFC 2412.</DD>
1193 <DT>Oakley groups</DT>
1194 <DD>The groups used as the basis of <A href="#DH">Diffie-Hellman</A>
1195  key  exchange in the Oakley protocol, and in <A href="#IKE">IKE</A>.
1196 Four  were defined in the original RFC, and a fifth has been <A href="http://www.lounge.org/ike_doi_errata.html">
1197 added since</A>. </DD>
1198 <P>Linux FreeS/WAN currently supports the three groups based on finite
1199  fields modulo a prime (Groups 1, 2 and 5) and does not support the
1200  elliptic curve groups (3 and 4). For a description of the difference
1201  of the types, see <A href="#dlog">discrete logarithms</A>.</P>
1202 <DT><A name="OTP">One time pad</A></DT>
1203 <DD>A cipher in which the key is:
1204 <UL>
1205 <LI>as long as the total set of messages to be enciphered</LI>
1206 <LI>absolutely <A href="#random">random</A></LI>
1207 <LI>never re-used</LI>
1208 </UL>
1209 </DD>
1210 <P>Given those three conditions, it can easily be proved that the
1211  cipher is perfectly secure, in the sense that an attacker with
1212  intercepted message in hand has no better chance of guessing the
1213  message than an attacker who has nt interecepted the message and only
1214  knows the message length. No such proof exists for any other  cipher.</P>
1215 <P>There are, however, several problems with this &quot;perfect&quot;  cipher.</P>
1216 <UL>
1217 <LI>It is wildly impractical for many applications. Key management  is
1218 difficult or impossible.</LI>
1219 <LI>It is <EM>extremely</EM> fragile. Small changes which violate  the
1220 conditions listed above do not just weaken the cipher a bit;  quite
1221 often they destroy its security completely.
1222 <UL>
1223 <LI>Re-using the pad weakens it to the point where it can be  broken
1224 with pencil and paper. With a computer, the attack is  trivially easy.</LI>
1225 <LI>Using computer-generated pseudo-random numbers instead of a  really <A
1226 href="#random">random</A> pad completely invalidates  the security
1227 proof. Depending on random number generator used,  this may also give
1228 an extremely weak cipher.</LI>
1229 </UL>
1230 </LI>
1231 <LI>If an attacker knows the plaintext and has an intercepted  message,
1232 he can discover the pad. This does not matter if the  attacker is just
1233 a <A href="#passive">passive</A> eavesdropper. It  gives him no
1234 plaintext he didn't already know and we don't care  that he learns a
1235 pad which we'll never re-use. However, knowing  the pad lets an <A href="#active">
1236 active</A> attacker perform a <A href="#middle">man-in-the-middle</A>
1237  attack, replacing your  message with whatever he chooses.</LI>
1238 </UL>
1239 <P>Marketing claims about the &quot;unbreakable&quot; security of various
1240  products which somewhat resemble one-time pads are common. Such claims
1241  are one of the surest signs of cryptographic <A href="#snake">snake
1242  oil</A>. Systems marketed with such claims are usually completely
1243  worthless.</P>
1244 <P>See also the <A href="http://www.clark.net/pub/mjr/pubs/otpfaq/">one
1245 time pad  FAQ</A>.</P>
1246 <DT><A name="carpediem">Opportunistic encryption</A></DT>
1247 <DD>A situation in which any two IPSEC-aware machines can secure their
1248  communications, without a pre-shared secret and without a common <A href="ipsec.html#PKI">
1249 PKI</A> or previous exchange of public keys. This is one  of the goals
1250 of the Linux FreeS/WAN project, discussed in our <A href="intro.html#goals">
1251 introduction</A> section. </DD>
1252 <P> Setting up for opportunistic encryption is described in our <A href="config.html#oppex">
1253  configuration</A> document.</P>
1254 <DT><A name="P">P</A></DT>
1255 <DT><A name="P1363"><A href="http://grouper.ieee.org/groups/1363">P1363
1256  standard</A></A></DT>
1257 <DD>An <A href="#IEEE">IEEE</A> standard for public key  cryptography.</DD>
1258 <DT><A name="passive">Passive attack</A></DT>
1259 <DD>An attack in which the attacker only eavesdrops and attempts to
1260  analyse intercepted messages, as opposed to an <A href="#active">
1261 active attack</A> in which he diverts messages or  generates his own.</DD>
1262 <DT><A name="pathMTU">Path <A href="#MTU">MTU</A></A> discovery</DT>
1263 <DD>The process of discovering the largest packet size which all links
1264  on a path can handle without fragmentation -- that is, without any
1265  router having to break the packet up into smaller pieces to match the <A
1266 href="#MTU"> MTU</A> of its outgoing link. </DD>
1267 <P>This is done as follows:</P>
1268 <UL>
1269 <LI>originator sends the largest packets allowed by <A href="#MTU">MTU</A>
1270  of the first link, setting the DF  (<STRONG>d</STRONG>on't <STRONG>f</STRONG>
1271 ragment) bit in the  packet header</LI>
1272 <LI>any router which cannot send the packet on (outgoing MTU is too
1273  small for it, and DF prevents fragmenting it to match) sends back  an <A
1274 href="#ICMP">ICMP</A> packet reporting the problem</LI>
1275 <LI>originator looks at ICMP message and tries a smaller size</LI>
1276 <LI>eventually, you settle on a size that can pass all routers</LI>
1277 <LI>thereafter, originator just sends that size and no-one has to
1278  fragment</LI>
1279 </UL>
1280 <P>Since this requires co-operation of many systems, and since the
1281  next packet may travel a different path, this is one of the trickier
1282  areas of IP programming. Bugs that have shown up over the years have
1283  included:</P>
1284 <UL>
1285 <LI>malformed ICMP messages</LI>
1286 <LI>hosts that ignore or mishandle these ICMP messages</LI>
1287 <LI>firewalls blocking the ICMP messages so host does not see  them</LI>
1288 </UL>
1289 <P>Since IPSEC adds a header, it increases packet size and may require
1290  fragmentation even where incoming and outgoing MTU are equal.</P>
1291 <DT><A name="PFS">Perfect forward secrecy (PFS)</A></DT>
1292 <DD>A property of systems such as <A href="#DH">Diffie-Hellman</A> key
1293  exchange which use a long-term key (such as the shared secret in IKE)
1294  and generate short-term keys as required. If an attacker who acquires
1295  the long-term key <EM>provably</EM> can
1296 <UL>
1297 <LI><EM>neither</EM> read previous messages which he may have  archived</LI>
1298 <LI><EM>nor</EM> read future messages without performing additional
1299  successful attacks</LI>
1300 </UL>
1301 </DD>
1302 <P>then the system has PFS. The attacker needs the short-term keys in
1303  order to read the trafiic and merely having the long-term key does not
1304  allow him to infer those. Of course, it may allow him to conduct
1305  another attack (such as <A href="#middle">man-in-the-middle</A>) which
1306  gives him some short-term keys, but he does not automatically get them
1307  just by acquiring the long-term key.</P>
1308 <DT>PFS</DT>
1309 <DD>see Perfect Forward Secrecy</DD>
1310 <DT><A name="PGP">PGP</A></DT>
1311 <DD><B>P</B>retty <B>G</B>ood <B>P</B>rivacy, a personal encryption
1312  system for email based on public key technology, written by Phil
1313  Zimmerman. </DD>
1314 <P>The 2.xx versions of PGP used the <A href="#RSA">RSA</A> public key
1315  algorithm and used <A href="#IDEA">IDEA</A> as the symmetric cipher.
1316  These versions are described in RFC 1991 and in <A href="#PGP">
1317 Garfinkel's book</A>. Since version 5, the products from <A href="#pgpi">
1318  PGP Inc</A>. have used <A href="#DH">Diffie-Hellman</A> public key
1319 methods and <A href="#CAST128">CAST-128</A> symmetric encryption. These
1320 can verify  signatures from the 2.xx versions, but cannot exchange
1321 encryted  messages with them.</P>
1322 <P>An <A href="#IETF">IETF</A> working group has issued RFC 2440 for
1323  an &quot;Open PGP&quot; standard, similar to the 5.x versions. PGP Inc. staff
1324  were among the authors. A free <A href="#GPG">Gnu Privacy Guard</A>
1325  based on that standard is now available.</P>
1326 <P>For more information on PGP, including how to obtain it, see our
1327  cryptography <A href="web.html#tools">links</A>.</P>
1328 <DT><A name="PGPI">PGP Inc.</A></DT>
1329 <DD>A company founded by Zimmerman, the author of <A href="#PGP">PGP</A>
1330 , now a division of <A href="#NAI">NAI</A>. See the <A href="http://www.pgp.com">
1331  corporate website</A>. </DD>
1332 <P>Their PGP 6.5 product includes PGPnet, an IPSEC client for
1333  Macintosh or for Windows 95/98/NT.</P>
1334 <DT><A name="photuris">Photuris</A></DT>
1335 <DD>Another key negotiation protocol, an alternative to <A href="#IKE">
1336 IKE</A>, described in RFCs 2522 and 2523.</DD>
1337 <DT><A name="PPTP">PPTP</A></DT>
1338 <DD><B>P</B>oint-to-<B>P</B>oint <B>T</B>unneling <B>P</B>rotocol.
1339  Papers discussing weaknesses in it are on <A href="http://www.counterpane.com/publish.html">
1340 counterpane.com</A>.</DD>
1341 <DT><A name="PKI">PKI</A></DT>
1342 <DD><B>P</B>ublic <B>K</B>ey <B>I</B>nfrastructure, the things an
1343  organisation or community needs to set up in order to make <A href="#public">
1344 public key</A> cryptographic technology a standard part  of their
1345 operating procedures. </DD>
1346 <P>There are several PKI products on the market. Typically they use a
1347  hierarchy of <A href="#CA">Certification Authorities (CAs)</A>. Often
1348  they use <A href="#LDAP">LDAP</A> access to <A href="#X509">X.509</A>
1349  directories to implement this.</P>
1350 <P>See <A href="#web">Web of Trust</A> for a different sort of
1351  infrastructure.</P>
1352 <DT><A name="PKIX">PKIX</A></DT>
1353 <DD><B>PKI</B> e<B>X</B>change, an <A href="#IETF">IETF</A> standard
1354  that allows <A href="ipsec.html#PKI">PKI</A>s to talk to each other. </DD>
1355 <P>This is required, for example, when users of a corporate PKI need
1356  to communicate with people at client, supplier or government
1357  organisations, any of which may have a different PKI in place. I
1358  should be able to talk to you securely whenever:</P>
1359 <UL>
1360 <LI>your organisation and mine each have a PKI in place</LI>
1361 <LI>you and I are each set up to use those PKIs</LI>
1362 <LI>the two PKIs speak PKIX</LI>
1363 <LI>the configuration allows the conversation</LI>
1364 </UL>
1365 <P>At time of writing (March 1999), this is not yet widely implemented
1366  but is under quite active development by several groups.</P>
1367 <DT><A name="plaintext">Plaintext</A></DT>
1368 <DD>The unencrypted input to a cipher, as opposed to the encrypted <A href="#ciphertext">
1369 ciphertext</A> output.</DD>
1370 <DT><A name="Pluto">Pluto</A></DT>
1371 <DD>The <A href="web.html#FreeSWAN">Linux FreeS/WAN</A> daemon which
1372 handles key  exchange via the <A href="#IKE">IKE</A> protocol,
1373 connection  negotiation, and other higher-level tasks. Pluto calls the <A
1374 href="#KLIPS">KLIPS</A> kernel code as required. For details, see the
1375  manual page ipsec_pluto(8).</DD>
1376 <DT><A name="public">Public Key Cryptography</A></DT>
1377 <DD>In public key cryptography, keys are created in matched pairs.
1378  Encrypt with one half of a pair and only the matching other half can
1379  decrypt it. This contrasts with <A href="#symmetric">symmetric or
1380  secret key cryptography</A> in which a single key known to both
1381  parties is used for both encryption and decryption. </DD>
1382 <P>One half of each pair, called the public key, is made public. The
1383  other half, called the private key, is kept secret. Messages can then
1384  be sent by anyone who knows the public key to the holder of the
1385  private key. Encrypt with the public key and you know only someone
1386  with the matching private key can decrypt.</P>
1387 <P>Public key techniques can be used to create <A href="#signature">
1388 digital signatures</A> and to deal with key  management issues, perhaps
1389 the hardest part of effective deployment of <A href="#symmetric">
1390  symmetric ciphers</A>. The resulting <A href="#hybrid">hybrid
1391 cryptosystems</A> use public key methods to  manage keys for symmetric
1392 ciphers.</P>
1393 <P>Many organisations are currently creating <A href="ipsec.html#PKI">
1394 PKIs,  public key infrastructures</A> to make these benefits widely
1395  available.</P>
1396 <DT>Public Key Infrastructure</DT>
1397 <DD>see <A href="ipsec.html#PKI">PKI</A></DD>
1398 <DT><A name="Q">Q</A></DT>
1399 <DT><A name="R">R</A></DT>
1400 <DT><A name="random">Random</A></DT>
1401 <DD>A remarkably tricky term, far too much so for me to attempt a
1402  definition here. Quite a few cryptosystems have been broken via
1403  attacks on weak random number generators, even when the rest of the
1404  system was sound. </DD>
1405 <P>See RFC 1750 for the theory. It will be available <A href="../Internet-docs/rfc1750.txt">
1406 locally</A> if you have downloaded  our RFC bundle (which is <A href="rfc.html#RFC">
1407 described here</A>). Or read  it <A href="http://nis.nsf.net/internet/documents/rfc/rfc1750.txt">
1408 on  the net</A>.</P>
1409 <P>See the manual pages for ipsec_ranbits(8) and random(4) for details
1410  of what we use.</P>
1411 <P>There has recently been discussion on several mailing lists of the
1412  limitations of Linux /dev/random and of whether we are using it
1413  correctly. Those discussions are archived on the <A href="http://www.openpgp.net/random/index.html">
1414 /dev/random support  page</A>.</P>
1415 <DT><A href="http://www.raptor.com">Raptor</A></DT>
1416 <DD>A firewall product for Windows NT offerring IPSEC-based VPN
1417  services. Linux FreeS/WAN interoperates with Raptor; see our <A href="interop.html#Raptor">
1418 Compatibility</A> document for details. Raptor have  recently merged
1419 with Axent.</DD>
1420 <DT><A name="RC4">RC4</A></DT>
1421 <DD><B>R</B>ivest <B>C</B>ipher four, designed by Ron Rivest of <A href="#RSAco">
1422 RSA</A> and widely used. Believed highly secure with  adequate key
1423 length, but often implemented with inadequate key length  to comply
1424 with export restrictions.</DD>
1425 <DT><A name="RC6">RC6</A></DT>
1426 <DD><B>R</B>ivest <B>C</B>ipher six, <A href="#RSAco">RSA</A>'s <A href="#AES">
1427 AES</A> candidate cipher.</DD>
1428 <DT><A name="replay">Replay attack</A></DT>
1429 <DD>An attack in which the attacker records data and later replays it
1430 in  an attempt to deceive the recipient.</DD>
1431 <DT>RFC</DT>
1432 <DD><B>R</B>equest <B>F</B>or <B>C</B>omments, an Internet document.
1433  Some RFCs are just informative. Others are standards. </DD>
1434 <P>Our list of <A href="#IPSEC">IPSEC</A> and other security-related
1435  RFCs is <A href="rfc.html#RFC">here</A>, along with information on
1436 methods of  obtaining them.</P>
1437 <DT><A name="RIPEMD">RIPEMD</A></DT>
1438 <DD>A <A href="#digest">message digest</A> algorithm. The current
1439  version is RIPEMD-160 which gives a 160-bit hash.</DD>
1440 <DT><A name="rootCA">Root CA</A></DT>
1441 <DD>The top level <A href="#CA">Certification Authority</A> in a
1442  hierachy of such authorities.</DD>
1443 <DT><A name="routable">Routable IP address</A></DT>
1444 <DD>Most IP addresses can be used as &quot;to&quot; and &quot;from&quot; addresses in
1445 packet  headers. These are the routable addresses; we expect routing to
1446 be  possible for them. If we send a packet to one of them, we expect
1447 (in  most cases; there are various complications) that it will be
1448 delivered  if the address is in use and will cause an <A href="#icmp">
1449 ICMP</A> error packet to come back to us if not. </DD>
1450 <P>There are also several classes of <A href="#non-routable">
1451 non-routable</A> IP addresses.</P>
1452 <DT><A name="RSA">RSA algorithm</A></DT>
1453 <DD><B>R</B>ivest <B>S</B>hamir <B>A</B>dleman public key encryption
1454  method, named for its three inventors. The algorithm is widely used
1455  and likely to become moreso since it became free of patent
1456  encumbrances in September 2000. </DD>
1457 <P> For a full explanation of the algorithm, consult one of the
1458 standard references such as <A href="biblio.html#schneier">Applied
1459 Cryptography</A>. A simple explanation is: </P>
1460 <P> The great 17th century French mathematician <A href="http://www-groups.dcs.st-andrews.ac.uk/~history/Mathematicians/Fermat.html">
1461 Fermat</A> proved that, for any prime p and number x, 0
1462 <!--= x < p:
1463 <pre-->
1464  x^p == x
1465  modulo p  x^(p-1) == 1  modulo p, non-zero x  From this it follows
1466 that if we have a pair of primes p, q and two numbers e, d such that: </P>
1467 <PRE>
1468         ed == 1                 modulo lcm( p-1, q-1)
1469 </PRE>
1470  where lcm() is least common multiple, then for all x, 0
1471 <!--= x < pq:
1472 <pre-->
1473  x^(ed-1) == 1
1474  modulo pq, non-zero x  x^ed == x  modulo pq  So we construct such as
1475 set of numbers p, q, e, d and publish the product N=pq and e as the
1476 public key. Encryption is then:
1477 <PRE>
1478         c = x^e                 modulo N
1479 </PRE>
1480  An attacker cannot deduce x from the cyphertext c, short of either
1481 factoring N or solving the <A href="#dlog">discrete logarithm</A>
1482  problem for this field. If p, q are large primes (hundreds or
1483 thousands of bits) no efficient solution to either problem is known.
1484 <P> The receiver, knowing the private key (N and d), can readily find x
1485 sixce: </P>
1486 <PRE>
1487         c^d == (x^e)^d          modulo N
1488             == x^ed             modulo N
1489             == x                modulo N
1490 </PRE>
1491  This gives an effective public key technique, with only a couple of
1492 problems. It uses a good deal of computer time, since calculations with
1493 large integers are not cheap, and there is no proof it is necessarily
1494 secure since no-one has proven either factoring or discrete log cannot
1495 be done efficiently.
1496 <DT><A name="RSAco">RSA Data Security</A></DT>
1497 <DD>A company founded by the inventors of the <A href="#RSA">RSA</A>
1498  public key algorithm.</DD>
1499 <DT><A name="S">S</A></DT>
1500 <DT><A name="SA">SA</A></DT>
1501 <DD><B>S</B>ecurity <B>A</B>ssociation, the channel negotiated by the
1502  higher levels of an <A href="#IPSEC">IPSEC</A> implementation and used
1503  by the lower. SAs are unidirectional; you need a pair of them for
1504  two-way communication. </DD>
1505 <P>An SA is defined by three things -- the destination, the protocol  (<A
1506 href="#AH">AH</A> or<A href="#ESP">ESP</A>) and the <A href="SPI">SPI</A>
1507 , security parameters index. It is used to index  other things such as
1508 session keys and intialisation vectors.</P>
1509 <P>For more detail, see our section on <A href="ipsec.html">IPSEC</A>
1510  and/or RFC 2401.</P>
1511 <DT><A name="SDNS"><A href="http://www.toad.com/~dnssec">Secure DNS</A></A>
1512 </DT>
1513 <DD>A version of the <A href="#DNS">DNS or Domain Name Service</A>
1514  enhanced with authentication services. This is being designed by the <A href="#IETF">
1515  IETF</A> DNS security <A href="http://www.ietf.org/ids.by.wg/dnssec.html">
1516  working group</A>.  Check the <A href="http://www.isc.org/bind.html">
1517  Internet Software Consortium</A> for information on implementation
1518 progress and for  the latest version of <A href="#BIND">BIND</A>.
1519 Another site has <A href="http://www.toad.com/~dnssec">more information</A>
1520 . </DD>
1521 <P><A href="#IPSEC">IPSEC</A> can use this plus <A href="#DH">
1522 Diffie-Hellman key exchange</A> to bootstrap itself. This  would allow <A
1523 href="#carpediem">opportunistic encryption</A>. Any  pair of machines
1524 which could authenticate each other via DNS could  communicate
1525 securely, without either a pre-existing shared secret or a  shared <A href="ipsec.html#PKI">
1526 PKI</A>.</P>
1527 <P><A href="web.html#FreeSWAN">Linux FreeS/WAN</A> will support this in
1528 a  future release.</P>
1529 <DT>Secret key cryptography</DT>
1530 <DD>See <A href="#symmetric">symmetric cryptography</A></DD>
1531 <DT>Security Association</DT>
1532 <DD>see <A href="#SA">SA</A></DD>
1533 <DT><A name="sequence">Sequence number</A></DT>
1534 <DD>A number added to a packet or message which indicates its position
1535  in a sequence of packets or messages. This provides some security
1536  against <A href="#replay">replay attacks</A>. </DD>
1537 <P>For <A href="ipsec.html#auto">automatic keying</A> mode, the <A href="#IPSEC">
1538 IPSEC</A> RFCs require that the sender generate sequence  numbers for
1539 each packet, but leave it optional whether the receiver  does anything
1540 with them.</P>
1541 <DT><A name="SHA">SHA</A></DT>
1542 <DD><B>S</B>ecure <B>H</B>ash <B>A</B>lgorithm, a <A href="#digest">
1543 message digest algorithm</A> developed by the <A href="#NSA">NSA</A>
1544  for use in the Digital Signature standard, <A href="#FIPS">FIPS</A>
1545  number 186 from <A href="#NIST">NIST</A>. SHA is  an improved variant
1546 of <A href="#MD4">MD4</A> producing a 160-bit  hash. </DD>
1547 <P>SHA is one of two message digest algorithms available in IPSEC. The
1548  other is <A href="#MD5">MD5</A>. Some people do not trust SHA because
1549  it was developed by the <A href="#NSA">NSA</A>. There is, as far as we
1550  know, no cryptographic evidence that SHA is untrustworthy, but this
1551  does not prevent that view from being strongly held.</P>
1552 <DT><A name="SIGINT">Signals intelligence (SIGINT)</A></DT>
1553 <DD>Activities of government agencies from various nations aimed at
1554  protecting their own communications and reading those of others.
1555  Cryptography, cryptanalysis, wiretapping, interception and monitoring
1556  of various sorts of signals. The players include the American <A href="#NSA">
1557 NSA</A>, British <A href="#GCHQ">GCHQ</A> and Canadian <A href="#CSE">
1558 CSE</A>.</DD>
1559 <DT><A name="SKIP">SKIP</A></DT>
1560 <DD><B>S</B>imple <B>K</B>ey management for <B>I</B>nternet <B> P</B>
1561 rotocols, an alternative to <A href="#IKE">IKE</A> developed  by Sun
1562 and being marketed by their <A href="http://skip.incog.com">Internet
1563 Commerce Group</A>.</DD>
1564 <DT><A name="snake">Snake oil</A></DT>
1565 <DD>Bogus cryptography. See the <A href="http://www.interhack.net/people/cmcurtin/snake-oil-faq.html">
1566  Snake Oil FAQ</A> or <A href="http://www.counterpane.com/crypto-gram-9902.html#snakeoil">
1567 this  paper</A> by Schneier.</DD>
1568 <DT><A name="SPI">SPI</A></DT>
1569 <DD><B>S</B>ecurity <B>P</B>arameter <B>I</B>ndex, an index used within <A
1570 href="#IPSEC"> IPSEC</A> to keep connections distinct. A <A href="#SA">
1571 Security Association (SA)</A> is defined by destination,  protocol and
1572 SPI. Without the SPI, two connections to the same gateway  using the
1573 same protocol could not be distinguished. </DD>
1574 <P>For more detail, see our <A href="#SPI">IPSEC Overview</A> and/or
1575  RFC 2401.</P>
1576 <DT><A name="SSH">SSH</A></DT>
1577 <DD><B>S</B>ecure <B>SH</B>ell, an encrypting replacement for the
1578  insecure Berkeley commands whose names begin with &quot;r&quot; for &quot;remote&quot;:
1579  rsh, rlogin, etc. </DD>
1580 <P>For more information on SSH, including how to obtain it, see our
1581  cryptography <A href="web.html#tools">links</A>.</P>
1582 <DT><A name="SSHco">SSH Communications Security</A></DT>
1583 <DD>A company founded by the authors of <A href="#SSH">SSH</A>. Offices
1584  are in <A href="http://www.ssh.fi">Finland</A> and <A href="http://www.ipsec.com">
1585 California</A>. They have a toolkit for  developers of IPSEC
1586 applications.</DD>
1587 <DT><A name="SSL">SSL</A></DT>
1588 <DD><A href="http://home.netscape.com/eng/ssl3">Secure Sockets  Layer</A>
1589 , a set of encryption and authentication services for web  browsers,
1590 developed by Netscape. Widely used in Internet commerce.  Also known as <A
1591 href="#TLS">TLS</A>.</DD>
1592 <DT>SSLeay</DT>
1593 <DD>A free implementation of <A href="#SSL">SSL</A> by Eric Young (eay)
1594  and others. Developed in Australia; not subject to US export  controls.</DD>
1595 <DT><A name="stream">Stream cipher</A></DT>
1596 <DD>A <A href="#symmetric">symmetric cipher</A> which produces a stream
1597  of output which can be combined (often using XOR or bytewise addition)
1598  with the plaintext to produce ciphertext. Contrasts with <A href="#block">
1599 block cipher</A>. </DD>
1600 <P><A href="#IPSEC">IPSEC</A> does not use stream ciphers. Their main
1601  application is link-level encryption, for example of voice, video or
1602  data streams on a wire or a radio signal.</P>
1603 <DT><A name="subnet">subnet</A></DT>
1604 <DD>A group of IP addresses which are logically one network, typically
1605  (but not always) assigned to a group of physically connected machines.
1606  The range of addresses in a subnet is described using a subnet mask.
1607  See next entry.</DD>
1608 <DT>subnet mask</DT>
1609 <DD>A method of indicating the addresses included in a subnet. Here are
1610  two equivalent examples:
1611 <UL>
1612 <LI>101.101.101.0/24</LI>
1613 <LI>101.101.101.0 with mask 255.255.255.0</LI>
1614 </UL>
1615 </DD>
1616 <P>The '24' is shorthand for a mask with the top 24 bits one and the
1617  rest zero. This is exactly the same as 255.255.255.0 which has three
1618  all-ones bytes and one all-zeros byte.</P>
1619 <P>These indicate that, for this range of addresses, the top 24 bits
1620  are to be treated as naming a network (often referred to as &quot;the
1621  101.101.101.0/24 subnet&quot;) while most combinations of the low 8 bits
1622  can be used to designate machines on that network. Two addresses are
1623  reserved; 101.101.101.0 refers to the subnet rather than a specific
1624  machine while 101.101.101.255 is a broadcast address. 1 to 254 are
1625  available for machines.</P>
1626 <P>It is common to find subnets arranged in a hierarchy. For example,
1627  a large company might have a /16 subnet and allocate /24 subnets
1628  within that to departments. An ISP might have a large subnet and
1629  allocate /26 subnets (64 addresses, 62 usable) to business customers
1630  and /29 subnets (8 addresses, 6 usable) to residential clients.</P>
1631 <DT><A name="SWAN">S/WAN</A></DT>
1632 <DD>Secure Wide Area Network, a project involving <A href="#RSAco">RSA
1633  Data Security</A> and a number of other companies. The goal was to
1634  ensure that all their <A href="#IPSEC">IPSEC</A> implementations would
1635  interoperate so that their customers can communicate with each other
1636  securely.</DD>
1637 <DT><A name="symmetric">Symmetric cryptography</A></DT>
1638 <DD>Symmetric cryptography, also referred to as conventional or secret
1639  key cryptography, relies on a <EM>shared secret key</EM>, identical
1640  for sender and receiver. Sender encrypts with that key, receiver
1641  decrypts with it. The idea is that an eavesdropper without the key be
1642  unable to read the messages. There are two main types of symmetric
1643  cipher, <A href="#block">block ciphers</A> and <A href="#stream">
1644 stream ciphers</A>. </DD>
1645 <P>Symmetric cryptography contrasts with <A href="#public">public  key</A>
1646  or asymmetric systems where the two players use different  keys.</P>
1647 <P>The great difficulty in symmetric cryptography is, of course, key
1648  management. Sender and receiver <EM>must</EM> have identical keys and
1649  those keys <EM>must</EM> be kept secret from everyone else. Not too
1650  much of a problem if only two people are involved and they can
1651  conveniently meet privately or employ a trusted courier. Quite a
1652  problem, though, in other circumstances.</P>
1653 <P>It gets much worse if there are many people. An application might
1654  be written to use only one key for communication among 100 people, for
1655  example, but there would be serious problems. Do you actually trust
1656  all of them that much? Do they trust each other that much? Should
1657  they? What is at risk if that key is compromised? How are you  going
1658  to distribute that key to everyone without risking its secrecy? What
1659  do you do when one of them leaves the company? Will you even know?</P>
1660 <P>On the other hand, if you need unique keys for every possible
1661  connection between a group of 100, then each user must have 99 keys.
1662  You need either 99*100/2 = 4950 <EM>secure</EM> key exchanges between
1663  users or a central authority that <EM>securely</EM> distributes 100
1664  key packets, each with a different set of 99 keys.</P>
1665 <P>Either of these is possible, though tricky, for 100 users. Either
1666  becomes an administrative nightmare for larger numbers. Moreover, keys <EM>
1667  must</EM> be changed regularly, so the problem of key distribution
1668  comes up again and again. If you use the same key for many messages
1669  then an attacker has more text to work with in an attempt to crack
1670  that key. Moreover, one successful crack will give him or her the text
1671  of all those messages.</P>
1672 <P>In short, the <EM>hardest part of conventional cryptography is key
1673  management</EM>. Today the standard solution is to build a <A href="#hybrid">
1674 hybrid system</A> using <A href="#public">public  key</A> techniques to
1675 manage keys.</P>
1676 <DT><A name="T">T</A></DT>
1677 <DT><A name="TIS">TIS</A></DT>
1678 <DD><A href="http://www.tislabs.com">Trusted Information Systems</A>, a
1679  firewall vendor now part of <A href="#NAI">NAI</A>. Their Gauntlet
1680  product offers IPSEC VPN services. TIS implemented the first version
1681  of <A href="#SNDS">Secure DNS</A> on a <A href="#DARPA">DARPA</A>
1682  contract.</DD>
1683 <DT><A name="TLS">TLS</A></DT>
1684 <DD><B>T</B>ransport <B>L</B>ayer <B>S</B>ecurity, a newer name for <A href="#SSL">
1685 SSL</A>.</DD>
1686 <DT><A name="traffic">Traffic analysis</A></DT>
1687 <DD>Deducing useful intelligence from patterns of message traffic,
1688  without breaking codes or reading the messages. In one case during
1689  World War II, the British knew an attack was coming because all German
1690  radio traffic stopped. The &quot;radio silence&quot; order, intended to preserve
1691  security, actually gave the game away. </DD>
1692 <P>In an industrial espionage situation, one might deduce something
1693  interesting just by knowing that company A and company B were talking,
1694  especially if one were able to tell which departments were involved,
1695  or if one already knew that A was looking for acquisitions and B was
1696  seeking funds for expansion.</P>
1697 <P><A href="#IPSEC">IPSEC</A> itself does not defend against this, but
1698  carefully thought out systems using IPSEC can provide at least partial
1699  protection. In particular, one might want to encrypt more traffic than
1700  was strictly necessary, route things in odd ways, or even encrypt
1701  dummy packets, to confuse the analyst.</P>
1702 <DT><A name="transport">Transport mode</A></DT>
1703 <DD>An IPSEC application in which the IPSEC gateway is the destination
1704  of the protected packets, a machine acts as its own gateway. Contrast
1705  with <A href="#tunnel">tunnel mode</A>.</DD>
1706 <DT>Triple DES</DT>
1707 <DD>see <A href="#3DES">3DES</A></DD>
1708 <DT><A name="tunnel">Tunnel mode</A></DT>
1709 <DD>An IPSEC application in which an IPSEC gateway provides protection
1710  for packets to and from other systems. Contrast with <A href="#transport">
1711 transport mode</A>.</DD>
1712 <DT><A name="2key">Two-key Triple DES</A></DT>
1713 <DD>A variant of <A href="#3DES">triple DES or 3DES</A> in which only
1714  two keys are used. As in the three-key version, the order of
1715  operations is <A href="#EDE">EDE</A> or encrypt-decrypt-encrypt, but
1716  in the two-key variant the first and third keys are the same. </DD>
1717 <P>3DES with three keys has 3*56 = 168 bits of key but has only
1718  112-bit strength against a <A href="#meet">meet-in-the-middle</A>
1719  attack, so it is possible that the two key version is just as strong.
1720  Last I looked, this was an open question in the research  literature.</P>
1721 <P>RFC 2451 defines triple DES for <A href="#IPSEC">IPSEC</A> as the
1722  three-key variant. The two-key variant should not be used and is not
1723  implemented directly in <A href="web.html#FreeSWAN">Linux FreeS/WAN</A>
1724 . It  cannot be used in automatically keyed mode without major fiddles
1725 in  the source code. For manually keyed connections, you could make
1726 Linux  FreeS/WAN talk to a two-key implementation by setting two keys
1727 the  same in /etc/ipsec.conf.</P>
1728 <DT><A name="U">U</A></DT>
1729 <DT><A name="V">V</A></DT>
1730 <DT><A name="virtual">Virtual Interface</A></DT>
1731 <DD>A <A href="#Linux">Linux</A> feature which allows one physical
1732  network interface to have two or more IP addresses. See the <CITE>
1733  Linux Network Administrator's Guide</CITE> in <A href="biblio.html#kirch">
1734 book form</A> or <A href="http://metalab.unc.edu/LDP/LDP/nag/node1.html">
1735 on the web</A> for details.</DD>
1736 <DT>Virtual Private Network</DT>
1737 <DD>see <A href="web.html#VPN">VPN</A></DD>
1738 <DT><A name="VPN">VPN</A></DT>
1739 <DD><B>V</B>irtual <B>P</B>rivate <B>N</B>etwork, a network which can
1740  safely be used as if it were private, even though some of its
1741  communication uses insecure connections. All traffic on those
1742  connections is encrypted. </DD>
1743 <P><A href="#IPSEC">IPSEC</A> is not the only technique available for
1744  building VPNs, but it is the only method defined by <A href="rfc.html#RFC">
1745 RFCs</A> and supported by many vendors. VPNs are by no  means the only
1746 thing you can do with IPSEC, but they may be the most  important
1747 application for many users.</P>
1748 <DT><A name="VPNC">VPNC</A></DT>
1749 <DD><A href="http://www.vpnc.org">Virtual Private Network  Consortium</A>
1750 , an association of vendors of VPN products.</DD>
1751 <DT><A name="W">W</A></DT>
1752 <DT>Wassenaar Arrangement</DT>
1753 <DD>An international agreement restricting export of munitions and
1754 other  tools of war. Unfortunately, cryptographic software is also
1755 restricted  under the current version of the agreement. <A href="politics.html#Wassenaar">
1756  Discussion</A>.</DD>
1757 <DT><A name="web">Web of Trust</A></DT>
1758 <DD><A href="#PGP">PGP</A>'s method of certifying keys. Any user can
1759  sign a key; you decide which signatures or combinations of signatures
1760  to accept as certification. This contrasts with the hierarchy of <A href="#CA">
1761 CAs (Certification Authorities)</A> used in many <A href="ipsec.html#PKI">
1762 PKIs (Public Key Infrastructures)</A>. </DD>
1763 <P>See <A href="#GTR">Global Trust Register</A> for an interesting
1764  addition to the web of trust.</P>
1765 <DT><A name="X">X</A></DT>
1766 <DT><A name="X509">X.509</A></DT>
1767 <DD>A standard from the <A href="http://www.itu.int">ITU (International
1768  Telecommunication Union)</A>, for hierarchical directories with
1769  authentication services, used in many <A href="ipsec.html#PKI">PKI</A>
1770  implementations. </DD>
1771 <P>Use of X.509 services, via the <A href="#LDAP">LDAP protocol</A>,
1772  for certification of keys is allowed but not required by the <A href="#IPSEC">
1773 IPSEC</A> RFCs. It is not yet implemented in <A href="web.html#FreeSWAN">
1774 Linux FreeS/WAN</A>.</P>
1775 <DT><A href="http://www.xedia.com">Xedia</A></DT>
1776 <DD>A vendor of router and Internet access products. Their QVPN
1777 products  interoperate with Linux FreeS/WAN; see our <A href="interop.html#Xedia">
1778 compatibility document</A>.</DD>
1779 <DT><A name="Y">Y</A></DT>
1780 <DT><A name="Z">Z</A></DT>
1781 </DL>
1782 <HR>
1783 <A HREF="toc.html">Contents</a>
1784 <A HREF="web.html">Previous</a>
1785 <A HREF="biblio.html">Next</a>
1786 </BODY>
1787 </HTML>