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.

Using three DES 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 Linux
FreeS/WAN.

IPSEC always does 3DES with three different
keys, as required by RFC 2451. For an explanation of the two-key
variant, see two key triple DES. Both use an
EDE encrypt-decrypt-encrpyt sequence of operations.

Double DES is ineffective. Using two 56-bit keys, one might expect
an attacker to have to do 2112 work to break it. In fact,
only 257 work is required with a
meet-in-the-middle attack, 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 2168 one might expect to 2
112. That provides adequate protection against
brute force attacks, and no better attack is known.

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 benchmarks below for details.

An attack in which the attacker does not merely eavesdrop (see
passive attack) but takes action to change, delete, reroute, add,
forge or divert data. Perhaps the best-known active attack is
man-in-the-middle. In general,
authentication is a useful defense against active attacks.

The Advanced Encryption Standard, a new
block cipher standard to replace
DES being developed by NIST, 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 are required to
support 128, 192 and 256-bit keys. Some of them support other sizes as
well. The larger block size helps resist birthday
attacks while the large key size prevents brute
force attacks.

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:

Adding one or more AES ciphers to Linux
FreeS/WAN would be useful undertaking, and considerable freely
available code exists to start from. One complication is that our code
is built for a 64-bit block cipher and AES uses a 128-bit block.
Volunteers via the mailing lists would be welcome.

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.

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 Applied Cryptography

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 replay attack.

A common solution to this problem is a
challenge-response system. This defeats simple eavesdropping and
replay attacks. Of course an attacker might still try to break the
cryptographic algorithm used, or the random number
generator.

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 man-in-the middle attack to break the
security of your IPSEC connections.

However, having an attacker break the authentication in automatic
keying is not quite as bad as losing the key in manual keying.

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.

Automatic keying has a property called perfect
forward secrecy. 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
man-in-the-middle attack 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.

That said, the secrets used for authentication, stored in
ipsec.secrets(5), should still be protected as tightly as
cryptographic keys.

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
interoperation section.

Our default block cipher, triple DES, 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 LIBDES library we use encrypts 1.6
megabytes per second on a Pentium 200, according to the test program
supplied with the library.

Berkeley Internet Name Daemon, a widely
used implementation of DNS (Domain Name Service).
See our bibliography for a useful reference. See
the BIND home page for more
information and the latest version.

A cryptographic attack based on the mathematics exemplified by the birthday paradox. This math turns up whenever the
question of two cryptographic operations producing the same result
becomes an issue:

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%.

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.

A symmetric cipher which operates on
fixed-size blocks of plaintext, giving a block of ciphertext for each.
Contrast with stream cipher. Block ciphers can
be used in various modes when multiple block are
to be encrypted.

DES is among the the best known and widely used
block ciphers, but is now obsolete. Its 56-bit key size makes it
highly insecure today. Triple DES is the
default transform for Linux FreeS/WAN
because it is the only cipher which is both required in the
RFCs and apparently secure.

The current generation of block ciphers -- such as
Blowfish, CAST-128 and IDEA
-- all use 64-bit blocks and 128-bit keys. The next generation,
AES, uses 128-bit blocks and supports key sizes up to 256 bits.

Breaking a cipher by trying all possible keys. This is always
possible in theory (except against a one-time pad),
but it becomes practical only if the key size is inadequate. For an
important example, see our document on the
insecurity of DES with its 56-bit key. For an analysis of key
sizes required to resist plausible brute force attacks, see
this paper.

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
any brute force attack.

For example, the EFF's DES Cracker 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 232 seconds, just over a century.
Against a 128-bit key, he needs 232 centuries or about
400,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 400,000 years to
crack a message.

Cautions: Inadequate keylength always indicates a weak cipher but
it is important to note that adequate keylength does not
necessarily indicate a strong cipher. There are many attacks
other than brute force, and adequate keylength only
guarantees resistance to brute force. Any cipher, whatever its key
size, will be weak if design or implementation flaws allow other
attacks.

Also, once you have adequate keylength (somewhere around
90 or 100 bits), adding more key bits make no practical difference
, even against brute force. Consider our 128-bit example above that
takes 400 billion years to break by brute force. Do we care if an
extra 16 bits of key put that into the quadrillions? No. What about 16
fewer bits reducing it to the 112-bit security level of
Triple DES, which our example attacker could break in just over a
billion years? No again, unless we're being really paranoid about
safety margins.

