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