1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
4 <meta http-equiv="Content-Type" content="text/html">
5 <title>FreeS/WAN glossary</title>
7 content="Linux, IPsec, VPN, security, FreeSWAN, glossary, cryptography">
10 Written by Sandy Harris for the Linux FreeS/WAN project
11 Freely distributable under the GNU General Public License
13 More information at www.freeswan.org
14 Feedback to users@lists.freeswan.org
17 RCS ID: $Id: glossary.html,v 1.60 2002/03/26 21:42:19 sandy Exp $
18 Last changed: $Date: 2002/03/26 21:42:19 $
19 Revision number: $Revision: 1.60 $
21 CVS revision numbers do not correspond to FreeS/WAN release numbers.
26 <h1><a name="ourgloss">Glossary for the Linux FreeS/WAN project</a></h1>
28 <p>Entries are in alphabetical order. Some entries are only one line or one
29 paragraph long. Others run to several paragraphs. I have tried to put the
30 essential information in the first paragraph so you can skip the other
31 paragraphs if that seems appropriate.</p>
34 <h2><a name="jump">Jump to a letter in the glossary</a></h2>
37 <big><b><a href="#0">numeric</a> <a href="#A">A</a> <a href="#B">B</a> <a
38 href="#C">C</a> <a href="#D">D</a> <a href="#E">E</a> <a href="#F">F</a> <a
39 href="#G">G</a> <a href="#H">H</a> <a href="#I">I</a> <a href="#J">J</a> <a
40 href="#K">K</a> <a href="#L">L</a> <a href="#M">M</a> <a href="#N">N</a> <a
41 href="#O">O</a> <a href="#P">P</a> <a href="#Q">Q</a> <a href="#R">R</a> <a
42 href="#S">S</a> <a href="#T">T</a> <a href="#U">U</a> <a href="#V">V</a> <a
43 href="#W">W</a> <a href="#X">X</a> <a href="#Y">Y</a> <a
44 href="#Z">Z</a></b></big></center>
47 <h2><a name="gloss">Other glossaries</a></h2>
49 <p>Other glossaries which overlap this one include:</p>
51 <li>The VPN Consortium's glossary of <a
52 href="http://www.vpnc.org/terms.html">VPN terms</a>.</li>
53 <li>glossary portion of the <a
54 href="http://www.rsa.com/rsalabs/faq/B.html">Cryptography FAQ</a></li>
55 <li>an extensive crytographic glossary on <a
56 href="http://www.ciphersbyritter.com/GLOSSARY.HTM">Terry Ritter's</a>
58 <li>The <a href="#NSA">NSA</a>'s <a
59 href="http://www.sans.org/newlook/resources/glossary.htm">glossary of
60 computer security</a> on the <a href="http://www.sans.org">SANS
61 Institute</a> site.</li>
62 <li>a small glossary for Internet Security at <a
63 href="http://www5.zdnet.com/pcmag/pctech/content/special/glossaries/internetsecurity.html">
66 href="http://www.visi.com/crypto/inet-crypto/glossary.html">glossary</a>
67 from Richard Smith's book <a href="#Smith">Internet Cryptography</a></li>
70 <p>Several Internet glossaries are available as RFCs:</p>
72 <li><a href="http://www.rfc-editor.org/rfc/rfc1208.txt">Glossary of
73 Networking Terms</a></li>
74 <li><a href="http://www.rfc-editor.org/rfc/rfc1983.txt">Internet User's
76 <li><a href="http://www.rfc-editor.org/rfc/rfc2828.txt">Internet Security
80 <p>More general glossary or dictionary information:</p>
82 <li>Free Online Dictionary of Computing (FOLDOC)
84 <li><a href="http://www.nightflight.com/foldoc">North America</a></li>
86 href="http://wombat.doc.ic.ac.uk/foldoc/index.html">Europe</a></li>
87 <li><a href="http://www.nue.org/foldoc/index.html">Japan</a></li>
89 <p>There are many more mirrors of this dictionary.</p>
91 <li>The Jargon File, the definitive resource for hacker slang and folklore
93 <li><a href="http://www.netmeg.net/jargon">North America</a></li>
94 <li><a href="http://info.wins.uva.nl/~mes/jargon/">Holland</a></li>
95 <li><a href="http://www.tuxedo.org/~esr/jargon">home page</a></li>
97 <p>There are also many mirrors of this. See the home page for a list.</p>
100 href="http://www.trinity.edu/~rjensen/245glosf.htm#Navigate"> technology
102 <li>An <a href="http://www.yourdictionary.com/">online dictionary resource
103 page</a> with pointers to many dictionaries for many languages</li>
104 <li>A <a href="http://www.onelook.com/">search engine</a> that accesses
105 several hundred online dictionaries</li>
106 <li>O'Reilly <a href="http://www.ora.com/reference/dictionary/">Dictionary
107 of PC Hardware and Data Communications Terms</a></li>
108 <li><a href="http://www.FreeSoft.org/CIE/index.htm">Connected</a> Internet
110 <li><a href="http://www.whatis.com/">whatis.com</a></li>
114 <h2><a name="definitions">Definitions</a></h2>
116 <dt><a name="0">0</a></dt>
117 <dt><a name="3DES">3DES (Triple DES)</a></dt>
118 <dd>Using three <a href="#DES">DES</a> encryptions on a single data
119 block, with at least two different keys, to get higher security than is
120 available from a single DES pass. The three-key version of 3DES is the
121 default encryption algorithm for <a href="#FreeSWAN">Linux
123 <p><a href="#IPSEC">IPsec</a> always does 3DES with three different
124 keys, as required by RFC 2451. For an explanation of the two-key
125 variant, see <a href="#2key">two key triple DES</a>. Both use an <a
126 href="#EDE">EDE</a> encrypt-decrypt-encrpyt sequence of operations.</p>
127 <p>Single <a href="#DES">DES</a> is <a
128 href="politics.html#desnotsecure">insecure</a>.</p>
129 <p>Double DES is ineffective. Using two 56-bit keys, one might expect
130 an attacker to have to do 2<sup>112</sup> work to break it. In fact,
131 only 2<sup>57</sup> work is required with a <a
132 href="#meet">meet-in-the-middle attack</a>, though a large amount of
133 memory is also required. Triple DES is vulnerable to a similar attack,
134 but that just reduces the work factor from the 2<sup>168</sup> one
135 might expect to 2<sup>112</sup>. That provides adequate protection
136 against <a href="#brute">brute force</a> attacks, and no better attack
138 <p>3DES can be somewhat slow compared to other ciphers. It requires
139 three DES encryptions per block. DES was designed for hardware
140 implementation and includes some operations which are difficult in
141 software. However, the speed we get is quite acceptable for many uses.
142 See our <a href="performance.html">performance</a> document for
145 <dt><a name="A">A</a></dt>
146 <dt><a name="active">Active attack</a></dt>
147 <dd>An attack in which the attacker does not merely eavesdrop (see <a
148 href="#passive">passive attack</a>) but takes action to change, delete,
149 reroute, add, forge or divert data. Perhaps the best-known active
150 attack is <a href="#middle">man-in-the-middle</a>. In general, <a
151 href="#authentication">authentication</a> is a useful defense against
153 <dt><a name="AES">AES</a></dt>
154 <dd>The <b>A</b>dvanced <b>E</b>ncryption <b>S</b>tandard -- a new <a
155 href="#block">block cipher</a> standard to replace <a
156 href="politics.html#desnotsecure">DES</a> -- developed by <a
157 href="#NIST">NIST</a>, the US National Institute of Standards and
158 Technology. DES used 64-bit blocks and a 56-bit key. AES ciphers use a
159 128-bit block and 128, 192 or 256-bit keys. The larger block size helps
160 resist <a href="#birthday">birthday attacks</a> while the large key
161 size prevents <a href="#brute">brute force attacks</a>.
162 <p>Fifteen proposals meeting NIST's basic criteria were submitted in
163 1998 and subjected to intense discussion and analysis, "round one"
164 evaluation. In August 1999, NIST narrowed the field to five "round two"
167 <li><a href="http://www.research.ibm.com/security/mars.html">Mars</a>
169 <li><a href="http://www.rsa.com/rsalabs/aes/">RC6</a> from RSA</li>
171 href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael/">Rijndael</a>
172 from two Belgian researchers</li>
174 href="http://www.cl.cam.ac.uk/~rja14/serpent.html">Serpent</a>, a
175 British-Norwegian-Israeli collaboration</li>
176 <li><a href="http://www.counterpane.com/twofish.html">Twofish</a>
177 from the consulting firm <a
178 href="http://www.counterpane.com">Counterpane</a></li>
180 <p>Three of the five finalists -- Rijndael, Serpent and Twofish -- have
181 completely open licenses.</p>
182 <p>In October 2000, NIST announced the winner -- Rijndael.</p>
183 <p>For more information, see:</p>
186 href="http://csrc.nist.gov/encryption/aes/aes_home.htm">AES home
188 <li>the Block Cipher Lounge <a
189 href="http://www.ii.uib.no/~larsr/aes.html">AES page</a></li>
190 <li>Brian Gladman's <a
191 href="http://fp.gladman.plus.com/cryptography_technology/index.htm">code
192 and benchmarks</a></li>
193 <li>Helger Lipmaa's <a
194 href="http://www.tcs.hut.fi/~helger/aes/">survey of
195 implementations</a></li>
197 <p>AES will be added to a future release of <a href="#FreeSWAN">Linux
198 FreeS/WAN</a>. Likely we will add all three of the finalists with good
199 licenses. User-written <a href="web.html#patch">AES patches</a> are
200 already available.</p>
201 <p>Adding AES may also require adding stronger hashes, <a
202 href="#SHA-256">SHA-256, SHA-384 and SHA-512</a>.</p>
204 <dt><a name="AH">AH</a></dt>
205 <dd>The <a href="#IPSEC">IPsec</a> <b>A</b>uthentication <b>H</b>eader,
206 added after the IP header. For details, see our <a
207 href="ipsec.html#AH.ipsec">IPsec</a> document and/or RFC 2402.</dd>
208 <dt><a name="alicebob">Alice and Bob</a></dt>
209 <dd>A and B, the standard example users in writing on cryptography and
210 coding theory. Carol and Dave join them for protocols which require
212 <p>Bruce Schneier extends these with many others such as Eve the
213 Eavesdropper and Victor the Verifier. His extensions seem to be in the
214 process of becoming standard as well. See page 23 of <a
215 href="biblio.html#schneier">Applied Cryptography</a></p>
216 <p>Alice and Bob have an amusing <a
217 href="http://www.conceptlabs.co.uk/alicebob.html"> biography</a> on the
221 <dd>see <a href="#DARPA">DARPA</a></dd>
222 <dt><a name="ASIO">ASIO</a></dt>
223 <dd>Australian Security Intelligence Organisation.</dd>
224 <dt>Asymmetric cryptography</dt>
225 <dd>See <a href="#public">public key cryptography</a>.</dd>
226 <dt><a name="authentication">Authentication</a></dt>
227 <dd>Ensuring that a message originated from the expected sender and has
228 not been altered on route. <a href="#IPSEC">IPsec</a> uses
229 authentication in two places:
231 <li>peer authentication, authenticating the players in <a
232 href="#IKE">IKE</a>'s <a href="#DH">Diffie-Hellman</a> key
233 exchanges to prevent <a href="#middle">man-in-the-middle
234 attacks</a>. This can be done in a number of ways. The methods
235 supported by FreeS/WAN are discussed in our <a
236 href="adv_config.html#choose">advanced configuration</a>
238 <li>packet authentication, authenticating packets on an established
239 <a href="#SA">SA</a>, either with a separate <a
240 href="#AH">authentication header</a> or with the optional
241 authentication in the <a href="#ESP">ESP</a> protocol. In either
242 case, packet authentication uses a <a href="#HMAC">hashed message
243 athentication code</a> technique.</li>
245 <p>Outside IPsec, passwords are perhaps the most common authentication
246 mechanism. Their function is essentially to authenticate the person's
247 identity to the system. Passwords are generally only as secure as the
248 network they travel over. If you send a cleartext password over a
249 tapped phone line or over a network with a packet sniffer on it, the
250 security provided by that password becomes zero. Sending an encrypted
251 password is no better; the attacker merely records it and reuses it at
252 his convenience. This is called a <a href="#replay">replay</a>
254 <p>A common solution to this problem is a <a
255 href="#challenge">challenge-response</a> system. This defeats simple
256 eavesdropping and replay attacks. Of course an attacker might still try
257 to break the cryptographic algorithm used, or the <a
258 href="#random">random number</a> generator.</p>
260 <dt><a name="auto">Automatic keying</a></dt>
261 <dd>A mode in which keys are automatically generated at connection
262 establisment and new keys automaically created periodically thereafter.
263 Contrast with <a href="#manual">manual keying</a> in which a single
265 <p>IPsec uses the <a href="#DH">Diffie-Hellman key exchange
266 protocol</a> to create keys. An <a
267 href="#authentication">authentication</a> mechansim is required for
268 this. FreeS/WAN normally uses <a href="#RSA">RSA</a> for this. Other
269 methods supported are discussed in our <a
270 href="adv_config.html#choose">advanced configuration</a> document.</p>
271 <p>Having an attacker break the authentication is emphatically not a
272 good idea. An attacker that breaks authentication, and manages to
273 subvert some other network entities (DNS, routers or gateways), can use
274 a <a href="#middle">man-in-the middle attack</a> to break the security
275 of your IPsec connections.</p>
276 <p>However, having an attacker break the authentication in automatic
277 keying is not quite as bad as losing the key in manual keying.</p>
279 <li>An attacker who reads /etc/ipsec.conf and gets the keys for a
280 manually keyed connection can, without further effort, read all
281 messages encrypted with those keys, including any old messages he
282 may have archived.</li>
283 <li>Automatic keying has a property called <a href="#PFS">perfect
284 forward secrecy</a>. An attacker who breaks the authentication gets
285 none of the automatically generated keys and cannot immediately
286 read any messages. He has to mount a successful <a
287 href="#middle">man-in-the-middle attack</a> in real time before he
288 can read anything. He cannot read old archived messages at all and
289 will not be able to read any future messages not caught by
290 man-in-the-middle tricks.</li>
292 <p>That said, the secrets used for authentication, stored in <a
293 href="manpage.d/ipsec.secrets.5.html">ipsec.secrets(5)</a>, should
294 still be protected as tightly as cryptographic keys.</p>
296 <dt><a name="B">B</a></dt>
297 <dt><a href="http://www.nortelnetworks.com">Bay Networks</a></dt>
298 <dd>A vendor of routers, hubs and related products, now a subsidiary of
299 Nortel. Interoperation between their IPsec products and Linux FreeS/WAN
300 was problematic at last report; see our <a
301 href="interop.html#bay">interoperation</a> section.</dd>
302 <dt><a name="benchmarks">benchmarks</a></dt>
303 <dd>Our default block cipher, <a href="#3DES">triple DES</a>, is slower
304 than many alternate ciphers that might be used. Speeds achieved,
305 however, seem adequate for many purposes. For example, the assembler
306 code from the <a href="#LIBDES">LIBDES</a> library we use encrypts 1.6
307 megabytes per second on a Pentium 200, according to the test program
308 supplied with the library.
309 <p>For more detail, see our document on <a
310 href="performance.html">FreeS/WAN performance</a>.</p>
312 <dt><a name="BIND">BIND</a></dt>
313 <dd><b>B</b>erkeley <b>I</b>nternet <b>N</b>ame <b>D</b>aemon, a widely
314 used implementation of <a href="#DNS">DNS</a> (Domain Name Service).
315 See our bibliography for a <a href="#DNS">useful reference</a>. See the
316 <a href="http://www.isc.org/bind.html">BIND home page</a> for more
317 information and the latest version.</dd>
318 <dt><a name="birthday">Birthday attack</a></dt>
319 <dd>A cryptographic attack based on the mathematics exemplified by the <a
320 href="#paradox">birthday paradox</a>. This math turns up whenever the
321 question of two cryptographic operations producing the same result
324 <li><a href="#collision">collisions</a> in <a href="#digest">message
325 digest</a> functions.</li>
326 <li>identical output blocks from a <a href="#block">block
328 <li>repetition of a challenge in a <a
329 href="#challenge">challenge-response</a> system</li>
331 <p>Resisting such attacks is part of the motivation for:</p>
333 <li>hash algorithms such as <a href="#SHA">SHA</a> and <a
334 href="#RIPEMD">RIPEMD-160</a> giving a 160-bit result rather than
335 the 128 bits of <a href="#MD4">MD4</a>, <a href="#MD5">MD5</a> and
336 <a href="#RIPEMD">RIPEMD-128</a>.</li>
337 <li><a href="#AES">AES</a> block ciphers using a 128-bit block
338 instead of the 64-bit block of most current ciphers</li>
339 <li><a href="#IPSEC">IPsec</a> using a 32-bit counter for packets
340 sent on an <a href="#auto">automatically keyed</a> <a
341 href="#SA">SA</a> and requiring that the connection always be
342 rekeyed before the counter overflows.</li>
345 <dt><a name="paradox">Birthday paradox</a></dt>
346 <dd>Not really a paradox, just a rather counter-intuitive mathematical
347 fact. In a group of 23 people, the chance of a least one pair having
348 the same birthday is over 50%.
349 <p>The second person has 1 chance in 365 (ignoring leap years) of
350 matching the first. If they don't match, the third person's chances of
351 matching one of them are 2/365. The 4th, 3/365, and so on. The total of
352 these chances grows more quickly than one might guess.</p>
354 <dt><a name="block">Block cipher</a></dt>
355 <dd>A <a href="#symmetric">symmetric cipher</a> which operates on
356 fixed-size blocks of plaintext, giving a block of ciphertext for each.
357 Contrast with <a href="#stream"> stream cipher</a>. Block ciphers can
358 be used in various <a href="#mode">modes</a> when multiple block are to
360 <p><a href="#DES">DES</a> is among the the best known and widely used
361 block ciphers, but is now obsolete. Its 56-bit key size makes it <a
362 href="#desnotsecure">highly insecure</a> today. <a href="#3DES">Triple
363 DES</a> is the default block cipher for <a href="#FreeSWAN">Linux
365 <p>The current generation of block ciphers -- such as <a
366 href="#Blowfish">Blowfish</a>, <a href="#CAST128">CAST-128</a> and <a
367 href="#IDEA">IDEA</a> -- all use 64-bit blocks and 128-bit keys. The
368 next generation, <a href="#AES">AES</a>, uses 128-bit blocks and
369 supports key sizes up to 256 bits.</p>
370 <p>The <a href="http://www.ii.uib.no/~larsr/bc.html"> Block Cipher
371 Lounge</a> web site has more information.</p>
373 <dt><a name="Blowfish">Blowfish</a></dt>
374 <dd>A <a href="#block">block cipher</a> using 64-bit blocks and keys of
375 up to 448 bits, designed by <a href="#schneier">Bruce Schneier</a> and
376 used in several products.
377 <p>This is not required by the <a href="#IPSEC">IPsec</a> RFCs and not
378 currently used in <a href="#FreeSWAN">Linux FreeS/WAN</a>.</p>
380 <dt><a name="brute">Brute force attack (exhaustive search)</a></dt>
381 <dd>Breaking a cipher by trying all possible keys. This is always
382 possible in theory (except against a <a href="#OTP">one-time pad</a>),
383 but it becomes practical only if the key size is inadequate. For an
384 important example, see our document on the <a
385 href="#desnotsecure">insecurity of DES</a> with its 56-bit key. For an
386 analysis of key sizes required to resist plausible brute force attacks,
387 see <a href="http://www.counterpane.com/keylength.html">this paper</a>.
388 <p>Longer keys protect against brute force attacks. Each extra bit in
389 the key doubles the number of possible keys and therefore doubles the
390 work a brute force attack must do. A large enough key defeats
391 <strong>any</strong> brute force attack.</p>
392 <p>For example, the EFF's <a href="#EFF">DES Cracker</a> searches a
393 56-bit key space in an average of a few days. Let us assume an attacker
394 that can find a 64-bit key (256 times harder) by brute force search in
395 a second (a few hundred thousand times faster). For a 96-bit key, that
396 attacker needs 2<sup>32</sup> seconds, about 135 years. Against a
397 128-bit key, he needs 2<sup>32</sup> times that, over 500,000,000,000
398 years. Your data is then obviously secure against brute force attacks.
399 Even if our estimate of the attacker's speed is off by a factor of a
400 million, it still takes him over 500,000 years to crack a message.</p>
403 <li>single <a href="#DES">DES</a> is now considered <a
404 href="#desnotsecure">dangerously insecure</a></li>
405 <li>all of the current generation of <a href="#block">block
406 ciphers</a> use a 128-bit or longer key</li>
407 <li><a href="#AES">AES</a> ciphers support keysizes 128, 192 and 256
409 <li>any cipher we add to Linux FreeS/WAN will have <em>at least</em>
412 <p><strong>Cautions:</strong><br>
413 <em>Inadequate keylength always indicates a weak cipher</em> but it is
414 important to note that <em>adequate keylength does not necessarily
415 indicate a strong cipher</em>. There are many attacks other than brute
416 force, and adequate keylength <em>only</em> guarantees resistance to
417 brute force. Any cipher, whatever its key size, will be weak if design
418 or implementation flaws allow other attacks.</p>
419 <p>Also, <em>once you have adequate keylength</em> (somewhere around 90
420 or 100 bits), <em>adding more key bits make no practical
421 difference</em>, even against brute force. Consider our 128-bit example
422 above that takes 500,000,000,000 years to break by brute force. We
423 really don't care how many zeroes there are on the end of that, as long
424 as the number remains ridiculously large. That is, we don't care
425 exactly how large the key is as long as it is large enough.</p>
426 <p>There may be reasons of convenience in the design of the cipher to
427 support larger keys. For example <a href="#Blowfish">Blowfish</a>
428 allows up to 448 bits and <a href="#RC4">RC4</a> up to 2048, but beyond
429 100-odd bits it makes no difference to practical security.</p>
431 <dt>Bureau of Export Administration</dt>
432 <dd>see <a href="#BXA">BXA</a></dd>
433 <dt><a name="BXA">BXA</a></dt>
434 <dd>The US Commerce Department's <b>B</b>ureau of E<b>x</b>port
435 <b>A</b>dministration which administers the <a href="#EAR">EAR</a>
436 Export Administration Regulations controling the export of, among other
437 things, cryptography.</dd>
438 <dt><a name="C">C</a></dt>
439 <dt><a name="CA">CA</a></dt>
440 <dd><b>C</b>ertification <b>A</b>uthority, an entity in a <a
441 href="#PKI">public key infrastructure</a> that can certify keys by
442 signing them. Usually CAs form a hierarchy. The top of this hierarchy
443 is called the <a href="#rootCA">root CA</a>.
444 <p>See <a href="#web">Web of Trust</a> for an alternate model.</p>
446 <dt><a name="CAST128">CAST-128</a></dt>
447 <dd>A <a href="#block">block cipher</a> using 64-bit blocks and 128-bit
448 keys, described in RFC 2144 and used in products such as <a
449 href="#Entrust">Entrust</a> and recent versions of <a
451 <p>This is not required by the <a href="#IPSEC">IPsec</a> RFCs and not
452 currently used in <a href="#FreeSWAN">Linux FreeS/WAN</a>.</p>
455 <dd><a href="#Entrust">Entrust</a>'s candidate cipher for the <a
456 href="#AES">AES standard</a>, largely based on the <a
457 href="#CAST128">CAST-128</a> design.</dd>
458 <dt><a name="CBC">CBC mode</a></dt>
459 <dd><b>C</b>ipher <b>B</b>lock <b>C</b>haining <a href="#mode">mode</a>,
460 a method of using a <a href="#block">block cipher</a> in which for each
461 block except the first, the result of the previous encryption is XORed
462 into the new block before it is encrypted. CBC is the mode used in <a
463 href="#IPSEC">IPsec</a>.
464 <p>An <a href="#IV">initialisation vector</a> (IV) must be provided. It
465 is XORed into the first block before encryption. The IV need not be
466 secret but should be different for each message and unpredictable.</p>
468 <dt>Certification Authority</dt>
469 <dd>see <a href="#CA">CA</a></dd>
470 <dt><a name="challenge">Challenge-response authentication</a></dt>
471 <dd>An <a href="#authentication">authentication</a> system in which one
472 player generates a <a href="#random">random number</a>, encrypts it and
473 sends the result as a challenge. The other player decrypts and sends
474 back the result. If the result is correct, that proves to the first
475 player that the second player knew the appropriate secret, required for
476 the decryption. Variations on this technique exist using <a
477 href="#public">public key</a> or <a href="#symmetric">symmetric</a>
478 cryptography. Some provide two-way authentication, assuring each player
479 of the other's identity.
480 <p>This is more secure than passwords against two simple attacks:</p>
482 <li>If cleartext passwords are sent across the wire (e.g. for
483 telnet), an eavesdropper can grab them. The attacker may even be
484 able to break into other systems if the user has chosen the same
485 password for them.</li>
486 <li>If an encrypted password is sent, an attacker can record the
487 encrypted form and use it later. This is called a replay
490 <p>A challenge-response system never sends a password, either cleartext
491 or encrypted. An attacker cannot record the response to one challenge
492 and use it as a response to a later challenge. The random number is
493 different each time.</p>
494 <p>Of course an attacker might still try to break the cryptographic
495 algorithm used, or the <a href="#random">random number</a>
498 <dt><a name="mode">Cipher Modes</a></dt>
499 <dd>Different ways of using a block cipher when encrypting multiple
501 <p>Four standard modes were defined for <a href="#DES">DES</a> in <a
502 href="#FIPS">FIPS</a> 81. They can actually be applied with any block
509 <td><a href="#ECB">ECB</a></td>
510 <td>Electronic CodeBook</td>
511 <td>encrypt each block independently</td>
515 <td><a href="#CBC">CBC</a></td>
516 <td>Cipher Block Chaining<br>
518 <td>XOR previous block ciphertext into new block plaintext before
519 encrypting new block</td>
524 <td>Cipher FeedBack</td>
530 <td>Output FeedBack</td>
535 <p><a href="#IPSEC">IPsec</a> uses <a href="#CBC">CBC</a> mode since
536 this is only marginally slower than <a href="#ECB">ECB</a> and is more
537 secure. In ECB mode the same plaintext always encrypts to the same
538 ciphertext, unless the key is changed. In CBC mode, this does not
540 <p>Various other modes are also possible, but none of them are used in
543 <dt><a name="ciphertext">Ciphertext</a></dt>
544 <dd>The encrypted output of a cipher, as opposed to the unencrypted <a
545 href="#plaintext">plaintext</a> input.</dd>
546 <dt><a href="http://www.cisco.com">Cisco</a></dt>
547 <dd>A vendor of routers, hubs and related products. Their IPsec products
548 interoperate with Linux FreeS/WAN; see our <a
549 href="interop.html#Cisco">interop</a> section.</dd>
550 <dt><a name="client">Client</a></dt>
551 <dd>This term has at least two distinct uses in discussing IPsec:
553 <li>The <strong>clients of an IPsec gateway</strong> are the machines
554 it protects, typically on one or more subnets behind the gateway.
555 In this usage, all the machines on an office network are clients of
556 that office's IPsec gateway. Laptop or home machines connecting to
557 the office, however, are <em>not</em> clients of that gateway. They
558 are remote gateways, running the other end of an IPsec connection.
559 Each of them is also its own client.</li>
560 <li><strong>IPsec client software</strong> is used to describe
561 software which runs on various standalone machines to let them
562 connect to IPsec networks. In this usage, a laptop or home machine
563 connecting to the office is a client, and the office gateway is the
566 <p>We generally use the term in the first sense. Vendors of Windows
567 IPsec solutions often use it in the second. See this <a
568 href="interop.html#client.server">discussion</a>.</p>
570 <dt><a name="cc">Common Criteria</a></dt>
571 <dd>A set of international security classifications which are replacing
572 the old US <a href="#rainbow">Rainbow Book</a> standards and similar
573 standards in other countries.
574 <p>Web references include this <a href="http://csrc.nist.gov/cc">US
575 government site</a> and this <a
576 href="http://www.commoncriteria.org">global home page</a>.</p>
578 <dt>Conventional cryptography</dt>
579 <dd>See <a href="#symmetric">symmetric cryptography</a></dd>
580 <dt><a name="collision">Collision resistance</a></dt>
581 <dd>The property of a <a href="#digest">message digest</a> algorithm
582 which makes it hard for an attacker to find or construct two inputs
583 which hash to the same output.</dd>
585 <dd>see GNU <a href="#GPL">General Public License</a></dd>
586 <dt><a name="CSE">CSE</a></dt>
587 <dd><a href="http://www.cse-cst.gc.ca/">Communications Security
588 Establishment</a>, the Canadian organisation for <a
589 href="#SIGINT">signals intelligence</a>.</dd>
590 <dt><a name="D">D</a></dt>
591 <dt><a name="DARPA">DARPA (sometimes just ARPA)</a></dt>
592 <dd>The US government's <b>D</b>efense <b>A</b>dvanced <b>R</b>esearch
593 <b>P</b>rojects <b>A</b>gency. Projects they have funded over the years
594 have included the Arpanet which evolved into the Internet, the TCP/IP
595 protocol suite (as a replacement for the original Arpanet suite), the
596 Berkeley 4.x BSD Unix projects, and <a href="#SDNS">Secure DNS</a>.
597 <p>For current information, see their <a
598 href="http://www.darpa.mil/ito">web site</a>.</p>
600 <dt><a name="DOS">Denial of service (DoS) attack</a></dt>
601 <dd>An attack that aims at denying some service to legitimate users of a
602 system, rather than providing a service to the attacker.
604 <li>One variant is a flooding attack, overwhelming the system with
605 too many packets, to much email, or whatever.</li>
606 <li>A closely related variant is a resource exhaustion attack. For
607 example, consider a "TCP SYN flood" attack. Setting up a TCP
608 connection involves a three-packet exchange:
610 <li>Initiator: Connection please (SYN)</li>
611 <li>Responder: OK (ACK)</li>
612 <li>Initiator: OK here too</li>
614 <p>If the attacker puts bogus source information in the first
615 packet, such that the second is never delivered, the responder may
616 wait a long time for the third to come back. If responder has
617 already allocated memory for the connection data structures, and if
618 many of these bogus packets arrive, the responder may run out of
621 <li>Another variant is to feed the system undigestible data, hoping
622 to make it sick. For example, IP packets are limited in size to 64K
623 bytes and a fragment carries information on where it starts within
624 that 64K and how long it is. The "ping of death" delivers fragments
625 that say, for example, that they start at 60K and are 20K long.
626 Attempting to re-assemble these without checking for overflow can
629 <p>The two example attacks discussed were both quite effective when
630 first discovered, capable of crashing or disabling many operating
631 systems. They were also well-publicised, and today far fewer systems
632 are vulnerable to them.</p>
634 <dt><a name="DES">DES</a></dt>
635 <dd>The <b>D</b>ata <b>E</b>ncryption <b>S</b>tandard, a <a
636 href="#block">block cipher</a> with 64-bit blocks and a 56-bit key.
637 Probably the most widely used <a href="#symmetric">symmetric cipher</a>
638 ever devised. DES has been a US government standard for their own use
639 (only for unclassified data), and for some regulated industries such as
640 banking, since the late 70's. It is now being replaced by <a
642 <p><a href="politics.html#desnotsecure">DES is seriously insecure
643 against current attacks.</a></p>
644 <p><a href="#FreeSWAN">Linux FreeS/WAN</a> does not include DES, even
645 though the RFCs specify it. <b>We strongly recommend that single DES
647 <p>See also <a href="#3DES">3DES</a> and <a href="#DESX">DESX</a>,
648 stronger ciphers based on DES.</p>
650 <dt><a name="DESX">DESX</a></dt>
651 <dd>An improved <a href="#DES">DES</a> suggested by Ron Rivest of RSA
652 Data Security. It XORs extra key material into the text before and
653 after applying the DES cipher.
654 <p>This is not required by the <a href="#IPSEC">IPsec</a> RFCs and not
655 currently used in <a href="#FreeSWAN">Linux FreeS/WAN</a>. DESX would
656 be the easiest additional transform to add; there would be very little
657 code to write. It would be much faster than 3DES and almost certainly
658 more secure than DES. However, since it is not in the RFCs other IPsec
659 implementations cannot be expected to have it.</p>
662 <dd>see <a href="#DH">Diffie-Hellman</a></dd>
663 <dt><a name="DHCP">DHCP</a></dt>
664 <dd><strong>D</strong>ynamic <strong>H</strong>ost
665 <strong>C</strong>onfiguration <strong>P</strong>rotocol, a method of
666 assigning <a href="#dynamic">dynamic IP addresses</a>, and providing
667 additional information such as addresses of DNS servers and of
668 gateways. See this <a href="http://www.dhcp.org">DHCP resource
670 <dt><a name="DH">Diffie-Hellman (DH) key exchange protocol</a></dt>
671 <dd>A protocol that allows two parties without any initial shared secret
672 to create one in a manner immune to eavesdropping. Once they have done
673 this, they can communicate privately by using that shared secret as a
674 key for a block cipher or as the basis for key exchange.
675 <p>The protocol is secure against all <a href="#passive">passive
676 attacks</a>, but it is not at all resistant to active <a
677 href="#middle">man-in-the-middle attacks</a>. If a third party can
678 impersonate Bob to Alice and vice versa, then no useful secret can be
679 created. Authentication of the participants is a prerequisite for safe
680 Diffie-Hellman key exchange. IPsec can use any of several <a
681 href="#authentication">authentication</a> mechanisims. Those supported
682 by FreeS/WAN are discussed in our <a
683 href="config.html#choose">configuration</a> section.</p>
684 <p>The Diffie-Hellman key exchange is based on the <a
685 href="#dlog">discrete logarithm</a> problem and is secure unless
686 someone finds an efficient solution to that problem.</p>
687 <p>Given a prime <var>p</var> and generator <var>g</var> (explained
688 under <a href="#dlog">discrete log</a> below), Alice:</p>
690 <li>generates a random number <var>a</var></li>
691 <li>calculates <var>A = g^a modulo p</var></li>
692 <li>sends <var>A</var> to Bob</li>
694 <p>Meanwhile Bob:</p>
696 <li>generates a random number <var>b</var></li>
697 <li>calculates <var>B = g^b modulo p</var></li>
698 <li>sends <var>B</var> to Alice</li>
700 <p>Now Alice and Bob can both calculate the shared secret <var>s =
701 g^(ab)</var>. Alice knows <var>a</var> and <var>B</var>, so she
702 calculates <var>s = B^a</var>. Bob knows <var>A</var> and <var>b</var>
703 so he calculates <var>s = A^b</var>.</p>
704 <p>An eavesdropper will know <var>p</var> and <var>g</var> since these
705 are made public, and can intercept <var>A</var> and <var>B</var> but,
706 short of solving the <a href="#dlog">discrete log</a> problem, these do
707 not let him or her discover the secret <var>s</var>.</p>
709 <dt><a name="signature">Digital signature</a></dt>
712 <li>calculates a <a href="#digest">message digest</a> of a
714 <li>encrypts the digest with his or her private key, using some <a
715 href="#public">public key cryptosystem</a>.</li>
716 <li>attaches the encrypted digest to the document as a signature</li>
720 <li>calculates a digest of the document (not including the
722 <li>decrypts the signature with the signer's public key</li>
723 <li>verifies that the two results are identical</li>
725 <p>If the public-key system is secure and the verification succeeds,
726 then the receiver knows</p>
728 <li>that the document was not altered between signing and
730 <li>that the signer had access to the private key</li>
732 <p>Such an encrypted message digest can be treated as a signature since
733 it cannot be created without <em>both</em> the document <em>and</em>
734 the private key which only the sender should possess. The <a
735 href="web.html#legal">legal issues</a> are complex, but several
736 countries are moving in the direction of legal recognition for digital
739 <dt><a name="dlog">discrete logarithm problem</a></dt>
740 <dd>The problem of finding logarithms in a finite field. Given a field
741 defintion (such definitions always include some operation analogous to
742 multiplication) and two numbers, a base and a target, find the power
743 which the base must be raised to in order to yield the target.
744 <p>The discrete log problem is the basis of several cryptographic
745 systems, including the <a href="#DH">Diffie-Hellman</a> key exchange
746 used in the <a href="#IKE">IKE</a> protocol. The useful property is
747 that exponentiation is relatively easy but the inverse operation,
748 finding the logarithm, is hard. The cryptosystems are designed so that
749 the user does only easy operations (exponentiation in the field) but an
750 attacker must solve the hard problem (discrete log) to crack the
752 <p>There are several variants of the problem for different types of
753 field. The IKE/Oakley key determination protocol uses two variants,
754 either over a field modulo a prime or over a field defined by an
755 elliptic curve. We give an example modulo a prime below. For the
756 elliptic curve version, consult an advanced text such as <a
757 href="biblio.html#handbook">Handbook of Applied Cryptography</a>.</p>
758 <p>Given a prime <var>p</var>, a generator <var>g</var> for the field
759 modulo that prime, and a number <var>x</var> in the field, the problem
760 is to find <var>y</var> such that <var>g^y = x</var>.</p>
761 <p>For example, let p = 13. The field is then the integers from 0 to
762 12. Any integer equals one of these modulo 13. That is, the remainder
763 when any integer is divided by 13 must be one of these.</p>
764 <p>2 is a generator for this field. That is, the powers of two modulo
765 13 run through all the non-zero numbers in the field. Modulo 13 we
772 2^4 == 3 that is, the remainder from 16/13 is 3
773 2^5 == 6 the remainder from 32/13 is 6
781 <p>Exponentiation in such a field is not difficult. Given, say,
782 <nobr><var>y = 11</var>,</nobr>calculating <nobr><var>x =
783 7</var></nobr>is straightforward. One method is just to calculate
784 <nobr><var>2^11 = 2048</var>,</nobr>then <nobr><var>2048 mod 13 ==
785 7</var>.</nobr>When the field is modulo a large prime (say a few 100
786 digits) you need a silghtly cleverer method and even that is moderately
787 expensive in computer time, but the calculation is still not
788 problematic in any basic way.</p>
789 <p>The discrete log problem is the reverse. In our example, given
790 <nobr><var>x = 7</var>,</nobr>find the logarithm <nobr><var>y =
791 11</var>.</nobr>When the field is modulo a large prime (or is based on
792 a suitable elliptic curve), this is indeed problematic. No solution
793 method that is not catastrophically expensive is known. Quite a few
794 mathematicians have tackled this problem. No efficient method has been
795 found and mathematicians do not expect that one will be. It seems
796 likely no efficient solution to either of the main variants the
797 discrete log problem exists.</p>
798 <p>Note, however, that no-one has proven such methods do not exist. If
799 a solution to either variant were found, the security of any crypto
800 system using that variant would be destroyed. This is one reason <a
801 href="#IKE">IKE</a> supports two variants. If one is broken, we can
802 switch to the other.</p>
804 <dt><a name="discretionary">discretionary access control</a></dt>
805 <dd>access control mechanisms controlled by the user, for example Unix
806 rwx file permissions. These contrast with <a
807 href="#mandatory">mandatory access controls</a>.</dd>
808 <dt><a name="DNS">DNS</a></dt>
809 <dd><b>D</b>omain <b>N</b>ame <b>S</b>ervice, a distributed database
810 through which names are associated with numeric addresses and other
811 information in the Internet Protocol Suite. See also the <a
812 href="background.html#dns.background">DNS background</a> section of our
815 <dd>see <a href="#DOS">Denial Of Service</a> attack</dd>
816 <dt><a name="dynamic">dynamic IP address</a></dt>
817 <dd>an IP address which is automatically assigned, either by <a
818 href="#DHCP">DHCP</a> or by some protocol such as <a
819 href="#PPP">PPP</a> or <a href="#PPPoE">PPPoE</a> which the machine
820 uses to connect to the Internet. This is the opposite of a <a
821 href="#static">static IP address</a>, pre-set on the machine
823 <dt><a name="E">E</a></dt>
824 <dt><a name="EAR">EAR</a></dt>
825 <dd>The US government's <b>E</b>xport <b>A</b>dministration
826 <b>R</b>egulations, administered by the <a href="#BXA">Bureau of Export
827 Administration</a>. These have replaced the earlier <a
828 href="#ITAR">ITAR</a> regulations as the controls on export of
830 <dt><a name="ECB">ECB mode</a></dt>
831 <dd><b>E</b>lectronic <b>C</b>ode<b>B</b>ook mode, the simplest way to
832 use a block cipher. See <a href="#mode">Cipher Modes</a>.</dd>
833 <dt><a name="EDE">EDE</a></dt>
834 <dd>The sequence of operations normally used in either the three-key
835 variant of <a href="#3DES">triple DES</a> used in <a
836 href="#IPSEC">IPsec</a> or the <a href="#2key">two-key</a> variant used
837 in some other systems.
838 <p>The sequence is:</p>
840 <li><b>E</b>ncrypt with key1</li>
841 <li><b>D</b>ecrypt with key2</li>
842 <li><b>E</b>ncrypt with key3</li>
844 <p>For the two-key version, key1=key3.</p>
845 <p>The "advantage" of this EDE order of operations is that it makes it
846 simple to interoperate with older devices offering only single DES. Set
847 key1=key2=key3 and you have the worst of both worlds, the overhead of
848 triple DES with the "security" of single DES. Since both the <a
849 href="politics.html#desnotsecure">security of single DES</a> and the
850 overheads of triple DES are seriously inferior to many other ciphers,
851 this is a spectacularly dubious "advantage".</p>
853 <dt><a name="Entrust">Entrust</a></dt>
854 <dd>A Canadian company offerring enterprise <a href="#PKI">PKI</a>
855 products using <a href="#CAST128">CAST-128</a> symmetric crypto, <a
856 href="#RSA">RSA</a> public key and <a href="#X509">X.509</a>
857 directories. <a href="http://www.entrust.com">Web site</a></dd>
858 <dt><a name="EFF">EFF</a></dt>
859 <dd><a href="http://www.eff.org">Electronic Frontier Foundation</a>, an
860 advocacy group for civil rights in cyberspace.</dd>
861 <dt><a name="encryption">Encryption</a></dt>
862 <dd>Techniques for converting a readable message (<a
863 href="#plaintext">plaintext</a>) into apparently random material (<a
864 href="#ciphertext">ciphertext</a>) which cannot be read if intercepted.
865 A key is required to read the message.
866 <p>Major variants include <a href="#symmetric">symmetric</a> encryption
867 in which sender and receiver use the same secret key and <a
868 href="#public">public key</a> methods in which the sender uses one of a
869 matched pair of keys and the receiver uses the other. Many current
870 systems, including <a href="#IPSEC">IPsec</a>, are <a
871 href="#hybrid">hybrids</a> combining the two techniques.</p>
873 <dt><a name="ESP">ESP</a></dt>
874 <dd><b>E</b>ncapsulated <b>S</b>ecurity <b>P</b>ayload, the <a
875 href="#IPSEC">IPsec</a> protocol which provides <a
876 href="#encryption">encryption</a>. It can also provide <a
877 href="#authentication">authentication</a> service and may be used with
878 null encryption (which we do not recommend). For details see our <a
879 href="ipsec.html#ESP.ipsec">IPsec</a> document and/or RFC 2406.</dd>
880 <dt><a name="#extruded">Extruded subnet</a></dt>
881 <dd>A situation in which something IP sees as one network is actually in
883 <p>For example, the Internet may route all traffic for a particular
884 company to that firm's corporate gateway. It then becomes the company's
885 problem to get packets to various machines on their <a
886 href="#subnet">subnets</a> in various departments. They may decide to
887 treat a branch office like a subnet, giving it IP addresses "on" their
888 corporate net. This becomes an extruded subnet.</p>
889 <p>Packets bound for it are delivered to the corporate gateway, since
890 as far as the outside world is concerned, that subnet is part of the
891 corporate network. However, instead of going onto the corporate LAN (as
892 they would for, say, the accounting department) they are then
893 encapsulated and sent back onto the Internet for delivery to the branch
895 <p>For information on doing this with Linux FreeS/WAN, look in our <a
896 href="adv_config.html#extruded.config">advanced configuration</a>
899 <dt>Exhaustive search</dt>
900 <dd>See <a href="#brute">brute force attack</a>.</dd>
901 <dt><a name="F">F</a></dt>
902 <dt><a name="FIPS">FIPS</a></dt>
903 <dd><b>F</b>ederal <b>I</b>nformation <b>P</b>rocessing <b>S</b>tandard,
904 the US government's standards for products it buys. These are issued by
905 <a href="#NIST">NIST</a>. Among other things, <a href="#DES">DES</a>
906 and <a href="#SHA">SHA</a> are defined in FIPS documents. NIST have a
907 <a href="http://www.itl.nist.gov/div897/pubs">FIPS home page</a>.</dd>
908 <dt><a name="FSF">Free Software Foundation (FSF)</a></dt>
909 <dd>An organisation to promote free software, free in the sense of these
910 quotes from their web pages</dd>
913 "Free software" is a matter of liberty, not price. To understand the
914 concept, you should think of "free speech", not "free beer."
915 <p>"Free software" refers to the users' freedom to run, copy,
916 distribute, study, change and improve the software.</p>
918 <p>See also <a href="#GNU">GNU</a>, <a href="#GPL">GNU General Public
919 License</a>, and <a href="http://www.fsf.org">the FSF site</a>.</p>
922 <dd>see <a href="#FreeSWAN">Linux FreeS/WAN</a></dd>
924 <dd>see <a href="#FSF">Free software Foundation</a></dd>
925 <dt><a name="G">G</a></dt>
926 <dt><a name="GCHQ">GCHQ</a></dt>
927 <dd><a href="http://www.gchq.gov.uk">Government Communications
928 Headquarters</a>, the British organisation for <a
929 href="#SIGINT">signals intelligence</a>.</dd>
930 <dt>generator of a prime field</dt>
931 <dd>see <a href="#dlog">discrete logarithm problem</a></dd>
932 <dt><a name="GILC">GILC</a></dt>
933 <dd><a href="http://www.gilc.org">Global Internet Liberty Campaign</a>,
934 an international organisation advocating, among other things, free
935 availability of cryptography. They have a <a
936 href="http://www.gilc.org/crypto/wassenaar">campaign</a> to remove
937 cryptographic software from the <a href="#Wassenaar.gloss">Wassenaar
938 Arrangement</a>.</dd>
939 <dt>Global Internet Liberty Campaign</dt>
940 <dd>see <a href="#GILC">GILC</a>.</dd>
941 <dt><a name="GTR">Global Trust Register</a></dt>
942 <dd>An attempt to create something like a <a href="#rootCA">root CA</a>
943 for <a href="#PGP">PGP</a> by publishing both <a
944 href="biblio.html#GTR">as a book</a> and <a
945 href="http://www.cl.cam.ac.uk/Research/Security/Trust-Register"> on the
946 web</a> the fingerprints of a set of verified keys for well-known users
947 and organisations.</dd>
948 <dt><a name="GMP">GMP</a></dt>
949 <dd>The <b>G</b>NU <b>M</b>ulti-<b>P</b>recision library code, used in <a
950 href="#FreeSWAN">Linux FreeS/WAN</a> by <a href="#Pluto">Pluto</a> for
951 <a href="#public">public key</a> calculations. See the <a
952 href="http://www.swox.com/gmp">GMP home page</a>.</dd>
953 <dt><a name="GNU">GNU</a></dt>
954 <dd><b>G</b>NU's <b>N</b>ot <b>U</b>nix, the <a href="#FSF">Free Software
955 Foundation's</a> project aimed at creating a free system with at least
956 the capabilities of Unix. <a href="#Linux">Linux</a> uses GNU utilities
958 <dt><a name="#GOST">GOST</a></dt>
959 <dd>a Soviet government standard <a href="#block">block cipher</a>. <a
960 href="biblio.html#schneier">Applied Cryptography</a> has details.</dd>
962 <dd>see <a href="#GPG">GNU Privacy Guard</a></dd>
963 <dt><a name="GPL">GNU General Public License</a>(GPL, copyleft)</dt>
964 <dd>The license developed by the <a href="#FSF">Free Software
965 Foundation</a> under which <a href="#Linux">Linux</a>, <a
966 href="#FreeSWAN">Linux FreeS/WAN</a> and many other pieces of software
967 are distributed. The license allows anyone to redistribute and modify
968 the code, but forbids anyone from distributing executables without
969 providing access to source code. For more details see the file <a
970 href="../COPYING">COPYING</a> included with GPLed source distributions,
971 including ours, or <a href="http://www.fsf.org/copyleft/gpl.html"> the
972 GNU site's GPL page</a>.</dd>
973 <dt><a name="GPG">GNU Privacy Guard</a></dt>
974 <dd>An open source implementation of Open <a href="#PGP">PGP</a> as
975 defined in RFC 2440. See their <a href="http://www.gnupg.org">web
978 <dd>see <a href="#GPL">GNU General Public License</a>.</dd>
979 <dt><a name="H">H</a></dt>
980 <dt><a name="hash">Hash</a></dt>
981 <dd>see <a href="#digest">message digest</a></dd>
982 <dt><a name="HMAC">Hashed Message Authentication Code (HMAC)</a></dt>
983 <dd>using keyed <a href="#digest">message digest</a> functions to
984 authenticate a message. This differs from other uses of these functions:
986 <li>In normal usage, the hash function's internal variable are
987 initialised in some standard way. Anyone can reproduce the hash to
988 check that the message has not been altered.</li>
989 <li>For HMAC usage, you initialise the internal variables from the
990 key. Only someone with the key can reproduce the hash. A successful
991 check of the hash indicates not only that the message is unchanged
992 but also that the creator knew the key.</li>
994 <p>The exact techniques used in <a href="#IPSEC">IPsec</a> are defined
995 in RFC 2104. They are referred to as HMAC-MD5-96 and HMAC-SHA-96
996 because they output only 96 bits of the hash. This makes some attacks
997 on the hash functions harder.</p>
1000 <dd>see <a href="#HMAC">Hashed Message Authentication Code</a></dd>
1001 <dt>HMAC-MD5-96</dt>
1002 <dd>see <a href="#HMAC">Hashed Message Authentication Code</a></dd>
1003 <dt>HMAC-SHA-96</dt>
1004 <dd>see <a href="#HMAC">Hashed Message Authentication Code</a></dd>
1005 <dt><a name="hybrid">Hybrid cryptosystem</a></dt>
1006 <dd>A system using both <a href="#public">public key</a> and <a
1007 href="#symmetric">symmetric cipher</a> techniques. This works well.
1008 Public key methods provide key management and <a
1009 href="#signature">digital signature</a> facilities which are not
1010 readily available using symmetric ciphers. The symmetric cipher,
1011 however, can do the bulk of the encryption work much more efficiently
1012 than public key methods.</dd>
1013 <dt><a name="I">I</a></dt>
1014 <dt><a name="IAB">IAB</a></dt>
1015 <dd><a href="http://www.iab.org/iab">Internet Architecture Board</a>.</dd>
1016 <dt><a name="ICMP.gloss">ICMP</a></dt>
1017 <dd><strong>I</strong>nternet <strong>C</strong>ontrol
1018 <strong>M</strong>essage <strong>P</strong>rotocol. This is used for
1019 various IP-connected devices to manage the network.</dd>
1020 <dt><a name="IDEA">IDEA</a></dt>
1021 <dd><b>I</b>nternational <b>D</b>ata <b>E</b>ncrypion <b>A</b>lgorithm,
1022 developed in Europe as an alternative to exportable American ciphers
1023 such as <a href="#DES">DES</a> which were <a href="#desnotsecure">too
1024 weak for serious use</a>. IDEA is a <a href="#block">block cipher</a>
1025 using 64-bit blocks and 128-bit keys, and is used in products such as
1026 <a href="#PGP">PGP</a>.
1027 <p>IDEA is not required by the <a href="#IPSEC">IPsec</a> RFCs and not
1028 currently used in <a href="#FreeSWAN">Linux FreeS/WAN</a>.</p>
1029 <p>IDEA is patented and, with strictly limited exceptions for personal
1030 use, using it requires a license from <a
1031 href="http://www.ascom.com">Ascom</a>.</p>
1033 <dt><a name="IEEE">IEEE</a></dt>
1034 <dd><a href="http://www.ieee.org">Institute of Electrical and Electronic
1035 Engineers</a>, a professional association which, among other things,
1036 sets some technical standards</dd>
1037 <dt><a name="IESG">IESG</a></dt>
1038 <dd><a href="http://www.iesg.org">Internet Engineering Steering
1040 <dt><a name="IETF">IETF</a></dt>
1041 <dd><a href="http://www.ietf.org">Internet Engineering Task Force</a>,
1042 the umbrella organisation whose various working groups make most of the
1043 technical decisions for the Internet. The IETF <a
1044 href="http://www.ietf.org/html.charters/ipsec-charter.html"> IPsec
1045 working group</a> wrote the <a href="#RFC">RFCs</a> we are
1047 <dt><a name="IKE">IKE</a></dt>
1048 <dd><b>I</b>nternet <b>K</b>ey <b>E</b>xchange, based on the <a
1049 href="#DH">Diffie-Hellman</a> key exchange protocol. For details, see
1050 RFC 2409 and our <a href="ipsec.html">IPsec</a> document. IKE is
1051 implemented in <a href="#FreeSWAN">Linux FreeS/WAN</a> by the <a
1052 href="#Pluto">Pluto daemon</a>.</dd>
1054 <dd>A proposed replacement for <a href="#IKE">IKE</a>. There are other
1055 candidates, such as <a href="#JFK">JFK</a>, and at time of writing
1056 (March 2002) the choice between them has not yet been made and does not
1057 appear imminent..</dd>
1058 <dt><a name="IV">Initialisation Vector (IV)</a></dt>
1059 <dd>Some cipher <a href="#mode">modes</a>, including the <a
1060 href="#CBC">CBC</a> mode which IPsec uses, require some extra data at
1061 the beginning. This data is called the initialisation vector. It need
1062 not be secret, but should be different for each message. Its function
1063 is to prevent messages which begin with the same text from encrypting
1064 to the same ciphertext. That might give an analyst an opening, so it is
1065 best prevented.</dd>
1066 <dt><a name="IP">IP</a></dt>
1067 <dd><b>I</b>nternet <b>P</b>rotocol.</dd>
1068 <dt><a name="masq">IP masquerade</a></dt>
1069 <dd>A mostly obsolete term for a method of allowing multiple machines to
1070 communicate over the Internet when only one IP address is available for
1071 their use. The more current term is Network Address Translation or <a
1072 href="#NAT.gloss">NAT</a>.</dd>
1073 <dt><a name="IPng">IPng</a></dt>
1074 <dd>"IP the Next Generation", see <a href="#ipv6.gloss">IPv6</a>.</dd>
1075 <dt><a name="IPv4">IPv4</a></dt>
1076 <dd>The current version of the <a href="#IP">Internet protocol
1078 <dt><a name="ipv6.gloss">IPv6 (IPng)</a></dt>
1079 <dd>Version six of the <a href="#IP">Internet protocol suite</a>,
1080 currently being developed. It will replace the current <a
1081 href="#IPv4">version four</a>. IPv6 has <a href="#IPSEC">IPsec</a> as a
1082 mandatory component.
1084 href="http://playground.sun.com/pub/ipng/html/ipng-main.html">web
1085 site</a> for more details, and our <a
1086 href="compat.html#ipv6">compatibility</a> document for information on
1087 FreeS/WAN and the Linux implementation of IPv6.</p>
1089 <dt><a name="IPSEC">IPsec</a> or IPSEC</dt>
1090 <dd><b>I</b>nternet <b>P</b>rotocol <b>SEC</b>urity, security functions
1091 (<a href="#authentication">authentication</a> and <a
1092 href="#encryption">encryption</a>) implemented at the IP level of the
1093 protocol stack. It is optional for <a href="#IPv4">IPv4</a> and
1094 mandatory for <a href="#ipv6.gloss">IPv6</a>.
1095 <p>This is the standard <a href="#FreeSWAN">Linux FreeS/WAN</a> is
1096 implementing. For more details, see our <a href="ipsec.html">IPsec
1097 Overview</a>. For the standards, see RFCs listed in our <a
1098 href="rfc.html#RFC">RFCs document</a>.</p>
1100 <dt><a name="IPX">IPX</a></dt>
1101 <dd>Novell's Netware protocol tunnelled over an IP link. Our <a
1102 href="firewall.html#user.scripts">firewalls</a> document includes an
1103 example of using this through an IPsec tunnel.</dd>
1104 <dt><a name="ISAKMP">ISAKMP</a></dt>
1105 <dd><b>I</b>nternet <b>S</b>ecurity <b>A</b>ssociation and <b>K</b>ey
1106 <b>M</b>anagement <b>P</b>rotocol, defined in RFC 2408.</dd>
1107 <dt><a name="ITAR">ITAR</a></dt>
1108 <dd><b>I</b>nternational <b>T</b>raffic in <b>A</b>rms
1109 <b>R</b>egulations, US regulations administered by the State Department
1110 which until recently limited export of, among other things,
1111 cryptographic technology and software. ITAR still exists, but the
1112 limits on cryptography have now been transferred to the <a
1113 href="#EAR">Export Administration Regulations</a> under the Commerce
1114 Department's <a href="#BXA">Bureau of Export Administration</a>.</dd>
1116 <dd>see <a href="#IV">Initialisation vector</a></dd>
1117 <dt><a name="J">J</a></dt>
1118 <dt><a name="JFK">JFK</a></dt>
1119 <dd><strong>J</strong>ust <strong>F</strong>ast <strong>K</strong>eying,
1120 a proposed simpler replacement for <a href="#IKE">IKE.</a></dd>
1121 <dt><a name="K">K</a></dt>
1122 <dt><a name="kernel">Kernel</a></dt>
1123 <dd>The basic part of an operating system (e.g. Linux) which controls the
1124 hardware and provides services to all other programs.
1125 <p>In the Linux release numbering system, an even second digit as in
1126 2.<strong>2</strong>.x indicates a stable or production kernel while an
1127 odd number as in 2.<strong>3</strong>.x indicates an experimental or
1128 development kernel. Most users should run a recent kernel version from
1129 the production series. The development kernels are primarily for people
1130 doing kernel development. Others should consider using development
1131 kernels only if they have an urgent need for some feature not yet
1132 available in production kernels.</p>
1134 <dt>Keyed message digest</dt>
1135 <dd>See <a href="#HMAC">HMAC</a>.</dd>
1137 <dd>see <a href="#brute">brute force attack</a></dd>
1138 <dt><a name="KLIPS">KLIPS</a></dt>
1139 <dd><b>K</b>erne<b>l</b> <b>IP</b> <b>S</b>ecurity, the <a
1140 href="#FreeSWAN">Linux FreeS/WAN</a> project's changes to the <a
1141 href="#Linux">Linux</a> kernel to support the <a
1142 href="#IPSEC">IPsec</a> protocols.</dd>
1143 <dt><a name="L">L</a></dt>
1144 <dt><a name="LDAP">LDAP</a></dt>
1145 <dd><b>L</b>ightweight <b>D</b>irectory <b>A</b>ccess <b>P</b>rotocol,
1146 defined in RFCs 1777 and 1778, a method of accessing information
1147 stored in directories. LDAP is used by several <a href="#PKI">PKI</a>
1148 implementations, often with X.501 directories and <a
1149 href="#X509">X.509</a> certificates. It may also be used by <a
1150 href="#IPSEC">IPsec</a> to obtain key certifications from those PKIs.
1151 This is not yet implemented in <a href="#FreeSWAN">Linux
1153 <dt><a name="LIBDES">LIBDES</a></dt>
1154 <dd>A publicly available library of <a href="#DES">DES</a> code, written
1155 by Eric Young, which <a href="#FreeSWAN">Linux FreeS/WAN</a> uses in
1156 both <a href="#KLIPS">KLIPS</a> and <a href="#Pluto">Pluto</a>.</dd>
1157 <dt><a name="Linux">Linux</a></dt>
1158 <dd>A freely available Unix-like operating system based on a kernel
1159 originally written for the Intel 386 architecture by (then) student
1160 Linus Torvalds. Once his 32-bit kernel was available, the <a
1161 href="#GNU">GNU</a> utilities made it a usable system and contributions
1162 from many others led to explosive growth.
1163 <p>Today Linux is a complete Unix replacement available for several CPU
1164 architectures -- Intel, DEC/Compaq Alpha, Power PC, both 32-bit SPARC
1165 and the 64-bit UltraSPARC, SrongARM, . . . -- with support for multiple
1166 CPUs on some architectures.</p>
1167 <p><a href="#FreeSWAN">Linux FreeS/WAN</a> is intended to run on all
1168 CPUs supported by Linux and is known to work on several. See our <a
1169 href="compat.html#CPUs">compatibility</a> section for a list.</p>
1171 <dt><a name="FreeSWAN">Linux FreeS/WAN</a></dt>
1172 <dd>Our implementation of the <a href="#IPSEC">IPsec</a> protocols,
1173 intended to be freely redistributable source code with <a href="#GPL">a
1174 GNU GPL license</a> and no constraints under US or other <a
1175 href="politics.html#exlaw">export laws</a>. Linux FreeS/WAN is intended
1176 to interoperate with other <a href="#IPSEC">IPsec</a> implementations.
1177 The name is partly taken, with permission, from the <a
1178 href="#SWAN">S/WAN</a> multi-vendor IPsec compatability effort. Linux
1179 FreeS/WAN has two major components, <a href="#KLIPS">KLIPS</a> (KerneL
1180 IPsec Support) and the <a href="#Pluto">Pluto</a> daemon which manages
1182 <p>See our <a href="ipsec.html">IPsec section</a> for more detail. For
1183 the code see our <a href="http://freeswan.org"> primary site</a> or one
1184 of the mirror sites on <a href="intro.html#mirrors">this list</a>.</p>
1186 <dt><a name="LSM">Linux Security Modules (LSM)</a></dt>
1187 <dd>a project to create an interface in the Linux kernel that supports
1188 plug-in modules for various security policies.
1189 <p>This allows multiple security projects to take different approaches
1190 to security enhancement without tying the kernel down to one particular
1191 approach. As I understand the history, several projects were pressing
1192 Linus to incorporate their changes, the various sets of changes were
1193 incompatible, and his answer was more-or-less "a plague on all your
1194 houses; I'll give you an interface, but I won't incorporate
1196 <p>It seems to be working. There is a fairly active <a
1197 href="http://mail.wirex.com/mailman/listinfo/linux-security-module">LSM
1198 mailing list</a>, and several projects are already using the
1202 <dd>see <a href="#LSM">Linux Security Modules</a></dd>
1203 <dt><a name="M">M</a></dt>
1204 <dt><a name="list">Mailing list</a></dt>
1205 <dd>The <a href="#FreeSWAN">Linux FreeS/WAN</a> project has several
1206 public email lists for bug reports and software development
1207 discussions. See our document on <a href="mail.html">mailing
1209 <dt><a name="middle">Man-in-the-middle attack</a></dt>
1210 <dd>An <a href="#active">active attack</a> in which the attacker
1211 impersonates each of the legitimate players in a protocol to the other.
1212 <p>For example, if <a href="#alicebob">Alice and Bob</a> are
1213 negotiating a key via the <a href="#DH">Diffie-Hellman</a> key
1214 agreement, and are not using <a
1215 href="#authentication">authentication</a> to be certain they are
1216 talking to each other, then an attacker able to insert himself in the
1217 communication path can deceive both players.</p>
1218 <p>Call the attacker Mallory. For Bob, he pretends to be Alice. For
1219 Alice, he pretends to be Bob. Two keys are then negotiated,
1220 Alice-to-Mallory and Bob-to-Mallory. Alice and Bob each think the key
1221 they have is Alice-to-Bob.</p>
1222 <p>A message from Alice to Bob then goes to Mallory who decrypts it,
1223 reads it and/or saves a copy, re-encrypts using the Bob-to-Mallory key
1224 and sends it along to Bob. Bob decrypts successfully and sends a reply
1225 which Mallory decrypts, reads, re-encrypts and forwards to Alice.</p>
1226 <p>To make this attack effective, Mallory must</p>
1228 <li>subvert some part of the network in some way that lets him carry
1229 out the deception<br>
1230 possible targets: DNS, router, Alice or Bob's machine, mail server,
1232 <li>beat any authentication mechanism Alice and Bob use<br>
1233 strong authentication defeats the attack entirely; this is why <a
1234 href="#IKE">IKE</a> requires authentication</li>
1235 <li>work in real time, delivering messages without introducing a
1236 delay large enough to alert the victims<br>
1237 not hard if Alice and Bob are using email; quite difficult in some
1240 <p>If he manages it, however, it is devastating. He not only gets to
1241 read all the messages; he can alter messages, inject his own, forge
1242 anything he likes, . . . In fact, he controls the communication
1245 <dt><a name="mandatory">mandatory access control</a></dt>
1246 <dd>access control mechanisims which are not settable by the user (see <a
1247 href="#discretionary">discretionary access control</a>), but are
1248 enforced by the system.
1249 <p>For example, a document labelled "secret, zebra" might be readable
1250 only by someone with secret clearance working on Project Zebra.
1251 Ideally, the system will prevent any transfer outside those boundaries.
1252 For example, even if you can read it, you should not be able to e-mail
1253 it (unless the recipient is appropriately cleared) or print it (unless
1254 certain printers are authorised for that classification).</p>
1255 <p>Mandatory access control is a required feature for some levels of <a
1256 href="#rainbow">Rainbow Book</a> or <a href="#cc">Common Criteria</a>
1257 classification, but has not been widely used outside the military and
1258 government. There is a good discussion of the issues in Anderson's <a
1259 href="biblio.html#anderson">Security Engineering</a>.</p>
1260 <p>The <a href="#SElinux">Security Enhanced Linux</a> project is adding
1261 mandatory access control to Linux.</p>
1263 <dt><a name="manual">Manual keying</a></dt>
1264 <dd>An IPsec mode in which the keys are provided by the administrator. In
1265 FreeS/WAN, they are stored in /etc/ipsec.conf. The alternative, <a
1266 href="#auto">automatic keying</a>, is preferred in most cases. See this
1267 <a href="adv_config.html#man-auto">discussion</a>.</dd>
1268 <dt><a name="MD4">MD4</a></dt>
1269 <dd><a href="#digest">Message Digest Algorithm</a> Four from Ron Rivest
1270 of <a href="#RSAco">RSA</a>. MD4 was widely used a few years ago, but
1271 is now considered obsolete. It has been replaced by its descendants <a
1272 href="#MD5">MD5</a> and <a href="#SHA">SHA</a>.</dd>
1273 <dt><a name="MD5">MD5</a></dt>
1274 <dd><a href="#digest">Message Digest Algorithm</a> Five from Ron Rivest
1275 of <a href="#RSAco">RSA</a>, an improved variant of his <a
1276 href="#MD4">MD4</a>. Like MD4, it produces a 128-bit hash. For details
1278 <p>MD5 is one of two message digest algorithms available in IPsec. The
1279 other is <a href="#SHA">SHA</a>. SHA produces a longer hash and is
1280 therefore more resistant to <a href="#birthday">birthday attacks</a>,
1281 but this is not a concern for IPsec. The <a href="#HMAC">HMAC</a>
1282 method used in IPsec is secure even if the underlying hash is not
1283 particularly strong against this attack.</p>
1284 <p>Hans Dobbertin found a weakness in MD5, and people often ask whether
1285 this means MD5 is unsafe for IPsec. It doesn't. The IPsec RFCs discuss
1286 Dobbertin's attack and conclude that it does not affect MD5 as used for
1289 <dt><a name="meet">Meet-in-the-middle attack</a></dt>
1290 <dd>A divide-and-conquer attack which breaks a cipher into two parts,
1291 works against each separately, and compares results. Probably the best
1292 known example is an attack on double DES. This applies in principle to
1293 any pair of block ciphers, e.g. to an encryption system using, say,
1294 CAST-128 and Blowfish, but we will describe it for double DES.
1295 <p>Double DES encryption and decryption can be written:</p>
1296 <pre> C = E(k2,E(k1,P))
1297 P = D(k1,D(k2,C))</pre>
1298 <p>Where C is ciphertext, P is plaintext, E is encryption, D is
1299 decryption, k1 is one key, and k2 is the other key. If we know a P, C
1300 pair, we can try and find the keys with a brute force attack, trying
1301 all possible k1, k2 pairs. Since each key is 56 bits, there are
1302 2<sup>112</sup> such pairs and this attack is painfully inefficient.</p>
1303 <p>The meet-in-the middle attack re-writes the equations to calculate a
1307 <p>Now we can try some large number of D(k2,C) decryptions with various
1308 values of k2 and store the results in a table. Then start doing E(k1,P)
1309 encryptions, checking each result to see if it is in the table.</p>
1310 <p>With enough table space, this breaks double DES with
1311 <nobr>2<sup>56</sup> + 2<sup>56</sup> = 2<sup>57</sup></nobr>work.
1312 Against triple DES, you need <nobr>2<sup>56</sup> + 2<sup>112</sup> ~=
1313 2<sup>112</sup></nobr>.</p>
1314 <p>The memory requirements for such attacks can be prohibitive, but
1315 there is a whole body of research literature on methods of reducing
1318 <dt><a name="digest">Message Digest Algorithm</a></dt>
1319 <dd>An algorithm which takes a message as input and produces a hash or
1320 digest of it, a fixed-length set of bits which depend on the message
1321 contents in some highly complex manner. Design criteria include making
1322 it extremely difficult for anyone to counterfeit a digest or to change
1323 a message without altering its digest. One essential property is <a
1324 href="#collision">collision resistance</a>. The main applications are
1325 in message <a href="#authentication">authentication</a> and <a
1326 href="#signature">digital signature</a> schemes. Widely used algorithms
1327 include <a href="#MD5">MD5</a> and <a href="#SHA">SHA</a>. In IPsec,
1328 message digests are used for <a href="#HMAC">HMAC</a> authentication of
1330 <dt><a name="MTU">MTU</a></dt>
1331 <dd><strong>M</strong>aximum <strong>T</strong>ransmission
1332 <strong>U</strong>nit, the largest size of packet that can be sent over
1333 a link. This is determined by the underlying network, but must be taken
1334 account of at the IP level.
1335 <p>IP packets, which can be up to 64K bytes each, must be packaged into
1336 lower-level packets of the appropriate size for the underlying
1337 network(s) and re-assembled on the other end. When a packet must pass
1338 over multiple networks, each with its own MTU, and many of the MTUs are
1339 unknown to the sender, this becomes a fairly complex problem. See <a
1340 href="#pathMTU">path MTU discovery</a> for details.</p>
1341 <p>Often the MTU is a few hundred bytes on serial links and 1500 on
1342 Ethernet. There are, however, serial link protocols which use a larger
1343 MTU to avoid fragmentation at the ethernet/serial boundary, and newer
1344 (especially gigabit) Ethernet networks sometimes support much larger
1345 packets because these are more efficient in some applications.</p>
1347 <dt><a name="N">N</a></dt>
1348 <dt><a name="NAI">NAI</a></dt>
1349 <dd><a href="http://www.nai.com">Network Associates</a>, a conglomerate
1350 formed from <a href="#PGPI">PGP Inc.</a>, TIS (Trusted Information
1351 Systems, a firewall vendor) and McAfee anti-virus products. Among other
1352 things, they offer an IPsec-based VPN product.</dd>
1353 <dt><a name="NAT.gloss">NAT</a></dt>
1354 <dd><b>N</b>etwork <b>A</b>ddress <b>T</b>ranslation, a process by which
1355 firewall machines may change the addresses on packets as they go
1356 through. For discussion, see our <a
1357 href="background.html#nat.background">background</a> section.</dd>
1358 <dt><a name="NIST">NIST</a></dt>
1359 <dd>The US <a href="http://www.nist.gov"> National Institute of Standards
1360 and Technology</a>, responsible for <a href="#FIPS">FIPS standards</a>
1361 including <a href="#DES">DES</a> and its replacement, <a
1362 href="#AES">AES</a>.</dd>
1363 <dt><a name="nonce">Nonce</a></dt>
1364 <dd>A <a href="#random">random</a> value used in an <a
1365 href="#authentication">authentication</a> protocol.</dd>
1367 <dt><a name="non-routable">Non-routable IP address</a></dt>
1368 <dd>An IP address not normally allowed in the "to" or "from" IP address
1369 field header of IP packets.
1370 <p>Almost invariably, the phrase "non-routable address" means one of
1371 the addresses reserved by RFC 1918 for private networks:</p>
1373 <li>10.anything</li>
1374 <li>172.x.anything with 16 <= x <= 31</li>
1375 <li>192.168.anything</li>
1377 <p>These addresses are commonly used on private networks, e.g. behind a
1378 Linux machines doing <a href="#masq">IP masquerade</a>. Machines within
1379 the private network can address each other with these addresses. All
1380 packets going outside that network, however, have these addresses
1381 replaced before they reach the Internet.</p>
1382 <p>If any packets using these addresses do leak out, they do not go
1383 far. Most routers automatically discard all such packets.</p>
1384 <p>Various other addresses -- the 127.0.0.0/8 block reserved for local
1385 use, 0.0.0.0, various broadcast and network addresses -- cannot be
1386 routed over the Internet, but are not normally included in the meaning
1387 when the phrase "non-routable address" is used.</p>
1389 <dt><a name="NSA">NSA</a></dt>
1390 <dd>The US <a href="http://www.nsa.gov"> National Security Agency</a>,
1391 the American organisation for <a href="#SIGINT">signals
1392 intelligence</a>, the protection of US government messages and the
1393 interception and analysis of other messages. For details, see Bamford's
1394 <a href="biblio.html#puzzle">"The Puzzle Palace"</a>.
1396 href="http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/index.html">history
1397 of NSA</a> documents were declassified in response to a FOIA (Freedom
1398 of Information Act) request.</p>
1400 <dt><a name="O">O</a></dt>
1401 <dt><a name="oakley">Oakley</a></dt>
1402 <dd>A key determination protocol, defined in RFC 2412.</dd>
1403 <dt>Oakley groups</dt>
1404 <dd>The groups used as the basis of <a href="#DH">Diffie-Hellman</a> key
1405 exchange in the Oakley protocol, and in <a href="#IKE">IKE</a>. Four
1406 were defined in the original RFC, and a fifth has been <a
1407 href="http://www.lounge.org/ike_doi_errata.html">added since</a>.
1408 <p>Linux FreeS/WAN currently supports the three groups based on finite
1409 fields modulo a prime (Groups 1, 2 and 5) and does not support the
1410 elliptic curve groups (3 and 4). For a description of the difference of
1411 the types, see <a href="#dlog">discrete logarithms</a>.</p>
1413 <dt><a name="OTP">One time pad</a></dt>
1414 <dd>A cipher in which the key is:
1416 <li>as long as the total set of messages to be enciphered</li>
1417 <li>absolutely <a href="#random">random</a></li>
1418 <li>never re-used</li>
1420 <p>Given those three conditions, it can easily be proved that the
1421 cipher is perfectly secure, in the sense that an attacker with
1422 intercepted message in hand has no better chance of guessing the
1423 message than an attacker who has not intercepted the message and only
1424 knows the message length. No such proof exists for any other cipher.</p>
1425 <p>There are, however, several problems with this "perfect" cipher.</p>
1426 <p>First, it is <strong>wildly impractical</strong> for most
1427 applications. Key management is at best difficult, often completely
1429 <p>Second, it is <strong>extremely fragile</strong>. Small changes
1430 which violate the conditions listed above do not just weaken the cipher
1431 liitle. Quite often they destroy its security completely.</p>
1433 <li>Re-using the pad weakens the cipher to the point where it can be
1434 broken with pencil and paper. With a computer, the attack is
1435 trivially easy.</li>
1436 <li>Using <em>anything</em> less than truly <a
1437 href="#random">random</a> numbers <em>completely</em> invalidates
1438 the security proof.</li>
1439 <li>In particular, using computer-generated pseudo-random numbers may
1440 give an extremely weak cipher. It might also produce a good stream
1441 cipher, if the pseudo-random generator is both well-designed and
1442 properely seeded.</li>
1444 <p>Marketing claims about the "unbreakable" security of various
1445 products which somewhat resemble one-time pads are common. Such claims
1446 are one of the surest signs of cryptographic <a href="#snake">snake
1447 oil</a>; most systems marketed with such claims are worthless.</p>
1448 <p>Finally, even if the system is implemented and used correctly, it is
1449 <strong>highly vulnerable to a substitution attack</strong>. If an
1450 attacker knows some plaintext and has an intercepted message, he can
1451 discover the pad.</p>
1453 <li>This does not matter if the attacker is just a <a
1454 href="#passive">passive</a> eavesdropper. It gives him no plaintext
1455 he didn't already know and we don't care that he learns a pad which
1456 we will never re-use.</li>
1457 <li>However, an <a href="#active">active</a> attacker who knows the
1458 plaintext can recover the pad, then use it to encode with whatever
1459 he chooses. If he can get his version delivered instead of yours,
1460 this may be a disaster. If you send "attack at dawn", the delivered
1461 message can be anything the same length -- perhaps "retreat to
1462 east" or "shoot generals".</li>
1463 <li>An active attacker with only a reasonable guess at the plaintext
1464 can try the same attack. If the guess is correct, this works and
1465 the attacker's bogus message is delivered. If the guess is wrong, a
1466 garbled message is delivered.</li>
1468 <p>In general then, despite its theoretical perfection, the
1469 one-time-pad has very limited practical application.</p>
1470 <p>See also the <a href="http://pubweb.nfr.net/~mjr/pubs/otpfaq/">one
1471 time pad FAQ</a>.</p>
1473 <dt><a name="carpediem">Opportunistic encryption</a></dt>
1474 <dd>A situation in which any two IPsec-aware machines can secure their
1475 communications, without a pre-shared secret and without a common <a
1476 href="#PKI">PKI</a> or previous exchange of public keys. This is one of
1477 the goals of the Linux FreeS/WAN project, discussed in our <a
1478 href="intro.html#goals">introduction</a> section.
1479 <p>Setting up for opportunistic encryption is described in our <a
1480 href="config.html#oppex">configuration</a> document.</p>
1482 <dt><a name="orange">Orange book</a></dt>
1483 <dd>the most basic and best known of the US government's <a
1484 href="#rainbow">Rainbow Book</a> series of computer security
1486 <dt><a name="P">P</a></dt>
1487 <dt><a name="P1363">P1363 standard</a></dt>
1488 <dd>An <a href="#IEEE">IEEE</a> standard for public key cryptography. <a
1489 href="http://grouper.ieee.org/groups/1363">Web page</a>.</dd>
1490 <dt><a name="passive">Passive attack</a></dt>
1491 <dd>An attack in which the attacker only eavesdrops and attempts to
1492 analyse intercepted messages, as opposed to an <a href="#active">active
1493 attack</a> in which he diverts messages or generates his own.</dd>
1494 <dt><a name="pathMTU">Path MTU discovery</a></dt>
1495 <dd>The process of discovering the largest packet size which all links on
1496 a path can handle without fragmentation -- that is, without any router
1497 having to break the packet up into smaller pieces to match the <a
1498 href="#MTU">MTU</a> of its outgoing link.
1499 <p>This is done as follows:</p>
1501 <li>originator sends the largest packets allowed by <a
1502 href="#MTU">MTU</a> of the first link, setting the DF
1503 (<strong>d</strong>on't <strong>f</strong>ragment) bit in the
1505 <li>any router which cannot send the packet on (outgoing MTU is too
1506 small for it, and DF prevents fragmenting it to match) sends back
1507 an <a href="#ICMP.gloss">ICMP</a> packet reporting the problem</li>
1508 <li>originator looks at ICMP message and tries a smaller size</li>
1509 <li>eventually, you settle on a size that can pass all routers</li>
1510 <li>thereafter, originator just sends that size and no-one has to
1513 <p>Since this requires co-operation of many systems, and since the next
1514 packet may travel a different path, this is one of the trickier areas
1515 of IP programming. Bugs that have shown up over the years have
1518 <li>malformed ICMP messages</li>
1519 <li>hosts that ignore or mishandle these ICMP messages</li>
1520 <li>firewalls blocking the ICMP messages so host does not see
1523 <p>Since IPsec adds a header, it increases packet size and may require
1524 fragmentation even where incoming and outgoing MTU are equal.</p>
1526 <dt><a name="PFS">Perfect forward secrecy (PFS)</a></dt>
1527 <dd>A property of systems such as <a href="#DH">Diffie-Hellman</a> key
1528 exchange which use a long-term key (such as the shared secret in IKE)
1529 and generate short-term keys as required. If an attacker who acquires
1530 the long-term key <em>provably</em> can
1532 <li><em>neither</em> read previous messages which he may have
1534 <li><em>nor</em> read future messages without performing additional
1535 successful attacks</li>
1537 <p>then the system has PFS. The attacker needs the short-term keys in
1538 order to read the trafiic and merely having the long-term key does not
1539 allow him to infer those. Of course, it may allow him to conduct
1540 another attack (such as <a href="#middle">man-in-the-middle</a>) which
1541 gives him some short-term keys, but he does not automatically get them
1542 just by acquiring the long-term key.</p>
1545 <dd>see Perfect Forward Secrecy</dd>
1546 <dt><a name="PGP">PGP</a></dt>
1547 <dd><b>P</b>retty <b>G</b>ood <b>P</b>rivacy, a personal encryption
1548 system for email based on public key technology, written by Phil
1550 <p>The 2.xx versions of PGP used the <a href="#RSA">RSA</a> public key
1551 algorithm and used <a href="#IDEA">IDEA</a> as the symmetric cipher.
1552 These versions are described in RFC 1991 and in <a
1553 href="#PGP">Garfinkel's book</a>. Since version 5, the products from <a
1554 href="#PGPI">PGP Inc</a>. have used <a href="#DH">Diffie-Hellman</a>
1555 public key methods and <a href="#CAST128">CAST-128</a> symmetric
1556 encryption. These can verify signatures from the 2.xx versions, but
1557 cannot exchange encryted messages with them.</p>
1558 <p>An <a href="#IETF">IETF</a> working group has issued RFC 2440 for an
1559 "Open PGP" standard, similar to the 5.x versions. PGP Inc. staff were
1560 among the authors. A free <a href="#GPG">Gnu Privacy Guard</a> based on
1561 that standard is now available.</p>
1562 <p>For more information on PGP, including how to obtain it, see our
1563 cryptography <a href="web.html#tools">links</a>.</p>
1565 <dt><a name="PGPI">PGP Inc.</a></dt>
1566 <dd>A company founded by Zimmerman, the author of <a href="#PGP">PGP</a>,
1567 now a division of <a href="#NAI">NAI</a>. See the <a
1568 href="http://www.pgp.com">corporate website</a>. Zimmerman left in
1569 2001, and early in 2002 NAI announced that they would no longer sell
1571 <p>Versions 6.5 and later of the PGP product include PGPnet, an IPsec
1572 client for Macintosh or for Windows 95/98/NT. See our <a
1573 href="interop.html#pgpnet">interoperation documen</a>t.</p>
1575 <dt><a name="photuris">Photuris</a></dt>
1576 <dd>Another key negotiation protocol, an alternative to <a
1577 href="#IKE">IKE</a>, described in RFCs 2522 and 2523.</dd>
1578 <dt><a name="PPP">PPP</a></dt>
1579 <dd><b>P</b>oint-to-<b>P</b>oint <b>P</b>rotocol, originally a method of
1580 connecting over modems or serial lines, but see also PPPoE.</dd>
1581 <dt><a name="PPPoE">PPPoE</a></dt>
1582 <dd><b>PPP</b> <b>o</b>ver <b>E</b>thernet, a somewhat odd protocol that
1583 makes Ethernet look like a point-to-point serial link. It is widely
1584 used for cable or ADSL Internet services, apparently mainly because it
1585 lets the providers use access control and address assignmment
1586 mechanisms developed for dialup networks. <a
1587 href="http://www.roaringpenguin.com">Roaring Penguin</a> provide a
1588 widely used Linux implementation.</dd>
1589 <dt><a name="PPTP">PPTP</a></dt>
1590 <dd><b>P</b>oint-to-<b>P</b>oint <b>T</b>unneling <b>P</b>rotocol, used
1591 in some Microsoft VPN implementations. Papers discussing weaknesses in
1593 href="http://www.counterpane.com/publish.html">counterpane.com</a>. It
1594 is now largely obsolete, replaced by L2TP.</dd>
1595 <dt><a name="PKI">PKI</a></dt>
1596 <dd><b>P</b>ublic <b>K</b>ey <b>I</b>nfrastructure, the things an
1597 organisation or community needs to set up in order to make <a
1598 href="#public">public key</a> cryptographic technology a standard part
1599 of their operating procedures.
1600 <p>There are several PKI products on the market. Typically they use a
1601 hierarchy of <a href="#CA">Certification Authorities (CAs)</a>. Often
1602 they use <a href="#LDAP">LDAP</a> access to <a href="#X509">X.509</a>
1603 directories to implement this.</p>
1604 <p>See <a href="#web">Web of Trust</a> for a different sort of
1607 <dt><a name="PKIX">PKIX</a></dt>
1608 <dd><b>PKI</b> e<b>X</b>change, an <a href="#IETF">IETF</a> standard that
1609 allows <a href="#PKI">PKI</a>s to talk to each other.
1610 <p>This is required, for example, when users of a corporate PKI need to
1611 communicate with people at client, supplier or government
1612 organisations, any of which may have a different PKI in place. I should
1613 be able to talk to you securely whenever:</p>
1615 <li>your organisation and mine each have a PKI in place</li>
1616 <li>you and I are each set up to use those PKIs</li>
1617 <li>the two PKIs speak PKIX</li>
1618 <li>the configuration allows the conversation</li>
1620 <p>At time of writing (March 1999), this is not yet widely implemented
1621 but is under quite active development by several groups.</p>
1623 <dt><a name="plaintext">Plaintext</a></dt>
1624 <dd>The unencrypted input to a cipher, as opposed to the encrypted <a
1625 href="#ciphertext">ciphertext</a> output.</dd>
1626 <dt><a name="Pluto">Pluto</a></dt>
1627 <dd>The <a href="#FreeSWAN">Linux FreeS/WAN</a> daemon which handles key
1628 exchange via the <a href="#IKE">IKE</a> protocol, connection
1629 negotiation, and other higher-level tasks. Pluto calls the <a
1630 href="#KLIPS">KLIPS</a> kernel code as required. For details, see the
1631 manual page ipsec_pluto(8).</dd>
1632 <dt><a name="public">Public Key Cryptography</a></dt>
1633 <dd>In public key cryptography, keys are created in matched pairs.
1634 Encrypt with one half of a pair and only the matching other half can
1635 decrypt it. This contrasts with <a href="#symmetric">symmetric or
1636 secret key cryptography</a> in which a single key known to both parties
1637 is used for both encryption and decryption.
1638 <p>One half of each pair, called the public key, is made public. The
1639 other half, called the private key, is kept secret. Messages can then
1640 be sent by anyone who knows the public key to the holder of the private
1641 key. Encrypt with the public key and you know that only someone with
1642 the matching private key can decrypt.</p>
1643 <p>Public key techniques can be used to create <a
1644 href="#signature">digital signatures</a> and to deal with key
1645 management issues, perhaps the hardest part of effective deployment of
1646 <a href="#symmetric"> symmetric ciphers</a>. The resulting <a
1647 href="#hybrid">hybrid cryptosystems</a> use public key methods to
1648 manage keys for symmetric ciphers.</p>
1649 <p>Many organisations are currently creating <a href="#PKI">PKIs,
1650 public key infrastructures</a> to make these benefits widely
1653 <dt>Public Key Infrastructure</dt>
1654 <dd>see <a href="#PKI">PKI</a></dd>
1655 <dt><a name="Q">Q</a></dt>
1656 <dt><a name="R">R</a></dt>
1657 <dt><a name="rainbow">Rainbow books</a></dt>
1658 <dd>A set of US government standards for evaluation of "trusted computer
1659 systems", of which the best known was the <a href="#orange">Orange
1660 Book</a>. One fairly often hears references to "C2 security" or a
1661 product "evaluated at B1". The Rainbow books define the standards
1662 referred to in those comments.
1663 <p>See this <a href="http://www.fas.org/irp/nsa/rainbow.htm">reference
1665 <p>The Rainbow books are now mainly obsolete, replaced by the
1666 international <a href="#cc">Common Criteria</a> standards.</p>
1668 <dt><a name="random">Random</a></dt>
1669 <dd>A remarkably tricky term, far too much so for me to attempt a
1670 definition here. Quite a few cryptosystems have been broken via attacks
1671 on weak random number generators, even when the rest of the system was
1674 href="http://nis.nsf.net/internet/documents/rfc/rfc1750.txt">RFC
1675 1750</a> for the theory.</p>
1676 <p>See the manual pages for <a
1677 href="manpage.d/ipsec_ranbits.8.html">ipsec_ranbits(8)</a> and
1678 ipsec_prng(3) for more on FreeS/WAN's use of randomness. Both depend on
1679 the random(4) device driver..</p>
1680 <p>A couple of years ago, there was extensive mailing list discussion
1682 href="http://www.openpgp.net/random/index.html">here</a>)of Linux
1683 /dev/random and FreeS/WAN. Since then, the design of the random(4)
1684 driver has changed considerably. Linux 2.4 kernels have the new
1688 <dd>A firewall product for Windows NT offerring IPsec-based VPN services.
1689 Linux FreeS/WAN interoperates with Raptor; see our <a
1690 href="interop.html#Raptor">interop</a> document for details. Raptor
1691 have recently merged with Axent.</dd>
1692 <dt><a name="RC4">RC4</a></dt>
1693 <dd><b>R</b>ivest <b>C</b>ipher four, designed by Ron Rivest of <a
1694 href="#RSAco">RSA</a> and widely used. Believed highly secure with
1695 adequate key length, but often implemented with inadequate key length
1696 to comply with export restrictions.</dd>
1697 <dt><a name="RC6">RC6</a></dt>
1698 <dd><b>R</b>ivest <b>C</b>ipher six, <a href="#RSAco">RSA</a>'s <a
1699 href="#AES">AES</a> candidate cipher.</dd>
1700 <dt><a name="replay">Replay attack</a></dt>
1701 <dd>An attack in which the attacker records data and later replays it in
1702 an attempt to deceive the recipient.</dd>
1703 <dt><a name="reverse" reverse">Reverse map</a></dt>
1704 <dd>In <a href="#DNS">DNS</a>, a table where IP addresses can be used as
1705 the key for lookups which return a system name and/or other
1708 <dd><b>R</b>equest <b>F</b>or <b>C</b>omments, an Internet document. Some
1709 RFCs are just informative. Others are standards.
1710 <p>Our list of <a href="#IPSEC">IPsec</a> and other security-related
1711 RFCs is <a href="rfc.html#RFC">here</a>, along with information on
1712 methods of obtaining them.</p>
1714 <dt><a name="rijndael">Rijndael</a></dt>
1715 <dd>a <a href="#block">block cipher</a> designed by two Belgian
1716 cryptographers, winner of the US government's <a href="#AES">AES</a>
1717 contest to pick a replacement for <a href="#DES">DES</a>. See the <a
1718 href="http://www.esat.kuleuven.ac.be/~rijmen/rijndael">Rijndael home
1720 <dt><a name="RIPEMD">RIPEMD</a></dt>
1721 <dd>A <a href="#digest">message digest</a> algorithm. The current version
1722 is RIPEMD-160 which gives a 160-bit hash.</dd>
1723 <dt><a name="rootCA">Root CA</a></dt>
1724 <dd>The top level <a href="#CA">Certification Authority</a> in a hierachy
1725 of such authorities.</dd>
1726 <dt><a name="routable">Routable IP address</a></dt>
1727 <dd>Most IP addresses can be used as "to" and "from" addresses in packet
1728 headers. These are the routable addresses; we expect routing to be
1729 possible for them. If we send a packet to one of them, we expect (in
1730 most cases; there are various complications) that it will be delivered
1731 if the address is in use and will cause an <a
1732 href="#ICMP.gloss">ICMP</a> error packet to come back to us if not.
1733 <p>There are also several classes of <a
1734 href="#non-routable">non-routable</a> IP addresses.</p>
1736 <dt><a name="RSA">RSA algorithm</a></dt>
1737 <dd><b>R</b>ivest <b>S</b>hamir <b>A</b>dleman <a href="#public">public
1738 key</a> algorithm, named for its three inventors. It is widely used and
1739 likely to become moreso since it became free of patent encumbrances in
1741 <p>RSA can be used to provide either <a
1742 href="#encryption">encryption</a> or <a href="#signature">digital
1743 signatures</a>. In IPsec, it is used only for signatures. These provide
1744 gateway-to-gateway <a href="#authentication">authentication</a> for <a
1745 href="#IKE">IKE </a>negotiations.</p>
1746 <p>For a full explanation of the algorithm, consult one of the standard
1747 references such as <a href="biblio.html#schneier">Applied
1748 Cryptography</a>. A simple explanation is:</p>
1749 <p>The great 17th century French mathematician <a
1750 href="http://www-groups.dcs.st-andrews.ac.uk/~history/Mathematicians/Fermat.html">Fermat</a>
1752 <p>for any prime p and number x, 0 <= x < p:</p>
1753 <pre> x^p == x modulo p
1754 x^(p-1) == 1 modulo p, non-zero x
1756 <p>From this it follows that if we have a pair of primes p, q and two
1757 numbers e, d such that:</p>
1758 <pre> ed == 1 modulo lcm( p-1, q-1)
1760 where lcm() is least common multiple, then<br>
1761 for all x, 0 <= x < pq:
1762 <pre> x^ed == x modulo pq
1764 <p>So we construct such as set of numbers p, q, e, d and publish the
1765 product N=pq and e as the public key. Using c for <a
1766 href="#ciphertext">ciphertext</a> and i for the input <a
1767 href="#plaintext">plaintext</a>, encryption is then:</p>
1768 <pre> c = i^e modulo N
1770 <p>An attacker cannot deduce i from the cyphertext c, short of either
1771 factoring N or solving the <a href="#dlog">discrete logarithm</a>
1772 problem for this field. If p, q are large primes (hundreds or thousands
1773 of bits) no efficient solution to either problem is known.</p>
1774 <p>The receiver, knowing the private key (N and d), can readily recover
1775 the plaintext p since:</p>
1776 <pre> c^d == (i^e)^d modulo N
1780 <p>This gives an effective public key technique, with only a couple of
1781 problems. It uses a good deal of computer time, since calculations with
1782 large integers are not cheap, and there is no proof it is necessarily
1783 secure since no-one has proven either factoring or discrete log cannot
1784 be done efficiently. Quite a few good mathematicians have tried both
1785 problems, and no-one has announced success, but there is no proof they
1788 <dt><a name="RSAco">RSA Data Security</a></dt>
1789 <dd>A company founded by the inventors of the <a href="#RSA">RSA</a>
1790 public key algorithm.</dd>
1791 <dt><a name="S">S</a></dt>
1792 <dt><a name="SA">SA</a></dt>
1793 <dd><b>S</b>ecurity <b>A</b>ssociation, the channel negotiated by the
1794 higher levels of an <a href="#IPSEC">IPsec</a> implementation (<a
1795 href="#IKE">IKE</a>) and used by the lower (<a href="#ESP">ESP</a> and
1796 <a href="#AH">AH</a>). SAs are unidirectional; you need a pair of them
1797 for two-way communication.
1798 <p>An SA is defined by three things -- the destination, the protocol
1799 (<a href="#AH">AH</a> or<a href="#ESP">ESP</a>) and the <a
1800 href="SPI">SPI</a>, security parameters index. It is used as an index
1801 to look up other things such as session keys and intialisation
1803 <p>For more detail, see our section on <a href="ipsec.html">IPsec</a>
1804 and/or RFC 2401.</p>
1806 <dt><a name="SElinux">SE Linux</a></dt>
1807 <dd><strong>S</strong>ecurity <strong>E</strong>nhanced Linux, an <a
1808 href="#NSA">NSA</a>-funded project to add <a
1809 href="#mandatory">mandatory access control</a> to Linux. See the <a
1810 href="http://www.nsa.gov/selinux">project home page</a>.
1811 <p>According to their web pages, this work will include extending
1812 mandatory access controls to IPsec tunnels.</p>
1813 <p>Recent versions of SE Linux code use the <a href="#LSM">Linux
1814 Security Module</a> interface.</p>
1816 <dt><a name="SDNS">Secure DNS</a></dt>
1817 <dd>A version of the <a href="#DNS">DNS or Domain Name Service</a>
1818 enhanced with authentication services. This is being designed by the <a
1819 href="#IETF">IETF</a> DNS security <a
1820 href="http://www.ietf.org/ids.by.wg/dnssec.html">working group</a>.
1821 Check the <a href="http://www.isc.org/bind.html">Internet Software
1822 Consortium</a> for information on implementation progress and for the
1823 latest version of <a href="#BIND">BIND</a>. Another site has <a
1824 href="http://www.toad.com/~dnssec">more information</a>.
1825 <p><a href="#IPSEC">IPsec</a> can use this plus <a
1826 href="#DH">Diffie-Hellman key exchange</a> to bootstrap itself. This
1827 allows <a href="#carpediem">opportunistic encryption</a>. Any pair of
1828 machines which can authenticate each other via DNS can communicate
1829 securely, without either a pre-existing shared secret or a shared <a
1830 href="#PKI">PKI</a>.</p>
1832 <dt>Secret key cryptography</dt>
1833 <dd>See <a href="#symmetric">symmetric cryptography</a></dd>
1834 <dt>Security Association</dt>
1835 <dd>see <a href="#SA">SA</a></dd>
1836 <dt>Security Enhanced Linux</dt>
1837 <dd>see <a href="#SElinux">SE Linux</a></dd>
1838 <dt><a name="sequence">Sequence number</a></dt>
1839 <dd>A number added to a packet or message which indicates its position in
1840 a sequence of packets or messages. This provides some security against
1841 <a href="#replay">replay attacks</a>.
1842 <p>For <a href="#auto">automatic keying</a> mode, the <a
1843 href="#IPSEC">IPsec</a> RFCs require that the sender generate sequence
1844 numbers for each packet, but leave it optional whether the receiver
1845 does anything with them.</p>
1847 <dt><a name="SHA">SHA</a></dt>
1849 <dd><b>S</b>ecure <b>H</b>ash <b>A</b>lgorithm, a <a
1850 href="#digest">message digest algorithm</a> developed by the <a
1851 href="#NSA">NSA</a> for use in the Digital Signature standard, <a
1852 href="#FIPS">FIPS</a> number 186 from <a href="#NIST">NIST</a>. SHA is
1853 an improved variant of <a href="#MD4">MD4</a> producing a 160-bit hash.
1854 <p>SHA is one of two message digest algorithms available in IPsec. The
1855 other is <a href="#MD5">MD5</a>. Some people do not trust SHA because
1856 it was developed by the <a href="#NSA">NSA</a>. There is, as far as we
1857 know, no cryptographic evidence that SHA is untrustworthy, but this
1858 does not prevent that view from being strongly held.</p>
1859 <p>The NSA made one small change after the release of the original SHA.
1860 They did not give reasons. Iit may be a defense against some attack
1861 they found and do not wish to disclose. Technically the modified
1862 algorithm should be called SHA-1, but since it has replaced the
1863 original algorithm in nearly all applications, it is generally just
1864 referred to as SHA..</p>
1866 <dt><a name="SHA-256">SHA-256</a></dt>
1869 <dd>Newer variants of SHA designed to match the strength of the 128, 192
1870 and 256-bit keys of <a href="#AES">AES</a>. The work to break an
1871 encryption algorithm's strength by <a href="#brute">brute force</a> is
1873 <math xmlns="http://www.w3.org/1998/Math/MathML">
1879 operations but a <a href="birthday">birthday attack </a>on a hash
1881 <math xmlns="http://www.w3.org/1998/Math/MathML">
1891 , so as a general rule you need a hash twice the size of the key to
1892 get similar strength. SHA-256, SHA-384 and SHA-512 are designed to
1893 match the 128, 192 and 256-bit key sizes of AES, respectively.</dd>
1894 <dt><a name="SIGINT">Signals intelligence (SIGINT)</a></dt>
1895 <dd>Activities of government agencies from various nations aimed at
1896 protecting their own communications and reading those of others.
1897 Cryptography, cryptanalysis, wiretapping, interception and monitoring
1898 of various sorts of signals. The players include the American <a
1899 href="#NSA">NSA</a>, British <a href="#GCHQ">GCHQ</a> and Canadian <a
1900 href="#CSE">CSE</a>.</dd>
1901 <dt><a name="SKIP">SKIP</a></dt>
1902 <dd><b>S</b>imple <b>K</b>ey management for <b>I</b>nternet
1903 <b>P</b>rotocols, an alternative to <a href="#IKE">IKE</a> developed by
1904 Sun and being marketed by their <a
1905 href="http://skip.incog.com">Internet Commerce Group</a>.</dd>
1906 <dt><a name="snake">Snake oil</a></dt>
1907 <dd>Bogus cryptography. See the <a
1908 href="http://www.interhack.net/people/cmcurtin/snake-oil-faq.html">
1909 Snake Oil FAQ</a> or <a
1910 href="http://www.counterpane.com/crypto-gram-9902.html#snakeoil">this
1911 paper</a> by Schneier.</dd>
1912 <dt><a name="SPI">SPI</a></dt>
1913 <dd><b>S</b>ecurity <b>P</b>arameter <b>I</b>ndex, an index used within
1914 <a href="#IPSEC">IPsec</a> to keep connections distinct. A <a
1915 href="#SA">Security Association (SA)</a> is defined by destination,
1916 protocol and SPI. Without the SPI, two connections to the same gateway
1917 using the same protocol could not be distinguished.
1918 <p>For more detail, see our <a href="ipsec.html">IPsec</a> section
1919 and/or RFC 2401.</p>
1921 <dt><a name="SSH">SSH</a></dt>
1922 <dd><b>S</b>ecure <b>SH</b>ell, an encrypting replacement for the
1923 insecure Berkeley commands whose names begin with "r" for "remote":
1925 <p>For more information on SSH, including how to obtain it, see our
1926 cryptography <a href="web.html#tools">links</a>.</p>
1928 <dt><a name="SSHco">SSH Communications Security</a></dt>
1929 <dd>A company founded by the authors of <a href="#SSH">SSH</a>. Offices
1930 are in <a href="http://www.ssh.fi">Finland</a> and <a
1931 href="http://www.ipsec.com">California</a>. They have a toolkit for
1932 developers of IPsec applications.</dd>
1933 <dt><a name="SSL">SSL</a></dt>
1934 <dd><a href="http://home.netscape.com/eng/ssl3">Secure Sockets Layer</a>,
1935 a set of encryption and authentication services for web browsers,
1936 developed by Netscape. Widely used in Internet commerce. Also known as
1937 <a href="#TLS">TLS</a>.</dd>
1939 <dd>A free implementation of <a href="#SSL">SSL</a> by Eric Young (eay)
1940 and others. Developed in Australia; not subject to US export
1942 <dt><a name="static">static IP address</a></dt>
1943 <dd>an IP adddress which is pre-set on the machine itself, as opposed to
1944 a <a href="#dynamic">dynamic address</a> which is assigned by a <a
1945 href="#DHCP">DHCP</a> server or obtained as part of the process of
1946 establishing a <a href="#PPP">PPP</a> or <a href="#PPPoE">PPPoE</a>
1948 <dt><a name="stream">Stream cipher</a></dt>
1949 <dd>A <a href="#symmetric">symmetric cipher</a> which produces a stream
1950 of output which can be combined (often using XOR or bytewise addition)
1951 with the plaintext to produce ciphertext. Contrasts with <a
1952 href="#block">block cipher</a>.
1953 <p><a href="#IPSEC">IPsec</a> does not use stream ciphers. Their main
1954 application is link-level encryption, for example of voice, video or
1955 data streams on a wire or a radio signal.</p>
1957 <dt><a name="subnet">subnet</a></dt>
1958 <dd>A group of IP addresses which are logically one network, typically
1959 (but not always) assigned to a group of physically connected machines.
1960 The range of addresses in a subnet is described using a subnet mask.
1961 See next entry.</dd>
1962 <dt>subnet mask</dt>
1963 <dd>A method of indicating the addresses included in a subnet. Here are
1964 two equivalent examples:
1966 <li>101.101.101.0/24</li>
1967 <li>101.101.101.0 with mask 255.255.255.0</li>
1969 <p>The '24' is shorthand for a mask with the top 24 bits one and the
1970 rest zero. This is exactly the same as 255.255.255.0 which has three
1971 all-ones bytes and one all-zeros byte.</p>
1972 <p>These indicate that, for this range of addresses, the top 24 bits
1973 are to be treated as naming a network (often referred to as "the
1974 101.101.101.0/24 subnet") while most combinations of the low 8 bits can
1975 be used to designate machines on that network. Two addresses are
1976 reserved; 101.101.101.0 refers to the subnet rather than a specific
1977 machine while 101.101.101.255 is a broadcast address. 1 to 254 are
1978 available for machines.</p>
1979 <p>It is common to find subnets arranged in a hierarchy. For example, a
1980 large company might have a /16 subnet and allocate /24 subnets within
1981 that to departments. An ISP might have a large subnet and allocate /26
1982 subnets (64 addresses, 62 usable) to business customers and /29 subnets
1983 (8 addresses, 6 usable) to residential clients.</p>
1984 <p>There is a handy calculator for subnet masks available as part of
1985 the free <a href="http://www.monmouth.com/~jsd/dq">dq tool</a>.</p>
1987 <dt><a name="SWAN">S/WAN</a></dt>
1988 <dd>Secure Wide Area Network, a project involving <a href="#RSAco">RSA
1989 Data Security</a> and a number of other companies. The goal was to
1990 ensure that all their <a href="#IPSEC">IPsec</a> implementations would
1991 interoperate so that their customers can communicate with each other
1993 <dt><a name="symmetric">Symmetric cryptography</a></dt>
1994 <dd>Symmetric cryptography, also referred to as conventional or secret
1995 key cryptography, relies on a <em>shared secret key</em>, identical for
1996 sender and receiver. Sender encrypts with that key, receiver decrypts
1997 with it. The idea is that an eavesdropper without the key be unable to
1998 read the messages. There are two main types of symmetric cipher, <a
1999 href="#block">block ciphers</a> and <a href="#stream">stream
2001 <p>Symmetric cryptography contrasts with <a href="#public">public
2002 key</a> or asymmetric systems where the two players use different
2004 <p>The great difficulty in symmetric cryptography is, of course, key
2005 management. Sender and receiver <em>must</em> have identical keys and
2006 those keys <em>must</em> be kept secret from everyone else. Not too
2007 much of a problem if only two people are involved and they can
2008 conveniently meet privately or employ a trusted courier. Quite a
2009 problem, though, in other circumstances.</p>
2010 <p>It gets much worse if there are many people. An application might be
2011 written to use only one key for communication among 100 people, for
2012 example, but there would be serious problems. Do you actually trust all
2013 of them that much? Do they trust each other that much? Should they?
2014 What is at risk if that key is compromised? How are you going to
2015 distribute that key to everyone without risking its secrecy? What do
2016 you do when one of them leaves the company? Will you even know?</p>
2017 <p>On the other hand, if you need unique keys for every possible
2018 connection between a group of 100, then each user must have 99 keys.
2019 You need either 99*100/2 = 4950 <em>secure</em> key exchanges between
2020 users or a central authority that <em>securely</em> distributes 100 key
2021 packets, each with a different set of 99 keys.</p>
2022 <p>Either of these is possible, though tricky, for 100 users. Either
2023 becomes an administrative nightmare for larger numbers. Moreover, keys
2024 <em>must</em> be changed regularly, so the problem of key distribution
2025 comes up again and again. If you use the same key for many messages
2026 then an attacker has more text to work with in an attempt to crack that
2027 key. Moreover, one successful crack will give him or her the text of
2028 all those messages.</p>
2029 <p>In short, the <em>hardest part of conventional cryptography is key
2030 management</em>. Today the standard solution is to build a <a
2031 href="#hybrid">hybrid system</a> using <a href="#public">public key</a>
2032 techniques to manage keys.</p>
2034 <dt><a name="T">T</a></dt>
2035 <dt><a name="TIS">TIS</a></dt>
2036 <dd>Trusted Information Systems, a firewall vendor now part of <a
2037 href="#NAI">NAI</a>. Their Gauntlet product offers IPsec VPN services.
2038 TIS implemented the first version of <a href="#SDNS">Secure DNS</a> on
2039 a <a href="#DARPA">DARPA</a> contract.</dd>
2040 <dt><a name="TLS">TLS</a></dt>
2041 <dd><b>T</b>ransport <b>L</b>ayer <b>S</b>ecurity, a newer name for <a
2042 href="#SSL">SSL</a>.</dd>
2043 <dt><a name="TOS">TOS field</a></dt>
2044 <dd>The <strong>T</strong>ype <strong>O</strong>f
2045 <strong>S</strong>ervice field in an IP header, used to control
2046 qualkity of service routing.</dd>
2047 <dt><a name="traffic">Traffic analysis</a></dt>
2048 <dd>Deducing useful intelligence from patterns of message traffic,
2049 without breaking codes or reading the messages. In one case during
2050 World War II, the British guessed an attack was coming because all
2051 German radio traffic stopped. The "radio silence" order, intended to
2052 preserve security, actually gave the game away.
2053 <p>In an industrial espionage situation, one might deduce something
2054 interesting just by knowing that company A and company B were talking,
2055 especially if one were able to tell which departments were involved, or
2056 if one already knew that A was looking for acquisitions and B was
2057 seeking funds for expansion.</p>
2058 <p>In general, traffic analysis by itself is not very useful. However,
2059 in the context of a larger intelligence effort where quite a bit is
2060 already known, it can be very useful. When you are solving a complex
2061 puzzle, every little bit helps.</p>
2062 <p><a href="#IPSEC">IPsec</a> itself does not defend against traffic
2063 analysis, but carefully thought out systems using IPsec can provide at
2064 least partial protection. In particular, one might want to encrypt more
2065 traffic than was strictly necessary, route things in odd ways, or even
2066 encrypt dummy packets, to confuse the analyst. We discuss this <a
2067 href="ipsec.html#traffic.resist">here</a>.</p>
2069 <dt><a name="transport">Transport mode</a></dt>
2070 <dd>An IPsec application in which the IPsec gateway is the destination of
2071 the protected packets, a machine acts as its own gateway. Contrast with
2072 <a href="#tunnel">tunnel mode</a>.</dd>
2074 <dd>see <a href="#3DES">3DES</a></dd>
2075 <dt><a name="TTL">TTL</a></dt>
2076 <dd><strong>T</strong>ime <strong>T</strong>o <strong>L</strong>ive, used
2077 to control <a href="#DNS">DNS</a> caching. Servers discard cached
2078 records whose TTL expires</dd>
2079 <dt><a name="tunnel">Tunnel mode</a></dt>
2080 <dd>An IPsec application in which an IPsec gateway provides protection
2081 for packets to and from other systems. Contrast with <a
2082 href="#transport">transport mode</a>.</dd>
2083 <dt><a name="2key">Two-key Triple DES</a></dt>
2084 <dd>A variant of <a href="#3DES">triple DES or 3DES</a> in which only two
2085 keys are used. As in the three-key version, the order of operations is
2086 <a href="#EDE">EDE</a> or encrypt-decrypt-encrypt, but in the two-key
2087 variant the first and third keys are the same.
2088 <p>3DES with three keys has 3*56 = 168 bits of key but has only 112-bit
2089 strength against a <a href="#meet">meet-in-the-middle</a> attack, so it
2090 is possible that the two key version is just as strong. Last I looked,
2091 this was an open question in the research literature.</p>
2092 <p>RFC 2451 defines triple DES for <a href="#IPSEC">IPsec</a> as the
2093 three-key variant. The two-key variant should not be used and is not
2094 implemented directly in <a href="#FreeSWAN">Linux FreeS/WAN</a>. It
2095 cannot be used in automatically keyed mode without major fiddles in the
2096 source code. For manually keyed connections, you could make Linux
2097 FreeS/WAN talk to a two-key implementation by setting two keys the same
2098 in /etc/ipsec.conf.</p>
2100 <dt><a name="U">U</a></dt>
2101 <dt><a name="V">V</a></dt>
2102 <dt><a name="virtual">Virtual Interface</a></dt>
2103 <dd>A <a href="#Linux">Linux</a> feature which allows one physical
2104 network interface to have two or more IP addresses. See the <cite>Linux
2105 Network Administrator's Guide</cite> in <a
2106 href="biblio.html#kirch">book form</a> or <a
2107 href="http://metalab.unc.edu/LDP/LDP/nag/node1.html">on the web</a> for
2109 <dt>Virtual Private Network</dt>
2110 <dd>see <a href="#VPN">VPN</a></dd>
2111 <dt><a name="VPN">VPN</a></dt>
2112 <dd><b>V</b>irtual <b>P</b>rivate <b>N</b>etwork, a network which can
2113 safely be used as if it were private, even though some of its
2114 communication uses insecure connections. All traffic on those
2115 connections is encrypted.
2116 <p><a href="#IPSEC">IPsec</a> is not the only technique available for
2117 building VPNs, but it is the only method defined by <a
2118 href="#RFC">RFCs</a> and supported by many vendors. VPNs are by no
2119 means the only thing you can do with IPsec, but they may be the most
2120 important application for many users.</p>
2122 <dt><a name="VPNC">VPNC</a></dt>
2123 <dd><a href="http://www.vpnc.org">Virtual Private Network Consortium</a>,
2124 an association of vendors of VPN products.</dd>
2125 <dt><a name="W">W</a></dt>
2126 <dt><a name="Wassenaar.gloss">Wassenaar Arrangement</a></dt>
2127 <dd>An international agreement restricting export of munitions and other
2128 tools of war. Unfortunately, cryptographic software is also restricted
2129 under the current version of the agreement. <a
2130 href="politics.html#Wassenaar">Discussion</a>.</dd>
2131 <dt><a name="web">Web of Trust</a></dt>
2132 <dd><a href="#PGP">PGP</a>'s method of certifying keys. Any user can sign
2133 a key; you decide which signatures or combinations of signatures to
2134 accept as certification. This contrasts with the hierarchy of <a
2135 href="#CA">CAs (Certification Authorities)</a> used in many <a
2136 href="#PKI">PKIs (Public Key Infrastructures)</a>.
2137 <p>See <a href="#GTR">Global Trust Register</a> for an interesting
2138 addition to the web of trust.</p>
2140 <dt><a name="WEP">WEP (Wired Equivalent Privacy)</a></dt>
2141 <dd>The cryptographic part of the <a href="#IEEE">IEEE</a> standard for
2142 wireless LANs. As the name suggests, this is designed to be only as
2143 secure as a normal wired ethernet. Anyone with a network conection can
2144 tap it. Its advocates would claim this is good design, refusing to
2145 build in complex features beyond the actual requirements.
2146 <p>Critics refer to WEP as "Wire<em>tap</em> Equivalent Privacy", and
2147 consider it a horribly flawed design based on bogus "requirements". You
2148 do not control radio waves as you might control your wires, so the
2149 metaphor in the rationale is utterly inapplicable. A security policy
2150 that chooses not to invest resources in protecting against certain
2151 attacks which can only be conducted by people physically plugged into
2152 your LAN may or may not be reasonable. The same policy is completely
2153 unreasonable when someone can "plug in" from a laptop half a block
2155 <p>There has been considerable analysis indicating that WEP is
2156 seriously flawed. A FAQ on attacks against WEP is available. Part of it
2160 ... attacks are practical to mount using only inexpensive
2161 off-the-shelf equipment. We recommend that anyone using an 802.11
2162 wireless network not rely on WEP for security, and employ other
2163 security measures to protect their wireless network. Note that our
2164 attacks apply to both 40-bit and the so-called 128-bit versions of
2165 WEP equally well.</blockquote>
2166 <p>WEP appears to be yet another instance of governments, and
2167 unfortunately some vendors and standards bodies, deliberately promoting
2168 hopelessly flawed "security" products, apparently mainly for the
2169 benefit of eavesdropping agencies. See this <a
2170 href="politics.html#weak">discussion</a>.</p>
2172 <dt><a name="X">X</a></dt>
2173 <dt><a name="X509">X.509</a></dt>
2174 <dd>A standard from the <a href="http://www.itu.int">ITU (International
2175 Telecommunication Union)</a>, for hierarchical directories with
2176 authentication services, used in many <a href="#PKI">PKI</a>
2178 <p>Use of X.509 services, via the <a href="#LDAP">LDAP protocol</a>,
2179 for certification of keys is allowed but not required by the <a
2180 href="#IPSEC">IPsec</a> RFCs. It is not yet implemented in <a
2181 href="#FreeSWAN">Linux FreeS/WAN</a>.</p>
2184 <dd>A vendor of router and Internet access products, now part of Lucent.
2185 Their QVPN products interoperate with Linux FreeS/WAN; see our <a
2186 href="interop.html#Xedia">interop document</a>.</dd>
2187 <dt><a name="Y">Y</a></dt>
2188 <dt><a name="Z">Z</a></dt>
OSDN Git Service