There may be reasons of convenience in the design of the cipher to
support larger keys. For example Blowfish
allows up to 448 bits and RC4 up to 2048, but
beyond 100-odd bits it makes no difference to practical security.

Cipher Block Chaining mode
, a method of using a block cipher 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 IPSEC.

An initialisation vector (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.

XOR previous block ciphertext into new block plaintext
before encrypting new block

CFB

Cipher FeedBack

OFB

Output FeedBack

IPSEC uses CBC mode since
this is only marginally slower than ECB 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.

Various other modes are also possible, but none of them are used in
IPSEC.

An authentication system in which one
player generates a random number, 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 public key or symmetric
cryptography. Some provide two-way authentication, assuring each
player of the other's identity.

This is more secure than passwords against two simple attacks:

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.

If an encrypted password is sent, an attacker can record the
encrypted form and use it later. This is called a replay attack.

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.

Of course an attacker might still try to break the cryptographic
algorithm used, or the random number generator.

The clients of an IPSEC gateway 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 not clients of that gateway. They are
remote gateways, running the other end of an IPSEC connection. Each of
them is also its own client.

IPSEC client software 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 machine.

We generally use the term in the first sense. Vendors of Windows
IPSEC solutions often use it in the second.

The US government's Defense Advanced Research
Projects Agency. 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 Secure DNS.

An attack that aims at denying some service to legitimate users of
a system, rather than providing a service to the attacker.

One variant is a flooding attack, overwhelming the system with too
many packets, to much email, or whatever.

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:

Initiator: Connection please (SYN)

Responder: OK (ACK)

Initiator: OK here too

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.

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.

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.

The Data Encryption Standard, a
block cipher with 64-bit blocks and a 56-bit key. Probably the
most widely used symmetric cipher 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.

An improved DES suggested by Ron Rivest of RSA
Data Security. It XORs extra key material into the text before and
after applying the DES cipher.

This is not required by the IPSEC RFCs and not
currently used in Linux FreeS/WAN.
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.

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.

The protocol is secure against all passive
attacks, but it is not at all resistant to active
man-in-the-middle attacks. 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
authentication mechanisims. Those supported by FreeS/WAN are
discussed in our configuration section.

The Diffie-Hellman key exchange is based on the
discrete logarithm problem and is secure unless someone finds an
efficient solution to that problem.

Given a prime p and generator g (explained
under discrete log below), Alice:

generates a random number a

calculates A = g^a modulo p

sends A to Bob

Meanwhile Bob:

generates a random number b

calculates B = g^b modulo p

sends B to Alice

Now Alice and Bob can both calculate the shared secret s =
g^(ab). Alice knows a and B, so she
calculates s = B^a. Bob knows A and b
so he calculates s = A^b.

An eavesdropper will know p and g since these
are made public, and can intercept A and B but,
short of solving the discrete log problem, these
do not let him or her discover the secret s.

If the public-key system is secure and the verification succeeds,
then the receiver knows

that the document was not altered between signing and verification

that the signer had access to the private key

Such an encrypted message digest can be treated as a signature
since it cannot be created without both the document and
the private key which only the sender should possess. The
legal issues are complex, but several countries are moving in the
direction of legal recognition for digital signatures.

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.

The discrete log problem is the basis of several cryptographic
systems, including the Diffie-Hellman key exchange
used in the IKE 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.

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
Handbook of Applied Cryptography.

Given a prime p, a generator g for the field
modulo that prime, and a number x in the field, the problem
is to find y such that g^y = x.

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.

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:

Exponentiation in such a field is not difficult. Given, say,
y = 11, calculating x = 7 is
straightforward. One method is just to calculate 2^11 = 2048
, then 2048 mod 13 == 7. 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.

The discrete log problem is the reverse. In our example, given x = 7, find the logarithm y = 11.
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.

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
IKE supports two variants. If one is broken, we can switch to the
other.

Domain Name Service, a distributed database
through which names are associated with numeric addresses and other
information in the Internet Protocol Suite. See also
BIND, the Berkeley Internet Name Daemon which implements DNS
services and Secure DNS. See our bibliography for
a useful reference on both.

The sequence of operations normally used in either the three-key
variant of triple DES used in
IPSEC or the two-key variant used in some
other systems.

The sequence is:

Encrypt with key1

Decrypt with key2

Encrypt with key3

For the two-key version, key1=key3.

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
single DES is insecure, this is an extremely dubious "advantage".

The EDE two-key variant can also interoperate with the EDE
three-key variant used in IPSEC; just set k1=k3.

Techniques for converting a readable message (
plaintext) into apparently random material (
ciphertext) which cannot be read if intercepted. A key is required
to read the message.

Major variants include symmetric encryption
in which sender and receiver use the same secret key and
public key methods in which the sender uses one of a matched pair
of keys and the receiver uses the other. Many current systems,
including IPSEC, are hybrids
combining the two techniques.

Encapsulated Security Payload, the
IPSEC protocol which provides encryption.
It can also provide authentication
service and may be used with null encryption (which we do not
recommend). For details see our IPSEC Overview
document and/or RFC 2406.

A situation in which something IP sees as one network is actually
in two or more places.

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
subnets 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.

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.

For information on doing this with Linux FreeS/WAN, look in our
Configuration file.

Federal Information Processing S
tandard, the US government's standards for products it buys. These are
issued by NIST. Among other things,
DES and SHA are defined in FIPS documents. NIST
have a FIPS home page.

The license developed by the Free Software
Foundation under which Linux,
Linux FreeS/WAN 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
COPYING included with GPLed source distributions, including ours,
or the GNU site's GPL
page.

using keyed message digest functions to
authenticate a message. This differs from other uses of these
functions:

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.

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.

The exact techniques used in IPSEC 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.

A system using both public key and
symmetric cipher techniques. This works well. Public key methods
provide key management and digital signature
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.

International Data Encrypion Algorithm,
developed in Europe as an alternative to exportable American ciphers
such as DES which were
too weak for serious use. IDEA is a block cipher
using 64-bit blocks and 128-bit keys, and is used in products such as PGP.

Some cipher modes, including the
CBC 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.

A method of allowing multiple machines to communicate over the
Internet when only one IP address is available for their use. See the
Linux masquerade
resource page for details.

The client machines are set up with reserved
non-routable IP addresses defined in RFC 1918. The masquerading
gateway, the machine with the actual link to the Internet, rewrites
packet headers so that all packets going onto the Internet appear to
come from one IP address, that of its Internet interface. It then gets
all the replies, does some table lookups and more header rewriting,
and delivers the replies to the appropriate client machines.

International Traffic in Arms R
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 Export
Administration Regulations under the Commerce Department's
Bureau of Export Administration.

The basic part of an operating system (e.g. Linux) which controls
the hardware and provides services to all other programs.

In the Linux release numbering system, an even second digit as in 2.
2.x indicates a stable or production kernel while an odd
number as in 2.3.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.

Lightweight Directory Access Protocol,
defined in RFCs 1777 and 1778, a method of accessing information
stored in directories. LDAP is used by several
PKI implementations, often with X.501 directories and
X.509 certificates. It may also be used by IPSEC
to obtain key certifications from those PKIs. This is not yet
implemented in Linux FreeS/WAN.

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
GNU utilities made it a usable system and contributions from many
others led to explosive growth.

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.

Our implementation of the IPSEC protocols,
intended to be freely redistributable source code with
a GNU GPL license and no constraints under US or other
export laws. Linux FreeS/WAN is intended to interoperate with
other IPSEC implementations. The name is partly
taken, with permission, from the S/WAN multi-vendor
IPSEC compatability effort. Linux FreeS/WAN has two major components, KLIPS (KerneL IPSEC Support) and the
Pluto daemon which manages the whole thing.

An active attack in which the attacker
impersonates each of the legitimate players in a protocol to the
other.

For example, if Alice and Bob are
negotiating a key via the Diffie-Hellman key
agreement, and are not using authentication
to be certain they are talking to each other, then an attacker able
to insert himself in the communication path can deceive both players.

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.

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.

To make this attack effective, Mallory must

subvert some part of the network in some way that lets him carry
out the deception
possible targets: DNS, router, Alice or Bob's machine, mail
server, ...

beat any authentication mechanism Alice and Bob use
strong authentication defeats the attack entirely; this is why
IKE requires authentication

work in real time, delivering messages without introducing a delay
large enough to alert the victims
not hard if Alice and Bob are using email; quite difficult in some
situations.

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.

MD5 is one of two message digest algorithms available in IPSEC. The
other is SHA. SHA produces a longer hash and is
therefore more resistant to birthday attacks,
but this is not a concern for IPSEC. The HMAC
method used in IPSEC is secure even if the underlying hash is not
particularly strong against this attack.

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.

Double DES encryption and decryption can be written:

C = E(k2,E(k1,P))
P = D(k1,D(k2,C))

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
112 such pairs and this attack is painfully inefficient.

The meet-in-the middle attack re-writes the equations to calculate
a middle value M:

M = E(k1,P)
M = D(k2,C)

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.

With enough table space, this breaks double DES with 257
work. The memory requirements of such attacks can be prohibitive, but
there is a whole body of research literature on methods of reducing
them.

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
collision resistance. The main applications are in message
authentication and digital signature
schemes. Widely used algorithms include MD5 and
SHA. In IPSEC, message digests are used for HMAC
authentication of packets.

Maximum Transmission U
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.

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 path MTU discovery for details.

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.

An IP address not normally allowed in the "to" or "from" IP address
field header of IP packets.

Almost invariably, the phrase "non-routable address" means one of
the addresses reserved by RFC 1918 for private networks:

10.anything

172.x.anything with 16 <= x <= 31

192.168.anything

These addresses are commonly used on private networks, e.g. behind
a Linux machines doing IP masquerade. 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.

If any packets using these addresses do leak out, they do not go
far. Most routers automatically discard all such packets.

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.

The groups used as the basis of Diffie-Hellman
key exchange in the Oakley protocol, and in IKE.
Four were defined in the original RFC, and a fifth has been
added since.

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 discrete logarithms.

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 nt interecepted the message and only
knows the message length. No such proof exists for any other cipher.

There are, however, several problems with this "perfect" cipher.

It is wildly impractical for many applications. Key management is
difficult or impossible.

It is extremely fragile. Small changes which violate the
conditions listed above do not just weaken the cipher a bit; quite
often they destroy its security completely.

Re-using the pad weakens it to the point where it can be broken
with pencil and paper. With a computer, the attack is trivially easy.

Using computer-generated pseudo-random numbers instead of a really random pad completely invalidates the security
proof. Depending on random number generator used, this may also give
an extremely weak cipher.

If an attacker knows the plaintext and has an intercepted message,
he can discover the pad. This does not matter if the attacker is just
a passive eavesdropper. It gives him no
plaintext he didn't already know and we don't care that he learns a
pad which we'll never re-use. However, knowing the pad lets an
active attacker perform a man-in-the-middle
attack, replacing your message with whatever he chooses.

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 snake
oil. Systems marketed with such claims are usually completely
worthless.

A situation in which any two IPSEC-aware machines can secure their
communications, without a pre-shared secret and without a common
PKI or previous exchange of public keys. This is one of the goals
of the Linux FreeS/WAN project, discussed in our
introduction section.

Setting up for opportunistic encryption is described in our
configuration document.

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 MTU of its outgoing link.

This is done as follows:

originator sends the largest packets allowed by MTU
of the first link, setting the DF (don't f
ragment) bit in the packet header

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 ICMP packet reporting the problem

originator looks at ICMP message and tries a smaller size

eventually, you settle on a size that can pass all routers

thereafter, originator just sends that size and no-one has to
fragment

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:

malformed ICMP messages

hosts that ignore or mishandle these ICMP messages

firewalls blocking the ICMP messages so host does not see them

Since IPSEC adds a header, it increases packet size and may require
fragmentation even where incoming and outgoing MTU are equal.

A property of systems such as Diffie-Hellman 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 provably can

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 man-in-the-middle) which
gives him some short-term keys, but he does not automatically get them
just by acquiring the long-term key.

