aboutsummaryrefslogtreecommitdiffstats
path: root/doc/glossary.html
blob: 3ca33810f44fcd03d604115aab3ea6a8472d2215 (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132

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

<!--msup-->

<!--mi-->
 keylength</(null)></(null)></(null)> operations but a<A href="birthday">
 birthday attack</A> on a hash needs only 2
<!--math xmlns="http://www.w3.org/1998/Math/MathML"-->

<!--msup-->

<!--mrow-->

<!--mi-->
 hashlength</(null)>
<!--mo-->
 /</(null)>
<!--mn-->

 2</(null)></(null)></(null)></(null)> , so as a general rule you need a
 hash twice the size of the key to get similar strength. SHA-256,
 SHA-384 and SHA-512 are designed to match the 128, 192 and 256-bit key
 sizes of AES, respectively.</DD>
<DT><A name="SIGINT">Signals intelligence (SIGINT)</A></DT>
<DD>Activities of government agencies from various nations aimed at
 protecting their own communications and reading those of others.
 Cryptography, cryptanalysis, wiretapping, interception and monitoring
 of various sorts of signals. The players include the American<A href="#NSA">
 NSA</A>, British<A href="#GCHQ"> GCHQ</A> and Canadian<A href="#CSE">
 CSE</A>.</DD>
<DT><A name="SKIP">SKIP</A></DT>
<DD><B>S</B>imple<B> K</B>ey management for<B> I</B>nternet<B> P</B>
rotocols, an alternative to<A href="#IKE"> IKE</A> developed by Sun and
 being marketed by their<A href="http://skip.incog.com"> Internet
 Commerce Group</A>.</DD>
<DT><A name="snake">Snake oil</A></DT>
<DD>Bogus cryptography. See the<A href="http://www.interhack.net/people/cmcurtin/snake-oil-faq.html">
 Snake Oil FAQ</A> or<A href="http://www.counterpane.com/crypto-gram-9902.html#snakeoil">
 this paper</A> by Schneier.</DD>
<DT><A name="SPI">SPI</A></DT>
<DD><B>S</B>ecurity<B> P</B>arameter<B> I</B>ndex, an index used within<A
href="#IPSEC"> IPsec</A> to keep connections distinct. A<A href="#SA">
 Security Association (SA)</A> is defined by destination, protocol and
 SPI. Without the SPI, two connections to the same gateway using the
 same protocol could not be distinguished.
<P>For more detail, see our<A href="ipsec.html"> IPsec</A> section
 and/or RFC 2401.</P>
</DD>
<DT><A name="SSH">SSH</A></DT>
<DD><B>S</B>ecure<B> SH</B>ell, an encrypting replacement for the
 insecure Berkeley commands whose names begin with &quot;r&quot; for &quot;remote&quot;:
 rsh, rlogin, etc.
<P>For more information on SSH, including how to obtain it, see our
 cryptography<A href="web.html#tools"> links</A>.</P>
</DD>
<DT><A name="SSHco">SSH Communications Security</A></DT>
<DD>A company founded by the authors of<A href="#SSH"> SSH</A>. Offices
 are in<A href="http://www.ssh.fi"> Finland</A> and<A href="http://www.ipsec.com">
 California</A>. They have a toolkit for developers of IPsec
 applications.</DD>
<DT><A name="SSL">SSL</A></DT>
<DD><A href="http://home.netscape.com/eng/ssl3">Secure Sockets Layer</A>
, a set of encryption and authentication services for web browsers,
 developed by Netscape. Widely used in Internet commerce. Also known as<A
href="#TLS"> TLS</A>.</DD>
<DT>SSLeay</DT>
<DD>A free implementation of<A href="#SSL"> SSL</A> by Eric Young (eay)
 and others. Developed in Australia; not subject to US export controls.</DD>
<DT><A name="static">static IP address</A></DT>
<DD>an IP adddress which is pre-set on the machine itself, as opposed to
 a<A href="#dynamic"> dynamic address</A> which is assigned by a<A href="#DHCP">
 DHCP</A> server or obtained as part of the process of establishing a<A href="#PPP">
 PPP</A> or<A href="#PPPoE"> PPPoE</A> connection</DD>
<DT><A name="stream">Stream cipher</A></DT>
<DD>A<A href="#symmetric"> symmetric cipher</A> which produces a stream
 of output which can be combined (often using XOR or bytewise addition)
 with the plaintext to produce ciphertext. Contrasts with<A href="#block">
 block cipher</A>.
<P><A href="#IPSEC">IPsec</A> does not use stream ciphers. Their main
 application is link-level encryption, for example of voice, video or
 data streams on a wire or a radio signal.</P>
</DD>
<DT><A name="subnet">subnet</A></DT>
<DD>A group of IP addresses which are logically one network, typically
 (but not always) assigned to a group of physically connected machines.
 The range of addresses in a subnet is described using a subnet mask.
 See next entry.</DD>
<DT>subnet mask</DT>
<DD>A method of indicating the addresses included in a subnet. Here are
 two equivalent examples:
<UL>
<LI>101.101.101.0/24</LI>
<LI>101.101.101.0 with mask 255.255.255.0</LI>
</UL>
<P>The '24' is shorthand for a mask with the top 24 bits one and the
 rest zero. This is exactly the same as 255.255.255.0 which has three
 all-ones bytes and one all-zeros byte.</P>
<P>These indicate that, for this range of addresses, the top 24 bits are
 to be treated as naming a network (often referred to as &quot;the
 101.101.101.0/24 subnet&quot;) while most combinations of the low 8 bits can
 be used to designate machines on that network. Two addresses are
 reserved; 101.101.101.0 refers to the subnet rather than a specific
 machine while 101.101.101.255 is a broadcast address. 1 to 254 are
 available for machines.</P>
<P>It is common to find subnets arranged in a hierarchy. For example, a
 large company might have a /16 subnet and allocate /24 subnets within
 that to departments. An ISP might have a large subnet and allocate /26
 subnets (64 addresses, 62 usable) to business customers and /29 subnets
 (8 addresses, 6 usable) to residential clients.</P>
</DD>
<DT><A name="SWAN">S/WAN</A></DT>
<DD>Secure Wide Area Network, a project involving<A href="#RSAco"> RSA
 Data Security</A> and a number of other companies. The goal was to
 ensure that all their<A href="#IPSEC"> IPsec</A> implementations would
 interoperate so that their customers can communicate with each other
 securely.</DD>
<DT><A name="symmetric">Symmetric cryptography</A></DT>
<DD>Symmetric cryptography, also referred to as conventional or secret
 key cryptography, relies on a<EM> shared secret key</EM>, identical for
 sender and receiver. Sender encrypts with that key, receiver decrypts
 with it. The idea is that an eavesdropper without the key be unable to
 read the messages. There are two main types of symmetric cipher,<A href="#block">
 block ciphers</A> and<A href="#stream"> stream ciphers</A>.
<P>Symmetric cryptography contrasts with<A href="#public"> public key</A>
 or asymmetric systems where the two players use different keys.</P>
<P>The great difficulty in symmetric cryptography is, of course, key
 management. Sender and receiver<EM> must</EM> have identical keys and
 those keys<EM> must</EM> be kept secret from everyone else. Not too
 much of a problem if only two people are involved and they can
 conveniently meet privately or employ a trusted courier. Quite a
 problem, though, in other circumstances.</P>
<P>It gets much worse if there are many people. An application might be
 written to use only one key for communication among 100 people, for
 example, but there would be serious problems. Do you actually trust all
 of them that much? Do they trust each other that much? Should they?
 What is at risk if that key is compromised? How are you going to
 distribute that key to everyone without risking its secrecy? What do
 you do when one of them leaves the company? Will you even know?</P>
<P>On the other hand, if you need unique keys for every possible
 connection between a group of 100, then each user must have 99 keys.
 You need either 99*100/2 = 4950<EM> secure</EM> key exchanges between
 users or a central authority that<EM> securely</EM> distributes 100 key
 packets, each with a different set of 99 keys.</P>
<P>Either of these is possible, though tricky, for 100 users. Either
 becomes an administrative nightmare for larger numbers. Moreover, keys<EM>
 must</EM> be changed regularly, so the problem of key distribution
 comes up again and again. If you use the same key for many messages
 then an attacker has more text to work with in an attempt to crack that
 key. Moreover, one successful crack will give him or her the text of
 all those messages.</P>
<P>In short, the<EM> hardest part of conventional cryptography is key
 management</EM>. Today the standard solution is to build a<A href="#hybrid">
 hybrid system</A> using<A href="#public"> public key</A> techniques to
 manage keys.</P>
</DD>
<DT><A name="T">T</A></DT>
<DT><A name="TIS">TIS</A></DT>
<DD>Trusted Information Systems, a firewall vendor now part of<A href="#NAI">
 NAI</A>. Their Gauntlet product offers IPsec VPN services. TIS
 implemented the first version of<A href="#SDNS"> Secure DNS</A> on a<A href="#DARPA">
 DARPA</A> contract.</DD>
<DT><A name="TLS">TLS</A></DT>
<DD><B>T</B>ransport<B> L</B>ayer<B> S</B>ecurity, a newer name for<A href="#SSL">
 SSL</A>.</DD>
<DT><A name="TOS">TOS field</A></DT>
<DD>The<STRONG> T</STRONG>ype<STRONG> O</STRONG>f<STRONG> S</STRONG>
ervice field in an IP header, used to control qualkity of service
 routing.</DD>
<DT><A name="traffic">Traffic analysis</A></DT>
<DD>Deducing useful intelligence from patterns of message traffic,
 without breaking codes or reading the messages. In one case during
 World War II, the British guessed an attack was coming because all
 German radio traffic stopped. The &quot;radio silence&quot; order, intended to
 preserve security, actually gave the game away.
<P>In an industrial espionage situation, one might deduce something
 interesting just by knowing that company A and company B were talking,
 especially if one were able to tell which departments were involved, or
 if one already knew that A was looking for acquisitions and B was
 seeking funds for expansion.</P>
<P>In general, traffic analysis by itself is not very useful. However,
 in the context of a larger intelligence effort where quite a bit is
 already known, it can be very useful. When you are solving a complex
 puzzle, every little bit helps.</P>
<P><A href="#IPSEC">IPsec</A> itself does not defend against traffic
 analysis, but carefully thought out systems using IPsec can provide at
 least partial protection. In particular, one might want to encrypt more
 traffic than was strictly necessary, route things in odd ways, or even
 encrypt dummy packets, to confuse the analyst. We discuss this<A href="ipsec.html#traffic.resist">
 here</A>.</P>
</DD>
<DT><A name="transport">Transport mode</A></DT>
<DD>An IPsec application in which the IPsec gateway is the destination
 of the protected packets, a machine acts as its own gateway. Contrast
 with<A href="#tunnel"> tunnel mode</A>.</DD>
<DT>Triple DES</DT>
<DD>see<A href="#3DES"> 3DES</A></DD>
<DT><A name="TTL">TTL</A></DT>
<DD><STRONG>T</STRONG>ime<STRONG> T</STRONG>o<STRONG> L</STRONG>ive,
 used to control<A href="ipsec.html#DNS"> DNS</A> caching. Servers
 discard cached records whose TTL expires</DD>
<DT><A name="tunnel">Tunnel mode</A></DT>
<DD>An IPsec application in which an IPsec gateway provides protection
 for packets to and from other systems. Contrast with<A href="#transport">
 transport mode</A>.</DD>
<DT><A name="2key">Two-key Triple DES</A></DT>
<DD>A variant of<A href="#3DES"> triple DES or 3DES</A> in which only
 two keys are used. As in the three-key version, the order of operations
 is<A href="#EDE"> EDE</A> or encrypt-decrypt-encrypt, but in the
 two-key variant the first and third keys are the same.
<P>3DES with three keys has 3*56 = 168 bits of key but has only 112-bit
 strength against a<A href="#meet"> meet-in-the-middle</A> attack, so it
 is possible that the two key version is just as strong. Last I looked,
 this was an open question in the research literature.</P>
<P>RFC 2451 defines triple DES for<A href="#IPSEC"> IPsec</A> as the
 three-key variant. The two-key variant should not be used and is not
 implemented directly in<A href="web.html#FreeSWAN"> Linux FreeS/WAN</A>
. It cannot be used in automatically keyed mode without major fiddles in
 the source code. For manually keyed connections, you could make Linux
 FreeS/WAN talk to a two-key implementation by setting two keys the same
 in /etc/ipsec.conf.</P>
</DD>
<DT><A name="U">U</A></DT>
<DT><A name="V">V</A></DT>
<DT><A name="virtual">Virtual Interface</A></DT>
<DD>A<A href="#Linux"> Linux</A> feature which allows one physical
 network interface to have two or more IP addresses. See the<CITE> Linux
 Network Administrator's Guide</CITE> in<A href="biblio.html#kirch">
 book form</A> or<A href="http://metalab.unc.edu/LDP/LDP/nag/node1.html">
 on the web</A> for details.</DD>
<DT>Virtual Private Network</DT>
<DD>see<A href="#VPN"> VPN</A></DD>
<DT><A name="VPN">VPN</A></DT>
<DD><B>V</B>irtual<B> P</B>rivate<B> N</B>etwork, a network which can
 safely be used as if it were private, even though some of its
 communication uses insecure connections. All traffic on those
 connections is encrypted.
<P><A href="#IPSEC">IPsec</A> is not the only technique available for
 building VPNs, but it is the only method defined by<A href="rfc.html#RFC">
 RFCs</A> and supported by many vendors. VPNs are by no means the only
 thing you can do with IPsec, but they may be the most important
 application for many users.</P>
</DD>
<DT><A name="VPNC">VPNC</A></DT>
<DD><A href="http://www.vpnc.org">Virtual Private Network Consortium</A>
, an association of vendors of VPN products.</DD>
<DT><A name="W">W</A></DT>
<DT><A name="Wassenaar.gloss">Wassenaar Arrangement</A></DT>
<DD>An international agreement restricting export of munitions and other
 tools of war. Unfortunately, cryptographic software is also restricted
 under the current version of the agreement.<A href="politics.html#Wassenaar">
 Discussion</A>.</DD>
<DT><A name="web">Web of Trust</A></DT>
<DD><A href="#PGP">PGP</A>'s method of certifying keys. Any user can
 sign a key; you decide which signatures or combinations of signatures
 to accept as certification. This contrasts with the hierarchy of<A href="#CA">
 CAs (Certification Authorities)</A> used in many<A href="#PKI"> PKIs
 (Public Key Infrastructures)</A>.
<P>See<A href="#GTR"> Global Trust Register</A> for an interesting
 addition to the web of trust.</P>
</DD>
<DT><A name="WEP">WEP (Wired Equivalent Privacy)</A></DT>
<DD>The cryptographic part of the<A href="#IEEE"> IEEE</A> standard for
 wireless LANs. As the name suggests, this is designed to be only as
 secure as a normal wired ethernet. Anyone with a network conection can
 tap it. Its advocates would claim this is good design, refusing to
 build in complex features beyond the actual requirements.
<P>Critics refer to WEP as &quot;Wire<EM>tap</EM> Equivalent Privacy&quot;, and
 consider it a horribly flawed design based on bogus &quot;requirements&quot;. You
 do not control radio waves as you might control your wires, so the
 metaphor in the rationale is utterly inapplicable. A security policy
 that chooses not to invest resources in protecting against certain
 attacks which can only be conducted by people physically plugged into
 your LAN may or may not be reasonable. The same policy is completely
 unreasonable when someone can &quot;plug in&quot; from a laptop half a block
 away..</P>
<P>There has been considerable analysis indicating that WEP is seriously
 flawed. A FAQ on attacks against WEP is available. Part of it reads:</P>
<BLOCKQUOTE> ... attacks are practical to mount using only inexpensive
 off-the-shelf equipment. We recommend that anyone using an 802.11
 wireless network not rely on WEP for security, and employ other
 security measures to protect their wireless network. Note that our
 attacks apply to both 40-bit and the so-called 128-bit versions of WEP
 equally well.</BLOCKQUOTE>
<P>WEP appears to be yet another instance of governments, and
 unfortunately some vendors and standards bodies, deliberately promoting
 hopelessly flawed &quot;security&quot; products, apparently mainly for the
 benefit of eavesdropping agencies. See this<A href="politics.html#weak">
 discussion</A>.</P>
</DD>
<DT><A name="X">X</A></DT>
<DT><A name="X509">X.509</A></DT>
<DD>A standard from the<A href="http://www.itu.int"> ITU (International
 Telecommunication Union)</A>, for hierarchical directories with
 authentication services, used in many<A href="#PKI"> PKI</A>
 implementations.
<P>Use of X.509 services, via the<A href="#LDAP"> LDAP protocol</A>, for
 certification of keys is allowed but not required by the<A href="#IPSEC">
 IPsec</A> RFCs. It is not yet implemented in<A href="web.html#FreeSWAN">
 Linux FreeS/WAN</A>.</P>
</DD>
<DT>Xedia</DT>
<DD>A vendor of router and Internet access products, now part of Lucent.
 Their QVPN products interoperate with Linux FreeS/WAN; see our<A href="interop.html#Xedia">
 interop document</A>.</DD>
<DT><A name="Y">Y</A></DT>
<DT><A name="Z">Z</A></DT>
</DL>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="web.html">Previous</A>
<A HREF="biblio.html">Next</A>
</BODY>
</HTML>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-12 00:16:20 +0000