Pretty Good Privacy, a personal encryption
system for email based on public key technology, written by Phil
Zimmerman.

The 2.xx versions of PGP used the RSA public key
algorithm and used IDEA as the symmetric cipher.
These versions are described in RFC 1991 and in
Garfinkel's book. Since version 5, the products from
PGP Inc. have used Diffie-Hellman public key
methods and CAST-128 symmetric encryption. These
can verify signatures from the 2.xx versions, but cannot exchange
encryted messages with them.

An IETF 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 Gnu Privacy Guard
based on that standard is now available.

For more information on PGP, including how to obtain it, see our
cryptography links.

PKI eXchange, an IETF standard
that allows PKIs to talk to each other.

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:

your organisation and mine each have a PKI in place

you and I are each set up to use those PKIs

the two PKIs speak PKIX

the configuration allows the conversation

At time of writing (March 1999), this is not yet widely implemented
but is under quite active development by several groups.

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 symmetric or
secret key cryptography in which a single key known to both
parties is used for both encryption and decryption.

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 only someone
with the matching private key can decrypt.

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.

See the manual pages for ipsec_ranbits(8) and random(4) for details
of what we use.

There has recently been discussion on several mailing lists of the
limitations of Linux /dev/random and of whether we are using it
correctly. Those discussions are archived on the
/dev/random support page.

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
ICMP error packet to come back to us if not.

Rivest Shamir Adleman public key encryption
method, named for its three inventors. The algorithm is widely used
and likely to become moreso since it became free of patent
encumbrances in September 2000.

For a full explanation of the algorithm, consult one of the
standard references such as Applied
Cryptography. A simple explanation is:

The great 17th century French mathematician
Fermat proved that, for any prime p and number x, 0
x^p == x
modulo p x^(p-1) == 1 modulo p, non-zero x From this it follows
that if we have a pair of primes p, q and two numbers e, d such that:

ed == 1 modulo lcm( p-1, q-1)

where lcm() is least common multiple, then for all x, 0
x^(ed-1) == 1
modulo pq, non-zero x x^ed == x modulo pq So we construct such as
set of numbers p, q, e, d and publish the product N=pq and e as the
public key. Encryption is then:

c = x^e modulo N

An attacker cannot deduce x from the cyphertext c, short of either
factoring N or solving the discrete logarithm
problem for this field. If p, q are large primes (hundreds or
thousands of bits) no efficient solution to either problem is known.

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.

Secure Hash Algorithm, a
message digest algorithm developed by the NSA
for use in the Digital Signature standard, FIPS
number 186 from NIST. SHA is an improved variant
of MD4 producing a 160-bit hash.

SHA is one of two message digest algorithms available in IPSEC. The
other is MD5. Some people do not trust SHA because
it was developed by the NSA. 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.

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
NSA, British GCHQ and Canadian
CSE.

Security Parameter Index, an index used within IPSEC to keep connections distinct. A
Security Association (SA) is defined by destination, protocol and
SPI. Without the SPI, two connections to the same gateway using the
same protocol could not be distinguished.

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.

subnet mask

A method of indicating the addresses included in a subnet. Here are
two equivalent examples:

101.101.101.0/24

101.101.101.0 with mask 255.255.255.0

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.

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.

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.

Secure Wide Area Network, a project involving RSA
Data Security and a number of other companies. The goal was to
ensure that all their IPSEC implementations would
interoperate so that their customers can communicate with each other
securely.

Symmetric cryptography, also referred to as conventional or secret
key cryptography, relies on a shared secret key, 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, block ciphers and
stream ciphers.

Symmetric cryptography contrasts with public key
or asymmetric systems where the two players use different keys.

The great difficulty in symmetric cryptography is, of course, key
management. Sender and receiver must have identical keys and
those keys must 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.

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?

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 secure key exchanges between
users or a central authority that securely distributes 100
key packets, each with a different set of 99 keys.

Either of these is possible, though tricky, for 100 users. Either
becomes an administrative nightmare for larger numbers. Moreover, keys
must 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.

In short, the hardest part of conventional cryptography is key
management. Today the standard solution is to build a
hybrid system using public key techniques to
manage keys.

Deducing useful intelligence from patterns of message traffic,
without breaking codes or reading the messages. In one case during
World War II, the British knew an attack was coming because all German
radio traffic stopped. The "radio silence" order, intended to preserve
security, actually gave the game away.

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.

IPSEC itself does not defend against this, 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.

A variant of triple DES or 3DES in which only
two keys are used. As in the three-key version, the order of
operations is EDE or encrypt-decrypt-encrypt, but
in the two-key variant the first and third keys are the same.

3DES with three keys has 3*56 = 168 bits of key but has only
112-bit strength against a meet-in-the-middle
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.

RFC 2451 defines triple DES for IPSEC as the
three-key variant. The two-key variant should not be used and is not
implemented directly in Linux FreeS/WAN
. 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.

Virtual Private Network, 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.

IPSEC is not the only technique available for
building VPNs, but it is the only method defined by
RFCs 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.