Professional Documents
Culture Documents
Information Security
Information Security
Introduction
Security attacks
Security services
Methods of Defense
Security Mechanism: A mechanism that is designed to detect, prevent, or recover from a security
attack.
Security Service: A service that enhances the security of data processing systems and information
transfers. A security service makes use of one or more security mechanisms.
Security Attacks
Confidentiality (privacy)
Security Goals
X.800 defines it as a service provided by a protocol layer of communicating open systems, which
ensures adequate security of the systems or of data transfers.
RFC 2828 defines it as: a processing or communication service provided by a system to give a
specific kind of protection to system resources.
Ciphertext only
Known plaintext
Chosen plaintext
Chosen plaintext-ciphertext
Can select plaintext and obtain corresponding ciphertext, or select ciphertext and obtain
plaintext.
Unconditional security
No matter how much computer power is available, the cipher cannot be broken
Computational security
Given limited computing resources (eg time needed for calculations is greater than age of
universe), the cipher cannot be broken.
Key Generation
A Stream Cipher is one that encrypts a digital data stream one bit or one byte at a time.
Examples of classical stream ciphers are the auto keyed Vigenere cipher and Verman cipher.
A Block Cipher is one in which a block of plaintext is treated as a whole and used to produce a
ciphertext block of equal length ,typically of 64 or 128 bits is used .
Block size
I - increasing size improves security, but slows cipher
Key size
-increasing size improves security, makes exhaustive key searching harder, but may slow
cipher
Number of rounds
-increasing number improves security, but slows cipher
Subkey generation
-greater complexity can make analysis harder, but slows cipher
Round function
-greater complexity can make analysis harder, but slows cipher
Fast software en/decryption & ease of analysis
-are more recent concerns for practical use and testing.
DES was designed to be implemented only in hardware, and is therefore extremely slow in software.
A recent successful effort to crack DES took several thousand computers several months. The EFF
has sponsored the development of a crypto chip named "Deep Crack" that can process 88 billion
DES keys per second and has successfully cracked 56 bit DES in less than 3 days.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 9
DES is implemented in Kremlin (accessible through Kremlin SDK API).
DES Encryption
Initial Permutation
DES Decryption
-decrypt must unwind steps of data computation
-with Feistel design, do encryption steps again
-using subkeys in reverse order (SK16 … SK1)
-note that IP undoes final FP step of encryption
-1st round with SK16 undoes 16th encrypt round
-………………….….
-16th round with SK1 undoes 1st encrypt round
-then final FP undoes initial encryption IP
-thus recovering original data value
Avalanche Effect
-used when error feedback a problem or where need to encrypt before message is available
-superficially similar to CFB
-but feedback is from the output of cipher and is independent of message
-a variation of a Vernam cipher
-hence must never reuse the same sequence (key+IV)
-sender and receiver must remain in sync, and some recovery method is needed to ensure this
occurs
-originally specified with m-bit feedback in the standards
-subsequent research has shown that only OFB-64 should ever be used with a 64-bit block cipher
-efficiency
-can do parallel encryptions
-in advance of need
-good for bursty high speed links
-random access to encrypted data blocks
-provable security (good as other modes)
-but must ensure never reuse key/counter values, otherwise could break (cf OFB)
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 18
Triple-DES
Why Triple-DES?
AES Requirements
Mix Columns
-each column is processed separately
-each byte is replaced by a value dependent on all 4 bytes in the column
-effectively a matrix multiplication in GF(28) using prime poly m(x) =x8+x4+x3+x+1
RC5 should be a symmetric block cipher. The same secret cryptographic key is used for
encryption and for decryption. The plaintext and cipher text are fixed-length bit sequences (blocks).
RC5 should be suitable for hardware or software. This means that RC5 should use only
computational primitive operations commonly found on typical microprocessors.
RC5 should be fast. This more-or-less implies that RC5 be word-oriented: the basic computational
operations should be operators that work on full words of data at a time.
RC5 should be iterative in structure, with a variable number of rounds. The user can explicitly
manipulate the trade-off between higher speed and higher security. The number of rounds r is a
second parameter of RC5.
RC5 should have a variable-length cryptographic key. The user can choose the level of security
appropriate for his application, or as required by external considerations such as export restrictions.
The key length b (in bytes) is thus a third parameter of RC5.
RC5 should be simple. It should be easy to implement. More importantly, a simpler structure is
perhaps more interesting to analyze and evaluate, so that the cryptographic strength of RC5 can be
more rapidly determined.
RC5 should have a low memory requirement, so that it may be easily implemented on smart cards
or other devices with restricted memory
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 24
RC5 should provide high security when suitable parameter values are chosen.
RC5 should provide data-dependent rotations, RC5 incorporates rotations (circular bits shifts )
whose amount is data dependent . This appears to strengthen the algorithm against cryptanalysis.
RC5 Parameters
Configurable parameters
word length w
number of rounds r
key size (bytes) b
Denoted as RC5-w/r/b
Key Expansion
Data Encryption
In this section we discuss in somewhat greater detail the parameters of RC5, and the tradeoffs
involved in choosing various parameters.
As noted above, RC5 is word-oriented: all of the basic computational operations have w-bit words as
inputs and outputs. RC5 is a block-cipher with a two-word input (plaintext) block size and a two-
word (ciphertext) output block size. The nominal choice for w is 32 bits, for which RC5 has 64-bit
plaintext and ciphertext block sizes. RC5 is well-defined for any w > 0, although for simplicity it is
proposed here that only the values 16, 32, and 64 be "allowable."
The number r of rounds is the second parameter of RC5. Choosing a larger number of rounds
presumably provides an increased level of security. We note here that RC5 uses an "expanded key
table," S, that is derived from the user's supplied secret key. The size t of table S also depends on the
number r of rounds: S has t = 2(r +1) words. Choosing a larger number of rounds therefore also
implies a need for somewhat more memory.
Encryption
We assume that the input block is given in two w-bit registers A and B. We also assume that key-
expansion has already been performed, so that the array 5[0..i-1] has been computed. Here is the
encryption algorithm in pseudo-code:
A = A + S[0]; B = B + S[1]; for i = 1 to r do
A = {{A®B) <<< B) + S[2 * i];
The output is in the registers A and B.
We note the exceptional simplicity of this 5-line algorithm.
We also note that each RC5 round updates both registers A and B, whereas a "round" in DES
updates only half of its registers. An RC5 "half-round" (one of the assignment statements updating A
or B in the body of the loop above) is thus perhaps more analogous to a DES round.
Decryption
The decryption routine is easily derived from the encryption routine.
for i = r downto 1 do
B = ((B - S[2 * i + 1]) ^ A) © A; A = ((A - S[2 * i]) ^> B)®B-
A = A-S[0};
Blowfish, a new secret-key block cipher, is proposed. It is a Feistel network, iterating a simple
encryption function 16 times. The block size is 64 bits, and the key can be any length up to 448 bits.
Although there is a complex initialization phase required before any encryption can take place, the
actual encryption of data is very efficient on large
Characteristics of Blowfish
Speed: Encrypts data on 32-bit microprocessors at the rate of 18 clock cycles per byte.
Compactness: Can run in less than 5k of memory.
Simplicity: Easy to implement.
Variability: Flexible key size as long as 448 bits to enhance security.
Blowfish is a variable-length key block cipher. it is only suitable for applications where the key does
not change often, like a communications link or an automatic file encrypt or. It is significantly faster
than DES when implemented on 32-bit microprocessors with large data caches, such as the Pentium
and the PowerPC.
Blowfish is a variable-length key, 64-bit block cipher. The algorithm consists of two parts: a key-
expansion part and a data- encryption part. Key expansion converts a key of at most 448 bits into
several sub key arrays totaling 4168 bytes.
Data encryption occurs via a 16-round Feistel network. Each round consists of a key-dependent
permutation, and a key- and data-dependent substitution. All operations are XORs and additions on
32-bit words. The only additional operations are four indexed array data lookups per round
Sub keys:
Blowfish uses a large number of sub keys. These keys must be precomputed before any data
encryption or decryption.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 28
1. The P-array consists of 18 32-bit sub keys:
P1, P2, P3, P4……………………………………… P18.
Encryption:
For i = 1 to 16:
xL = xL XOR Pi
xR = F(xL) XOR xR
Swap xL and xR
Next i
Swap xL and xR (Undo the last swap.)
xR = xR XOR P17
xL = xL XOR P18
Recombine xL and xR
Function F (see Figure 2):
Divide xL into four eight-bit quarters: a, b, c, and d
F(xL) = ((S1,a + S2,b mod 232) XOR S3,c) + S4,d mod 232
Decryption is exactly the same as encryption, except that P1, P2,..., P18 are used in the reverse
order.
Implementations of Blowfish that require the fastest speeds should unroll the loop and ensure that all
sub keys are stored in cache.
The sub keys are calculated using the Blowfish algorithm. The exact method is as follows:
1. Initialize first the P-array and then the four S-boxes, in order, with a fixed string. This string
consists of the hexadecimal digits of pi (less the initial 3). For example:
P1 = 0x243f6a88
P2 = 0x85a308d3
P3 = 0x13198a2e
P4 = 0x03707344
P15=P15 XOR K1………P18= P18 XOR K4.Repeatedly cycle through the key bits until the entire
P-array has been XORed with key bits. (For every short key, there is at least one equivalent longer
key)
3. Encrypt the all-zero string with the Blowfish algorithm, using the sub keys described in steps (1)
and (2).
5. Encrypt the output of step (3) using the Blowfish algorithm with the modified subkeys.
7. Continue the process, replacing all entries of the P- array, and then all four S-boxes in order, with
the output of the continuously-changing Blowfish algorithm.
In total, 521 iterations are required to generate all required subkeys. Applications can store the
subkeys rather than execute this derivation process multiple times.
The underlying philosophy behind Blowfish is that simplicity of design yields an algorithm that is
both easier to understand and easier to implement. Through the use of a streamlined Feistel network-
-a simple S-box substitution and a simple P-box substitution--I hope that the design will not contain
any flaws.
A 64-bit block size yields a 32-bit word size, and maintains block-size compatibility with existing
algorithms. Blowfish is easy to scale up to a 128-bit block, and down to smaller block sizes.
Cryptanalysis of the mini-Blowfish variants may be significantly easier than cryptanalysis of the full
version.
The fundamental operations were chosen with speed in mind. XOR, ADD, and MOV from a cache
are efficient on both Intel and Motorola architectures. All subkeys fit in the cache of a 80486, 68040,
Pentium, and PowerPC.
The Feistel network that makes up the body of Blowfish is designed to be as simple as possible,
while still retaining the desirable cryptographic properties of the structure. Figure 3 is round i of a
general Feistel network: Rn,i are reversible functions of text and key, and Ni is a non-reversible
function of text and key. For speed and simplicity, I chose XOR as my reversible function. This let
me collapse the four XORs into a single XOR, since: R--1,i+1 = R1,i+1 XOR R2,i-1 XOR
R3,i XOR R4,i
This is the P-array substitution in Blowfish. The XOR can also be considered to be part of the non-
reversible function, Ni, occurring at the end of the function. (Although equivalent, I chose not to
illustrate them in this way because it simplifies description of the subkey-generation process.) There
are two XORs that remain after this reduction: R1 in the first round and R2 in the last round. I chose
not to eliminate these in order to hide the input to the first non-reversible function.
I considered a more complicated reversible function, one with modular multiplications and rotations.
However, these operations would greatly increase the algorithm's execution time. Since function F is
the primary source of the algorithm's security, I decided to save time-consuming complications for
that function.
Function F, the non-reversible function, gives Blowfish the best possible avalanche effect for a
Feistel network: every text bit on the left half of the round affects every text bit on the right half.
Additionally, since every subkey bit is affected by every key bit, the function also has a perfect
avalanche effect between the key and the right half of the text after every round. Hence, the
algorithm exhibits a perfect avalanche effect after three rounds and again every two rounds after that.
I considered adding a reversible mixing function, more complicated than XOR, before the first and
after the last round. This would further confuse the entry values into the Feistel network and ensure a
complete avalanche effect after the first two rounds. I eventually discarded the addition as a time-
consuming complication with no clear cryptographic benefits.
The non-reversible function is designed for strength, speed, and simplicity. Ideally, I wanted a single
S-box with 232 32-bit words, but that was impractical. My eventual choice of 256-entry S-boxes was
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 32
a compromise between my three design goals. The small-number of bits to large-number of bits may
have weaknesses with respect to linear cryptanalysis, but these weaknesses are hidden both by
combining the output of four S-boxes and making them dependent on the key.
I used four different S-boxes instead of one S-box primarily to avoid symmetries when different
bytes of the input are equal, or when the 32-bit input to function F is a bytewise permutation of
another 32-bit input. I could have used one S-box and made each of the four different outputs a non-
trivial permutation of the single output, but the four S-box design is faster, easier to program, and
seems more secure.
The function that combines the four S-box outputs is as fast as possible. A simpler function would be
to XOR the four values, but mixing addition mod 232 and XOR combines two different algebraic
groups with no additional instructions. The alternation of addition and XOR ends with an addition
operation because an XOR combines the final result with xR.
If the four indexes chose values out of the same S-box, a more complex combining function would
be required to eliminate symmetries. I considered using a more complex combining function in
Blowfish (using modular multiplications, rotations, etc.), but chose not to because the added
complication seemed unnecessary.
The key-dependent S-boxes protect against differential and linear cryptanalysis. Since the structure
of the S-boxes is completely hidden from the cryptanalyst, these attacks have a more difficult time
exploiting that structure. While it would be possible to replace these variable S-boxes with four fixed
S-boxes that were designed to be resistant to these attacks, key-dependent S-boxes are easier to
implement and less susceptible to arguments of "hidden" properties. Additionally, these S-boxes can
be created on demand, reducing the need for large data structures stored with the algorithm.
Each bit of xL is only used as the input to one S-box. In DES many bits are used as inputs to two S-
boxes, which strengthens the algorithm considerably against differential attacks. I feel that this
added complication is not as necessary with key- dependent S-boxes. Additionally, larger S-boxes
would take up considerably more memory space.
Function F does not depend on the iteration. I considered adding this dependency, but did not feel
that it had any cryptographic merit. The P-array substitution can be considered to be part of this
function, and that is already iteration-dependent.
The number of rounds is set at 16 primarily out of desire to be conservative. However, this number
affects the size of the P- array and therefore the subkey-generation process; 16 iterations permits key
lengths up to 448 bits. I expect to be able to reduce this number, and greatly speed up the algorithm
in the process, as I accumulate more cryptanalysis data.
In algorithm design, there are two basic ways to ensure that the key is long enough to ensure a
particular security level. One is to carefully design the algorithm so that the entire entropy of the key
is preserved, so there is no better way to cryptanalyze the algorithm other than brute force. The other
is to design the algorithm with so many key bits that attacks that reduce the effective key length by
several bits are irrelevant. Since Blowfish is designed for large microprocessors with large amounts
of memory, I chose the latter.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 33
The subkey generation process is designed to preserve the entire entropy of the key and to distribute
that entropy uniformly throughout the subkeys. It is also designed to distribute the set of allowed
subkeys randomly throughout the domain of possible subkeys. I chose the digits of pi as the initial
subkey table for two reasons: because it is a random sequence not related to the algorithm, and
because it could either be stored as part of the algorithm or derived when needed. There is nothing
sacred about pi; any string of random bits--digits of e, RAND tables, output of a random number
generator--will suffice. However, if the initial string is non-random in any way (for example, ASCII
text with the high bit of every byte a 0), this non-randomness will propagate throughout the
algorithm.
In the subkey generation process, the subkeys change slightly with every pair of subkeys generated.
This is primarily to protect against any attacked of the subkey generation process that exploit the
fixed and known subkeys. It also reduces storage requirements. The 448 limit on the key size ensures
that the every bit of every subkey depends on every bit of the key. (Note that every bit of P15, P16,
P17, and P18 does not affect every bit of the ciphertext, and that any S-box entry only has a .06
probability of affecting any single ciphertext block.)
The key bits are repeatedly XORed with the digits of pi in the initial P-array to prevent the following
potential attack: Assume that the key bits are not repeated, but instead padded with zeros to extend it
to the length of the P-array. An attacker might find two keys that differ only in the 64-bit value
XORed with P1 and P2 that, using the initial known subkeys, produce the same encrypted value. If
so, he can find two keys that produce all the same subkeys. This is a highly tempting attack for a
malicious key generator.
To prevent this same type of attack, I fixed the initial plaintext value in the subkey-generation
process. There is nothing special about the all-zeros string, but it is important that this value be fixed.
The subkey-generation algorithm does not assume that the key bits are random. Even highly
correlated key bits, such as an alphanumeric ASCII string with the bit of every byte set to 0, will
produce random subkeys. However, to produce subkeys with the same entropy, a longer
alphanumeric key is required.
from 1024 bytes to 259 bytes. Additional steps may be required to eliminate the symmetries that
these simplifications would introduce. Additionally, four different 10- or 12-bit indexes into a single
large S-box could be used instead of the current series of S-boxes.
Fewer iterations. It is probably safe to reduce the number of iterations from 16 to 8 without
compromising security. The number of iterations required for security may be dependent on the
length of the key. Note that with the current subkey generation procedure, an 8-iteration algorithm
cannot accept a key longer than 192 bits.
Possible Simplifications
Fewer and smaller S-boxes. It may be possible to reduce the number of S-boxes from four to one.
Additionally, it may be possible to overlap entries in a single S-box: entry 0 would consist of bytes 0
through 3, entry 1 would consist of bytes 1 through 4, etc. The former simplification would reduce
the memory requirements for the four S-boxes from 4096 bytes to 1024 bytes, the latter would
reduce the requirements for a single S-box from 1024 bytes to 259 bytes. Additional steps may be
required to eliminate the symmetries that these simplifications would introduce. Additionally, four
different 10- or 12-bit indexes into a single large S-box could be used instead of the current series of
S-boxes.
Fewer iterations. It is probably safe to reduce the number of iterations from 16 to 8 without
compromising security. The number of iterations required for security may be dependent on the
length of the key. Note that with the current subkey generation procedure, an 8-iteration algorithm
cannot accept a key longer than 192 bits.
On-the-fly subkey calculation. The current method of subkey calculation requires all subkeys to be
calculated advance of any data encryption. In fact, it is impossible to calculate the last subkey of the
last S-box without calculating every subkey that comes before. An alternate method of subkey
calculation would be preferable: one where every subkey can be calculated independently of any
other. High-end implementations could still precompute the subkeys for increased speed, but low-
end applications could only compute the required subkeys when needed.
Introduction
RC2 is a 64-bit block cipher with keys of variable lengths. It is designed by Ron Rivest for RSA Data
Security, Inc., and is used widely, most notably in the S/MIME secure messaging standard. In 1997 RC2
was published as an Internet Draft. The model for cryptanalysis in this report is the standard one for
block ciphers, where it is assumed that the attacker has access to a black-box which encrypts any
chosen input or decrypts any chosen output using RC2 with a secret, randomly chosen key.
Structural features and characteristics
RC2 works on 64-bit blocks which are divided into four words of each sixteen bits. It is an iterated
block cipher where the ciphertext is computed as a function of the plaintext and the secret key in a
number of rounds. There are two kinds of rounds in RC2, the mixing rounds and the mashing
rounds. There are in total 16 mixing rounds and two mashing rounds. In each round each of the four
sixteen-bit words in an intermediate ciphertexts is updated as a function of the other words. Each of
the mixing rounds takes a 16-bit subkey. The 64 subkeys are derived from the user-selected key which
can be of length from one to 128 bytes. An additional parameter of the algorithm is the effective key
length, which will be explained below.
We note that the decryption operation does not equal the encryption operation which may have
unfortunate impacts on implementations.
Also, RC2 is not a fast cipher and an optimized version of DES and any of the five AES finalists is
likely to produce higher throughputs than RC2.
Key Expansion
The key-schedule takes a user-selected key and a number representing the maximum effective key
length. The latter is a feature not seen in any other block ciphers as far as this author is informed.
Assume that the user-selected key consists of T bytes where 1 < T < 128. Let L be a key buffer (an
array) of 128 bytes. The T bytes are loaded into L[0], ..., L[T — 1] of the key buffer. The maximum
effective key length in bits is denoted Tl
The key expansion consists of the following two iterations, where II is a table consisting of a
permutation of the numbers 0,..., 127 derived from the expansion of TT:
1. for i = T,T + 1,..., 127 do
L[i] = U[L[i - 1] + L[i - T]], where addition is modulo 256
2. L[128 - T8] =n[L[128-T8] &.TM]
3. for i = 127-T8, ...,0 do
L[i] = U[L[i + 1] 0 L[i + T8}}
Finally, define the 64 subkeys, K[i] for i = 0,..., 63 as follows: K[i] = L[2i] + 256 x L[2i+1].
The terms T8 and TM ensure that the expanded key table is derived from only Tl bits, such that an
exhaustive search can be performed in 2T1 operations independent of the length of the user-selected
key.
Encryption and Decryption
The two kinds of rounds in RC2 are defined via the operations MIX and MASH . The plaintext is divided
into four words of each sixteen bits denoted R[0],..., R[3].
The MIX operation is defined as follows, where s[0] = 1, s[l] = 2, s[2] = 3, and S[3] = 5.
Here j is the global variable; K[j] is the first subkey word that has not yet been used
A mashing round consists of four MASH operations such that each of the words
R[0],R[l],R[2], and R[3] are modified.
1. Let the words R[0], ..., R[3] hold the 64-bit plaintext block.
2. Perform the key expansion such that the words K[0],...,K [63] hold the sub-keys.
3. Initialize j to zero.
4. Do five mixing rounds.
5. Do one mashing round.
6. Do six mixing rounds.
7. Do one mashing round.
8. Do five mixing rounds.
9. The ciphertext is defined as the resulting values of R[0], ...,R[3].
Decryption is the reverse of encryption. Clearly, it suffices to define the inverse operations of the
MIX and MASH operations.
Introduction
Description of Algorithm
CAST-128 belongs to the class of encryption algorithms known as Feistel ciphers; overall
operation is thus similar to the Data Encryption Standard (DES). The full encryption algorithm
is given in the following four steps.
4. c1...c64 <-- (R16,L16). (Exchange final blocks L16, R16 and concatenate to form the
ciphertext.)
CAST-128 uses a pair of subkeys per round: a 32-bit quantity Km is used as a "masking"
key and a 5-bit quantity Kr is used as a "rotation" key.
I I I I I
Non-Identical Rounds
Three different round functions are used in CAST-128. The rounds are as follows (where "D"
is the data input to the f function and "Ia" - "Id" are the most significant byte through least
significant byte of I, respectively). Note that "+" and "-" are addition and subtraction
modulo 2**32, "^" is bitwise XOR, and "<<<" is the circular left- shift operation.
Substitution Boxes
CAST-128 uses eight substitution boxes: s-boxes S1, S2, S3, and S4 are round function s-
boxes; S5, S6, S7, and S8 are key schedule s- boxes. Although 8 s-boxes require a total of 8
KBytes of storage, note that only 4 KBytes are required during actual encryption / decryption
since subkey generation is typically done prior to any data input.
Key Schedule
Let Km1, ..., Km16 be 32-bit masking subkeys (one per round).
Let Kr1, , Kr16 be 32-bit rotate subkeys (one per round); only the least significant 5 bits are
used in each round.
Variable Keysize
The CAST-128 encryption algorithm has been designed to allow a key size that can vary from
40 bits to 128 bits, in 8-bit increments (that is, the allowable key sizes are 40, 48, 56, 64, ...,
112, 120, and 128 bits. For variable keysize operation, the specification is as follows:
1) For key sizes up to and including 80 bits (i.e., 40, 48, 56, 64, 72, and 80 bits), the
algorithm is exactly as specified but uses12 rounds instead of 16;
2) For key sizes greater than 80 bits, the algorithm uses the full 16 rounds
3) For key sizes less than 128 bits, the key is padded with zero bytes (in the rightmost, or
least significant, positions) out to 128 bits (since the CAST-128 key schedule assumes an input
key of 128 bits). Note that although CAST-128 can support all 12 key sizes listed above, 40
bits, 64 bits, 80 bits, and 128 bits are the sizes that find utility in typical environments.
Therefore, it will likely be sufficient for most implementations to support some subset of only
these four sizes.
In order to avoid confusion when variable keysize operation is used, the name CAST-128 is
to be considered synonymous with the name CAST5; this allows a keysize to be appended
without ambiguity. Thus, for example, CAST-128 with a 40-bit key is to be referred to as
CAST5-40; where a 128-bit key is explicitly intended, the name CAST5-128 should be used.
Discussion
CAST-128 is a 12- or 16-round Feistel cipher that has a blocksize of 64 bits and a keysize of
up to 128 bits; it uses rotation to provide intrinsic immunity to linear and differential attacks; it
uses a mixture of XOR, addition and subtraction (modulo 2**32) in the round function; and it
uses three variations of the round function itself throughout the cipher. Finally, the 8x32 s-
boxes used in the round function each have a minimum nonlinearity of 74 and a maximum
entry of 2 in the difference distribution table.
This cipher appears to have cryptographic strength in accordance with its keysize (128 bits)
and has very good encryption / decryption performance: 3.3 MBytes/sec on a 150 MHz
Pentium processor.
IDEA, developed in Zurich, Switzerland by Xuejia Lai and James Massey, is generally
regarded to be one of the best and most secure block algorithm available to the public
today. It utilizes a 128-bit key and is designed to be resistant to differential
cryptanalysis. Some attacks have been made against reduced round IDEA.
Unfortunately, IDEA is patented; licensing information can be obtained from Ascom.
Used in PGP
128-bit key, 64-bit block
Variant Feistel network (not Feistel)
Eight rounds + final transformation
Successor to DES, 128-bit key, 3 times faster than DES
Uses three operations. Each operation is performed on two 16-bit inputs to produce a single
16-bit output
–Bit-by-bit XOR ( Å )
–(Unsigned 16-bit integers) addition modulo 216 ( )
–(Unsigned 16-bit integers) multiplication modulo 216 + 1 (except that a block of all zeros is
treated as representing 216 ( )
Three operations are incompatible in the sense that
–No pair of the three operations satisfies a distributive law. e.g.,
a (b c) ¹ (a b) (a c)
–No pair of the three operations satisfies an associative law. e.g.,
a (b Å c) ¹ (a b) Å c
In IDEA, confusion is achieved by using these three separate operations in combination
–Provides a complex transformation of the input, making cryptanalysis much more difficult
(than with a DES which uses just a single XOR)
The DES (Data Encryption Standard) algorithm is the most widely used encryption algorithm in the
world. For many years, and among many people, "secret code making" and DES have been
synonymous. And despite the recent coup by the Electronic Frontier Foundation in creating a
$220,000 machine to crack DES-encrypted messages, DES will live on in government and banking
for years to come through a life- extending version called "triple-DES."
How does DES work? This explains the various steps involved in DES-encryption, illustrating each
step by means of a simple example. Since the creation of DES, many other algorithms (recipes for
changing data) have emerged which are based on design principles similar to DES. Once you
understand the basic transformations that take place in DES, you will find it easy to follow the steps
involved in these more recent algorithms.
But first a bit of history of how DES came about is appropriate, as well as a look toward the future.
The National Bureau of Standards Coaxes the Genie from the Bottle
On May 15, 1973, during the reign of Richard Nixon, the National Bureau of Standards (NBS)
published a notice in the Federal Register soliciting proposals for cryptographic algorithms to protect
data during transmission and storage. The notice explained why encryption was an important issue.
Over the last decade, there has been an accelerating increase in the accumulations and
communication of digital data by government, industry and by other organizations in the private
sector. The contents of these communicated and stored data often have very significant value and/or
sensitivity. It is now common to find data transmissions which constitute funds transfers of several
million dollars, purchase or sale of securities, warrants for arrests or arrest and conviction records
being communicated between law enforcement agencies, airline reservations and ticketing
representing investment and value both to the airline and passengers, and health and patient care
records transmitted among physicians and treatment centers.
The increasing volume, value and confidentiality of these records regularly transmitted and stored by
commercial and government agencies has led to heightened recognition and concern over their
exposures to unauthorized access and use. This misuse can be in the form of theft or defalcations of
data records representing money, malicious modification of business inventories or the interception
and misuse of confidential information about people. The need for protection is then apparent and
urgent.
NBS waited for the responses to come in. It received none until August 6, 1974, three days before
Nixon's resignation, when IBM submitted a candidate that it had developed internally under the
name LUCIFER. After evaluating the algorithm with the help of the National Security Agency
(NSA), the NBS adopted a modification of the LUCIFER algorithm as the new Data Encryption
Standard (DES) on July 15, 1977.
DES was quickly adopted for non-digital media, such as voice-grade public telephone lines. Within a
couple of years, for example, International Flavors and Fragrances was using DES to protect its
valuable formulas transmitted over the phone ("With Data Encryption, Scents Are Safe at IFF,"
Computerworld 14, No. 21, 95 (1980).)
Meanwhile, the banking industry, which is the largest user of encryption outside government,
adopted DES as a wholesale banking standard. Standards for the wholesale banking industry are set
by the American National Standards Institute (ANSI). ANSI X3.92, adopted in 1980, specified the
use of the DES algorithm.
DES works on bits, or binary numbers--the 0s and 1s common to digital computers. Each group of
four bits makes up a hexadecimal, or base 16, number. Binary "0001" is equal to the hexadecimal
number "1", binary "1000" is equal to the hexadecimal number "8", "1001" is equal to the
hexadecimal number "9", "1010" is equal to the hexadecimal number "A", and "1111" is equal to the
hexadecimal number "F".
DES works by encrypting groups of 64 message bits, which is the same as 16 hexadecimal numbers.
To do the encryption, DES uses "keys" where are also apparently 16 hexadecimal numbers long, or
apparently 64 bits long. However, every 8th key bit is ignored in the DES algorithm, so that the
effective key size is 56 bits. But, in any case, 64 bits (16 hexadecimal digits) is the round number
upon which DES is organized.
For example, if we take the plaintext message "8787878787878787", and encrypt it with the DES
key "0E329232EA6D0D73", we end up with the ciphertext "0000000000000000". If the ciphertext
is decrypted with the same secret DES key "0E329232EA6D0D73", the result is the original
plaintext "8787878787878787".
This example is neat and orderly because our plaintext was exactly 64 bits long. The same would be
true if the plaintext happened to be a multiple of 64 bits. But most messages will not fall into this
category. They will not be an exact multiple of 64 bits (that is, an exact multiple of 16 hexadecimal
numbers).
The plaintext message "Your lips are smoother than vaseline" is, in hexadecimal,
(Note here that the first 72 hexadecimal digits represent the English message, while "0D" is
hexadecimal for Carriage Return, and "0A" is hexadecimal for Line Feed, showing that the message
file has terminated.) We then pad this message with some 0s on the end, to get a total of 80
hexadecimal digits:
If we then encrypt this plaintext message 64 bits (16 hexadecimal digits) at a time, using the same
DES key "0E329232EA6D0D73" as before, we get the ciphertext:
This is the secret code that can be transmitted or stored. Decrypting the ciphertext restores the
original message "Your lips are smoother than vaseline". (Think how much better off Bill Clinton
would be today, if Monica Lewinsky had used encryption on her Pentagon computer!)
DES is a block cipher--meaning it operates on plaintext blocks of a given size (64-bits) and returns
ciphertext blocks of the same size. Thus DES results in a permutation among the 2^64 (read this as:
"2 to the 64th power") possible arrangements of 64 bits, each of which may be either 0 or 1. Each
block of 64 bits is divided into two blocks of 32 bits each, a left half block L and a right half R. (This
division is only used in certain operations.)
M = 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
L = 0000 0001 0010 0011 0100 0101 0110 0111
R = 1000 1001 1010 1011 1100 1101 1110 1111
The first bit of M is "0". The last bit is "1". We read from left to right.
Example: Let K be the hexadecimal key K = 133457799BBCDFF1. This gives us as the binary key
(setting 1 = 0001, 3 = 0011, etc., and grouping together every eight bits, of which the last one in each
group will be unused):
The 64-bit key is permuted according to the following table, PC-1. Since the first entry in the table is
"57", this means that the 57th bit of the original key K becomes the first bit of the permuted key K+.
The 49th bit of the original key becomes the second bit of the permuted key. The 4th bit of the
original key is the last bit of the permuted key. Note only 56 bits of the original key appear in the
permuted key.
PC-1
57 49 41 33 25 17 9
1 58 50 42 34 26 18
10 2 59 51 43 35 27
19 11 3 60 52 44 36
63 55 47 39 31 23 15
7 62 54 46 38 30 22
14 6 61 53 45 37 29
21 13 5 28 20 12 4
Next, split this key into left and right halves, C0 and D0, where each half has 28 bits.
With C0 and D0 defined, we now create sixteen blocks Cn and Dn, 1<=n<=16. Each pair of blocks
Cn and Dn is formed from the previous pair Cn-1 and Dn-1, respectively, for n = 1, 2, ..., 16, using
the following schedule of "left shifts" of the previous block. To do a left shift, move each bit one
place to the left, except for the first bit, which is cycled to the end of the block.
Iteration Number of
Number Left Shifts
1 1
2 1
3 2
4 2
5 2
6 2
7 2
8 2
9 1
10 2
11 2
12 2
13 2
14 2
15 2
16 1
This means, for example, C3 and D3 are obtained from C2 and D2, respectively, by two left shifts,
and C16 and D16 are obtained from C15 and D15, respectively, by one left shift. In all cases, by a
single left shift is meant a rotation of the bits one place to the left, so that after one left shift the bits
in the 28 positions are the bits that were previously in positions 2, 3,..., 28, 1.
C0 = 1111000011001100101010101111
D0 = 0101010101100110011110001111
C1 = 1110000110011001010101011111
D1 = 1010101011001100111100011110
C2 = 1100001100110010101010111111
D2 = 0101010110011001111000111101
C3 = 0000110011001010101011111111
D3 = 0101011001100111100011110101
C5 = 1100110010101010111111110000
D5 = 0110011001111000111101010101
C6 = 0011001010101011111111000011
D6 = 1001100111100011110101010101
C7 = 1100101010101111111100001100
D7 = 0110011110001111010101010110
C8 = 0010101010111111110000110011
D8 = 1001111000111101010101011001
C9 = 0101010101111111100001100110
D9 = 0011110001111010101010110011
C10 = 0101010111111110000110011001
D10 = 1111000111101010101011001100
C11 = 0101011111111000011001100101
D11 = 1100011110101010101100110011
C12 = 0101111111100001100110010101
D12 = 0001111010101010110011001111
C13 = 0111111110000110011001010101
D13 = 0111101010101011001100111100
C14 = 1111111000011001100101010101
D14 = 1110101010101100110011110001
C15 = 1111100001100110010101010111
D15 = 1010101010110011001111000111
C16 = 1111000011001100101010101111
D16 = 0101010101100110011110001111
We now form the keys Kn, for 1<=n<=16, by applying the following permutation table to each of
the concatenated pairs CnDn. Each pair has 56 bits, but PC-2 only uses 48 of these.
PC-2
14 17 11 24 1 5
3 28 15 6 21 10
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 51
23 19 12 4 26 8
16 7 27 20 13 2
41 52 31 37 47 55
30 40 51 45 33 48
44 49 39 56 34 53
46 42 50 36 29 32
Therefore, the first bit of Kn is the 14th bit of CnDn, the second bit the 17th, and so on, ending with
the 48th bit of Kn being the 32th bit of CnDn.
Example: For the first key we have C1D1 = 1110000 1100110 0101010 1011111 1010101 0110011
0011110 0011110
There is an initial permutation IP of the 64 bits of the message data M. This rearranges the bits
according to the following table, where the entries in the table show the new arrangement of the bits
from their initial order. The 58th bit of M becomes the first bit of IP. The 50th bit of M becomes the
second bit of IP. The 7th bit of M is the last bit of IP.
58 50 42 34 26 18 10 2
60 52 44 36 28 20 12 4
62 54 46 38 30 22 14 6
64 56 48 40 32 24 16 8
57 49 41 33 25 17 9 1
59 51 43 35 27 19 11 3
61 53 45 37 29 21 13 5
63 55 47 39 31 23 15 7
Example: Applying the initial permutation to the block of text M, given previously, we get
M = 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
IP = 1100 1100 0000 0000 1100 1100 1111 1111 1111 0000 1010 1010 1111 0000 1010 1010
Here the 58th bit of M is "1", which becomes the first bit of IP. The 50th bit of M is "1", which
becomes the second bit of IP. The 7th bit of M is "0", which becomes the last bit of IP.
Next divide the permuted block IP into a left half L0 of 32 bits, and a right half R0 of 32 bits.
We now proceed through 16 iterations, for 1<=n<=16, using a function f which operates on two
blocks--a data block of 32 bits and a key Kn of 48 bits--to produce a block of 32 bits. Let + denote
XOR addition, (bit-by-bit addition modulo 2). Then for n going from 1 to 16 we calculate
Ln = Rn-1
Rn = Ln-1 + f(Rn-1,Kn)
This results in a final block, for n = 16, of L16R16. That is, in each iteration, we take the right 32
bits of the previous result and make them the left 32 bits of the current step. For the right 32 bits in
the current step, we XOR the left 32 bits of the previous step with the calculation f .
It remains to explain how the function f works. To calculate f, we first expand each block Rn-1 from
32 bits to 48 bits. This is done by using a selection table that repeats some of the bits in Rn-1 . We'll
Let E be such that the 48 bits of its output, written as 8 blocks of 6 bits each, are obtained by
selecting the bits in its inputs in order according to the following table:
E BIT-SELECTION TABLE
32 1 2 3 4 5
4 5 6 7 8 9
8 9 10 11 12 13
12 13 14 15 16 17
16 17 18 19 20 21
20 21 22 23 24 25
24 25 26 27 28 29
28 29 30 31 32 1
Thus the first three bits of E(Rn-1) are the bits in positions 32, 1 and 2 of Rn-1 while the last 2 bits
of E(Rn-1) are the bits in positions 32 and 1.
(Note that each block of 4 original bits has been expanded to a block of 6 output bits.)
Next in the f calculation, we XOR the output E(Rn-1) with the key Kn:
Kn + E(Rn-1).
We have not yet finished calculating the function f . To this point we have expanded Rn-1 from 32
bits to 48 bits, using the selection table, and XORed the result with the key Kn . We now have 48
bits, or eight groups of six bits. We now do something strange with each group of six bits: we use
them as addresses in tables called "S boxes". Each group of six bits will give us an address in a
different S box. Located at that address will be a 4 bit number. This 4 bit number will replace the
original 6 bits. The net result is that the eight groups of 6 bits are transformed into eight groups of 4
bits (the 4-bit outputs from the S boxes) for 32 bits total.
S1(B1)S2(B2)S3(B3)S4(B4)S5(B5)S6(B6)S7(B7)S8(B8)
To repeat, each of the functions S1, S2,..., S8, takes a 6-bit block as input and yields a 4-bit block as
output. The table to determine S1 is shown and explained below:
S1
Column Number
Row
No. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
1 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
2 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
3 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
If S1 is the function defined in this table and B is a block of 6 bits, then S1(B) is determined as
follows: The first and last bits of B represent in base 2 a number in the decimal range 0 to 3 (or
binary 00 to 11). Let that number be i. The middle 4 bits of B represent in base 2 a number in the
decimal range 0 to 15 (binary 0000 to 1111). Let that number be j. Look up in the table the number
in the i-th row and j-th column. It is a number in the range 0 to 15 and is uniquely represented by a 4
bit block. That block is the output S1(B) of S1 for the input B. For example, for input block B =
011011 the first bit is "0" and the last bit "1" giving 01 as the row. This is row 1. The middle four
bits are "1101". This is the binary equivalent of decimal 13, so the column is column number 13. In
row 1, column 13 appears 5. This determines the output; 5 is binary 0101, so that the output is 0101.
Hence S1(011011) = 0101.
S1
14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
S2
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 55
15 1 8 14 6 11 3 4 9 7 2 13 12 0 5 10
3 13 4 7 15 2 8 14 12 0 1 10 6 9 11 5
0 14 7 11 10 4 13 1 5 8 12 6 9 3 2 15
13 8 10 1 3 15 4 2 11 6 7 12 0 5 14 9
S3
10 0 9 14 6 3 15 5 1 13 12 7 11 4 2 8
13 7 0 9 3 4 6 10 2 8 5 14 12 11 15 1
13 6 4 9 8 15 3 0 11 1 2 12 5 10 14 7
1 10 13 0 6 9 8 7 4 15 14 3 11 5 2 12
S4
7 13 14 3 0 6 9 10 1 2 8 5 11 12 4 15
13 8 11 5 6 15 0 3 4 7 2 12 1 10 14 9
10 6 9 0 12 11 7 13 15 1 3 14 5 2 8 4
3 15 0 6 10 1 13 8 9 4 5 11 12 7 2 14
S5
2 12 4 1 7 10 11 6 8 5 3 15 13 0 14 9
14 11 2 12 4 7 13 1 5 0 15 10 3 9 8 6
4 2 1 11 10 13 7 8 15 9 12 5 6 3 0 14
11 8 12 7 1 14 2 13 6 15 0 9 10 4 5 3
S6
12 1 10 15 9 2 6 8 0 13 3 4 14 7 5 11
10 15 4 2 7 12 9 5 6 1 13 14 0 11 3 8
9 14 15 5 2 8 12 3 7 0 4 10 1 13 11 6
4 3 2 12 9 5 15 10 11 14 1 7 6 0 8 13
S7
4 11 2 14 15 0 8 13 3 12 9 7 5 10 6 1
13 0 11 7 4 9 1 10 14 3 5 12 2 15 8 6
1 4 11 13 12 3 7 14 10 15 6 8 0 5 9 2
6 11 13 8 1 4 10 7 9 5 0 15 14 2 3 12
S8
13 2 8 4 6 15 11 1 10 9 3 14 5 0 12 7
1 15 13 8 10 3 7 4 12 5 6 11 0 14 9 2
7 11 4 1 9 12 14 2 0 6 10 13 15 3 5 8
2 1 14 7 4 10 8 13 15 12 9 0 3 5 6 11
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 56
Example: For the first round, we obtain as the output of the eight S boxes:
The final stage in the calculation of f is to do a permutation P of the S-box output to obtain the final
value of f:
f = P(S1(B1)S2(B2)...S8(B8))
The permutation P is defined in the following table. P yields a 32-bit output from a 32-bit input by
permuting the bits of the input block.
16 7 20 21
29 12 28 17
1 15 23 26
5 18 31 10
2 8 24 14
32 27 3 9
19 13 30 6
22 11 4 25
we get
R1 = L0 + f(R0 , K1 )
In the next round, we will have L2 = R1, which is the block we just calculated, and then we must
calculate R2 =L1 + f(R1, K2), and so on for 16 rounds. At the end of the sixteenth round we have
the blocks L16 and R16. We then reverse the order of the two blocks into the 64-bit block
IP-1
40 8 48 16 56 24 64 32
39 7 47 15 55 23 63 31
38 6 46 14 54 22 62 30
37 5 45 13 53 21 61 29
36 4 44 12 52 20 60 28
35 3 43 11 51 19 59 27
34 2 42 10 50 18 58 26
33 1 41 9 49 17 57 25
That is, the output of the algorithm has bit 40 of the preoutput block as its first bit, bit 8 as its second
bit, and so on, until bit 25 of the preoutput block is the last bit of the output.
Example: If we process all 16 blocks using the method defined previously, we get, on the 16th
round,
We reverse the order of these two blocks and apply the final permutation to
85E813540F0AB405.
Decryption is simply the inverse of encryption, follwing the same steps as above, but reversing the
order in which the subkeys are applied.
The DES algorithm turns a 64-bit message block M into a 64-bit cipher block C. If each 64-bit block
is encrypted individually, then the mode of encryption is called Electronic Code Book (ECB) mode.
There are two other modes of DES encryption, namely Chain Block Coding (CBC) and Cipher
Feedback (CFB), which make each cipher block dependent on all the previous messages blocks
through an initial XOR operation.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 58
Cracking DES
Before DES was adopted as a national standard, during the period NBS was soliciting comments on
the proposed algorithm, the creators of public key cryptography, Martin Hellman and Whitfield
Diffie, registered some objections to the use of DES as an encryption algorithm. Hellman wrote:
"Whit Diffie and I have become concerned that the proposed data encryption standard, while
probably secure against commercial assault, may be extremely vulnerable to attack by an
intelligence organization" (letter to NBS, October 22, 1975).
Diffie and Hellman then outlined a "brute force" attack on DES. (By "brute force" is meant that you
try as many of the 2^56 possible keys as you have to before decrypting the ciphertext into a sensible
plaintext message.) They proposed a special purpose "parallel computer using one million chips to
try one million keys each" per second, and estimated the cost of such a machine at $20 million.
Fast forward to 1998. Under the direction of John Gilmore of the EFF, a team spent $220,000 and
built a machine that can go through the entire 56-bit DES key space in an average of 4.5 days. On
July 17, 1998, they announced they had cracked a 56-bit key in 56 hours. The computer, called Deep
Crack, uses 27 boards each containing 64 chips, and is capable of testing 90 billion keys a second.
Despite this, as recently as June 8, 1998, Robert Litt, principal associate deputy attorney general at
the Department of Justice, denied it was possible for the FBI to crack DES: "Let me put the technical
problem in context: It took 14,000 Pentium computers working for four months to decrypt a single
message . . . . We are not just talking FBI and NSA [needing massive computing power], we are
talking about every police department."
Responded cryptograpy expert Bruce Schneier: " . . . the FBI is either incompetent or lying, or both."
Schneier went on to say: "The only solution here is to pick an algorithm with a longer key; there isn't
enough silicon in the galaxy or enough time before the sun burns out to brute- force triple-DES"
(Crypto-Gram, Counterpane Systems, August 15, 1998).
• Question: How to deliver a shared key to 2 parties that wish to exchange data without others
to see the key?
•
• Key selected by A and delivered to B
• Third party selects key and delivers to A and B
• Use old key to encrypt and transmit new key from A to B
• Use old key to transmit new key from third party to A and B
Public-Key Certificates
• certificates allow key exchange without real-time access to public-key authority
• a certificate binds identity to public key
– usually with other info such as period of validity, rights of use etc
• with all contents signed by a trusted Public-Key or Certificate Authority (CA)
• can be verified by anyone who knows the public-key authority’s public-key
Message Encryption
• message encryption by itself also provides a measure of authentication
• if symmetric encryption is used then:
– receiver know sender must have created it
– since only sender and receiver know key used
– know content cannot have been altered
– if message has suitable structure, redundancy or a checksum to detect any changes
• However, generally unreliable – will see
• if public-key encryption is used:
– encryption provides no confidence of sender
– since anyone potentially knows public-key
– however if
• sender signs message using their private-key
• then encrypts with recipients public key
• have both secrecy and authentication
– again need to recognize corrupted messages
– but at cost of two public-key uses on message
Hash Functions
• condenses arbitrary message to fixed size
• usually assume that the hash function is public and not keyed
– cf. MAC which is keyed
• hash used to detect changes to message
• can use in various ways with message
• often to create a digital signature
Hash Algorithms
MD4
• precursor to MD5
• also produces a 128-bit hash of message
• has 3 rounds of 16 steps vs 4 in MD5
• design goals:
– collision resistant (hard to find collisions)
– direct security (no dependence on "hard" problems)
– fast, simple, compact
– favours little-endian systems (eg PCs)
Strength of MD5
• MD5 hash is dependent on all message bits
• Strong security claims
• known attacks are:
– Berson 92 attacked any 1 round using differential cryptanalysis (but can’t extend)
– Boer & Bosselaers 93 found a pseudo collision (again unable to extend)
– Dobbertin 96 created collisions on MD compression function (but initial constants
prevent exploit)
• conclusion is that MD5 looks vulnerable soon
RIPEMD-160
HMAC Security
• know that the security of HMAC relates to that of the underlying hash algorithm
• attacking HMAC requires either:
– brute force attack on key used
– birthday attack (but since keyed would need to observe a very large number of
messages)
• choose hash function used based on speed verses security constraints
RSA Example
• sample RSA encryption/decryption is:
• given message M = 88 (nb. 88<187)
• encryption:
C = 887 mod 187 = 11
• decryption:
M = 1123 mod 187 = 88
Exponentiation
• can use the Square and Multiply Algorithm
• a fast, efficient algorithm for exponentiation
• concept is based on repeatedly squaring base
• and multiplying in the ones that are needed to compute the result
• look at binary representation of exponent
• only takes O(log2 n) multiples for number n
– eg. 75 = 74(71) = 3(7) = 10 mod 11
– eg. 3129 = 3128(31) = 5(3) = 4 mod 11
RSA Key Generation
• users of RSA must:
– determine two primes at random - p, q
– select either e or d and compute the other
• primes p,q must not be easily derived from modulus N=p.q
– means must be sufficiently large
– typically guess and use probabilistic test
• exponents e, d are inverses, so use Inverse algorithm to compute the other
RSA Security
• four approaches to attacking RSA:
– brute force key search (infeasible given size of numbers)
– mathematical attacks (based on difficulty of computing ø(N), by factoring modulus
N)
– timing attacks (on running of decryption)
– misuse attacks
Digital Signatures
• have looked at message authentication
– but does not address issues of lack of trust
• digital signatures provide the ability to:
– verify author, date & time of signature
– authenticate message contents
– be verified by third parties to resolve disputes
• hence include authentication function with additional capabilities
Digital Signature Properties
• must depend on the message signed
• must use information unique to sender
– to prevent both forgery and denial
• must be relatively easy to produce
• must be relatively easy to recognize & verify
• be computationally infeasible to forge
– with new message for existing digital signature
– with fraudulent digital signature for given message
• be practical save digital signature in storage
Direct Digital Signatures
• involve only sender & receiver
• assumed receiver has sender’s public-key
• digital signature made by sender signing entire message or hash with private-key
• can encrypt using receivers public-key
• important that sign first then encrypt message & signature
• security depends on sender’s private-key
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 78
Types of Authentication
• What you know
– Password
– Secret (symmetric) key
– Private (asymmetric) key
• What you have
– Smart card
– Fingerprints
• Where you are
– Network location
Digital Signature Standard (DSS)
• US Govt approved signature scheme FIPS 186
• uses the SHA hash algorithm
• designed by NIST & NSA in early 90's
• DSS is the standard, DSA is the algorithm
• a variant on ElGamal and Schnorr schemes
• creates a 320 bit signature, but comparable to RSA 512-1024 bit security
• security depends on difficulty of computing discrete logarithms
DSA Key Generation
• have shared global public key values (p,q,g):
– a large prime p = 2L
• where L= 512 to 1024 bits and is a multiple of 64
– choose q, a 160 bit prime factor of p-1
– choose g = h(p-1)/q
• where h<p-1, h(p-1)/q (mod p) > 1
• users choose private & compute public key:
– choose x<q
– compute y = gx (mod p)
Algorithms Used
• Message Digesting: SHA-1 and MDS
• Digital Signatures: DSS
• Secret-Key Encryption: Triple-DES, RC2/40 (exportable)
• Public-Private Key Encryption: RSA with key sizes of 512 and 1024 bits, and Diffie-
Hellman (for session keys).
KERBEROS
In Greek mythology, a many headed dog, the guardian of the entrance of Hades
• Users wish to access services on servers.
• Three threats exist:
– User pretend to be another user.
– User alter the network address of a workstation.
– User eavesdrop on exchanges and use a replay attack.
• Provides a centralized authentication server to authenticate users to servers and servers to
users.
• Relies on conventional encryption, making no use of public-key encryption
• Two versions: version 4 and 5
• Version 4 makes use of DES
Kerberos Version 4
• Terms:
– C = Client
– AS = authentication server
– V = server
– IDc = identifier of user on C
– IDv = identifier of V
– Pc = password of user on C
– ADc = network address of C
– Kv = secret encryption key shared by AS an V
– TS = timestamp
– || = concatenation
Overview of Kerberos
Kerberos - in practice
X.509 Formats
Authentication Procedures
IPv6 Header
IPSec is not a single protocol. Instead, IPSec provides a set of security algorithms plus a general
framework that allows a pair of communicating entities to use whichever algorithms provide security
appropriate for the communication.
• Applications of IPSec
– Secure branch office connectivity over the Internet
– Secure remote access over the Internet
– Establsihing extranet and intranet connectivity with partners
– Enhancing electronic commerce security
IP Security Scenario
IP Security Overview
• Benefits of IPSec
– Transparent to applications (below transport layer (TCP, UDP)
– Provide security for individual users
• IPSec can assure that:
– A router or neighbor advertisement comes from an authorized router
– A redirect message comes from the router to which the initial packet was sent
– A routing update is not forged
IPSec Services
• Access Control
• Connectionless integrity
• Data origin authentication
• Rejection of replayed packets
• Confidentiality (encryption)
• Limited traffic flow confidentiallity
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 100
SSL and TLS
• SSL was originated by Netscape
• TLS working group was formed within IETF
• First version of TLS can be viewed as an SSLv3.1
SSL Architecture
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 101
SSL Record Format
• one of 3 SSL specific protocols which use the SSL Record protocol
• a single message
• causes pending state to become current
• hence updating the cipher suite in use
SSL Alert Protocol
• conveys SSL-related alerts to peer entity
• severity
• warning or fatal
• specific alert
• unexpected message, bad record mac, decompression failure, handshake
failure, illegal parameter
• close notify, no certificate, bad certificate, unsupported certificate, certificate
revoked, certificate expired, certificate unknown
• compressed & encrypted like all SSL data
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 102
SSL Handshake Protocol
• allows server & client to:
– authenticate each other
– to negotiate encryption & MAC algorithms
– to negotiate cryptographic keys to be used
• comprises a series of messages in phases
– Establish Security Capabilities
– Server Authentication and Key Exchange
– Client Authentication and Key Exchange
– Finish
SET Services
• Provides a secure communication channel in a transaction.
• Provides tust by the use of X.509v3 digital certificates.
• Ensures privacy.
SET Overview
• Key Features of SET:
– Confidentiality of information
– Integrity of data
– Cardholder account authentication
– Merchant authentication
SET Participants
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 104
Sequence of events for transactions
1. The customer opens an account.
2. The customer receives a certificate.
3. Merchants have their own certificates.
4. The customer places an order.
5. The merchant is verified.
6. The order and payment are sent.
7. The merchant request payment authorization.
8. The merchant confirm the order.
9. The merchant provides the goods or service.
10. The merchant requests payments.
Dual Signature
• customer creates dual messages
– order information (OI) for merchant
– payment information (PI) for bank
• neither party needs details of other
• but must know they are linked
• use a dual signature for this
– signed concatenated hashes of OI & PI
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 105
Purchase Request – Customer
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 106
Purchase Request – Merchant
1. verifies cardholder certificates using CA sigs
2. verifies dual signature using customer's public signature key to ensure order has not been
tampered with in transit & that it was signed using cardholder's private signature key
3. processes order and forwards the payment information to the payment gateway for
authorization (described later)
4. sends a purchase response to cardholder
Proxy Configuration
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 108
SNMP v1 and v2
• Trap – an unsolicited message (reporting an alarm condition)
• SNMPv1 is ”connectionless” since it utilizes UDP (rather than TCP) as the transport layer
protocol.
• SNMPv2 allows the use of TCP for ”reliable, connection-oriented” service.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 109
------ InformRequest Manager to Transmit
manager unsolicited
information
GetResponse Response Agent to manager Respond to
or Manage to manager request
manager(SNMPv2)
Trap SNMPv2-Trap Agent to manager Transmit
unsolicited
information
SNMPv3
• SNMPv3 defines a security capability to be used in conjunction with SNMPv1 or v2
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 110
Traditional SNMP Manager
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 111
User Security Model (USM)
• Designed to secure against:
– Modification of information
– Masquerade
– Message stream modification
– Disclosure
• Not intended to secure against:
– Denial of Service (DoS attack)
– Traffic analysis
Key Localization Process
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 112
Intruders and Viruses
• Intruders
– Intrusion Techniques
– Password Protection
– Password Selection Strategies
– Intrusion Detection
• Viruses and Related Threats
– Malicious Programs
– The Nature of Viruses
– Antivirus Approaches
– Advanced Antivirus Techniques
Intruders
• Three classes of intruders (hackers or crackers):
– Masquerader
– Misfeasor
– Clandestine user
Intrusion Techniques
• System maintain a file that associates a password with each authorized user.
• Password file can be protected with:
– One-way encryption
– Access Control
Intrusion Techniques
• Techniques for guessing passwords:
• Try default passwords.
• Try all short words, 1 to 3 characters long.
• Try all the words in an electronic dictionary(60,000).
• Collect information about the user’s hobbies, family names, birthday, etc.
• Try user’s phone number, social security number, street address, etc.
• Try all license plate numbers (MUP103).
• Use a Trojan horse
• Tap the line between a remote user and the host system.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 113
UNIX Password Scheme
”Salt”
• The salt serves three purposes:
– Prevents duplicate passwords.
– Effectively increases the length of the password.
– Prevents the use of hardware implementations of DES
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 116
Distributed Intrusion Detection – Agent Implementation
Password Management
• front-line defense against intruders
• users supply both:
– login – determines privileges of that user
– password – to identify them
• passwords often stored encrypted
– Unix uses multiple DES (variant with salt)
– more recent systems use crypto hash function
Managing Passwords
• need policies and good user education
• ensure every account has a default password
• ensure users change the default passwords to something they can remember
• protect password file from general access
• set technical policies to enforce good passwords
– minimum length (>6)
– require a mix of upper & lower case letters, numbers, punctuation
– block know dictionary words
• may reactively run password guessing tools
– note that good dictionaries exist for almost any language/interest group
• may enforce periodic changing of passwords
• have system monitor failed login attempts, & lockout account if see too many in a short
period
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 117
• do need to educate users and get support
• balance requirements with user acceptance
• be aware of social engineering attacks
Viruses and ”Malicious Programs”
• Computer “Viruses” and related programs have the ability to replicate themselves on an ever
increasing number of computers. They originally spread by people sharing floppy disks.
Now they spread primarily over the Internet (a “Worm”).
• Other “Malicious Programs” may be installed by hand on a single machine. They may also
be built into widely distributed commercial software packages. These are very hard to detect
before the payload activates (Trojan Horses, Trap Doors, and Logic Bombs).
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 118
Virus Phases
• Dormant phase - the virus is idle
• Propagation phase - the virus places an identical copy of itself into other programs
• Triggering phase – the virus is activated to perform the function for which it was intended
• Execution phase – the function is performed
Virus Structure
Types of Viruses
• Parasitic Virus - attaches itself to executable files as part of their code. Runs whenever the
host program runs.
• Memory-resident Virus - Lodges in main memory as part of the residual operating system.
• Boot Sector Virus - infects the boot sector of a disk, and spreads when the operating system
boots up (original DOS viruses).
• Polymorphic Virus - mutates with every new host to prevent signature detection.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 119
Macro Viruses
• Microsoft Office applications allow “macros” to be part of the document. The macro could
run whenever the document is opened, or when a certain command is selected (Save File).
• Platform independent.
• Infect documents, delete files, generate email and edit letters.
Antivirus Approaches
1st Generation, Scanners: searched files for any of a library of known virus “signatures.” Checked
executable files for length changes.
2nd Generation, Heuristic Scanners: looks for more general signs than specific signatures (code
segments common to many viruses). Checked files for checksum or hash changes.
3rd Generation, Activity Traps: stay resident in memory and look for certain patterns of software
behavior (e.g., scanning files).
4th Generation, Full Featured: combine the best of the techniques above.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 120
Email Virus
• spread using email with attachment containing a macro virus cf Melissa
• triggered when user opens attachment
• or worse even when mail viewed by using scripting features in mail agent
• usually targeted at Microsoft Outlook mail agent & Word/Excel documents
Worms
• replicating but not infecting program
• typically spreads over a network
– cf Morris Internet Worm in 1988
– led to creation of CERTs
• using users distributed privileges or by exploiting system vulnerabilities
• widely used by hackers to create zombie PC's, subsequently used for further attacks, esp
DoS
• major issue is lack of security of permanently connected systems, esp PC's
Worm Operation
• worm phases like those of viruses:
– dormant
– propagation
• search for other systems to infect
• establish connection to target remote system
• replicate self onto remote system
– triggering
– execution
Morris Worm
• best known classic worm
• released by Robert Morris in 1988
• targeted Unix systems
• using several propagation techniques
– simple password cracking of local pw file
– exploit bug in finger daemon
– exploit debug trapdoor in sendmail daemon
• if any attack succeeds then replicated self
Recent Worm Attacks
• new spate of attacks from mid-2001
• Code Red
– exploited bug in MS IIS to penetrate & spread
– probes random IPs for systems running IIS
– had trigger time for denial-of-service attack
– 2nd wave infected 360000 servers in 14 hours
• Code Red 2
– had backdoor installed to allow remote control
• Nimda
– used multiple infection mechanisms
• email, shares, web client, IIS, Code Red 2 backdoor
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 121
Virus Countermeasures
• viral attacks exploit lack of integrity control on systems
• to defend need to add such controls
• typically by one or more of:
– prevention - block virus infection mechanism
– detection - of viruses in infected system
– reaction - restoring system to clean state
Firewalls
• Information systems undergo a steady evolution (from small LAN`s to Internet connectivity)
• Strong security features for all workstations and servers not established
• The firewall is inserted between the premises network and the Internet
• Aims:
• Establish a controlled link
• Protect the premises network from Internet-based attacks
• Provide a single choke point
Firewall Characteristics
• Design goals:
– All traffic from inside to outside must pass through the firewall (physically blocking
all access to the local network except via the firewall)
– Only authorized traffic (defined by the local security police) will be allowed to pass
• Design goals:
– The firewall itself is immune to penetration (use of trusted system with a secure
operating system)
Firewall Characteristics
• Four general techniques:
• Service control
– Determines the types of Internet services that can be accessed, inbound or outbound
• Direction control
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 122
– Determines the direction in which particular service requests are allowed to flow
• User control
– Controls access to a service according to which user is attempting to access it
• Behavior control
– Controls how particular services are used (e.g. filter e-mail)
Types of Firewalls
• Three common types of Firewalls:
– Packet-filtering routers
– Application-level gateways
– Circuit-level gateways
– (Bastion host)
Types of Firewalls
• Packet-filtering Router
Packet-filtering Router
Applies a set of rules to each incoming IP packet and then forwards or discards the packet
Filter packets going in both directions
The packet filter is typically set up as a list of rules based on matches to fields in the IP or TCP
header
Two default policies (discard or forward)
• Advantages:
– Simplicity
– Transparency to users
– High speed
• Disadvantages:
– Difficulty of setting up packet filter rules
– Lack of Authentication
• Application-level Gateway
– Also called proxy server
– Acts as a relay of application-level traffic
• Advantages:
– Higher security than packet filters
– Only need to scrutinize a few allowable applications
– Easy to log and audit all incoming traffic
• Disadvantages:
– Additional processing overhead on each connection (gateway as splice point)
Circuit-level Gateway
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 124
• Circuit-level Gateway
– Stand-alone system or
– Specialized function performed by an Application-level Gateway
– Sets up two TCP connections
– The gateway typically relays TCP segments from one connection to the other without
examining the contents
• Circuit-level Gateway
– The security function consists of determining which connections will be allowed
– Typically use is a situation in which the system administrator trusts the internal users
– An example is the SOCKS package
• Bastion Host
– A system identified by the firewall administrator as a critical strong point in the
network´s security
– The bastion host serves as a platform for an application-level or circuit-level gateway
Trusted Systems
• One way to enhance the ability of a system to defend against intruders and malicious
programs is to implement trusted system technology
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 125
• Access Matrix: Basic elements of the model
– Subject: An entity capable of accessing objects, the concept of subject equates with
that of process
– Object: Anything to which access is controlled (e.g. files, programs)
– Access right: The way in which an object is accessed by a subject (e.g. read, write,
execute)
• Access Control List: Decomposition of the matrix by columns
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 126
• Reference Monitor
– Controlling element in the hardware and operating system of a computer that regulates
the access of subjects to objects on basis of security parameters
– The monitor has access to a file (security kernel database)
– The monitor enforces the security rules (no read up, no write down)
• Properties of the Reference Monitor
– Complete mediation: Security rules are enforced on every access
– Isolation: The reference monitor and database are protected from unauthorized
modification
– Verifiability: The reference monitor’s correctness must be provable (mathematically)
• A system that can provide such verifications (properties) is referred to as a trusted system
Trojan Horse Defense
• Secure, trusted operating systems are one way to secure against Trojan Horse attacks
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 127
TCP Session Hijacking /UDP Hijacking
When computers need to talk to each other, they simply do so. But, how do you know that your
computer is really talking to the computer it thinks it's talking to?
How do you know that an attacker has not taken over the session between the computers and is
passively monitoring the conversation, or even changing it? You would certainly know it—
belatedly—if the order for 1,000 widgets that you sent to a business partner was received as an
order for 100,000 widgets. This can happen, courtesy of a well-timed strike by an intruder.
Session hijacking works by taking advantage of the fact that most communications are protected (by
providing credentials) at session setup, but not thereafter. These attacks generally fall into three
categories: Man-in-the-middle (MITM), Blind Hijack, and Session Theft.
In MITM attacks, an attacker intercepts all communications between two hosts. With
communications between a client and server now flowing through the attacker, he or she is free to
modify their content. Protocols that rely on the exchange of public keys to protect communications
are often the target of these types of attacks.
In blind hijacking, an attacker injects data such as malicious commands into intercepted
communications between two hosts commands like "net.exe local group administrators /add Evil
Attacker". This is called blind hijacking because the attacker can only inject data into the
communications stream; he or she cannot see the response to that data (such as "The command
completed successfully.") Essentially, the blind hijack attacker is shooting data in the dark, but as
you will see shortly, this method of hijacking is still very effective.
In a session theft attack, the attacker neither intercepts nor injects data into existing communications
between two hosts. Instead, the attacker creates new sessions or uses old ones. This type of session
hijacking is most common at the application level, especially Web applications.
Session hijacking at the network level is especially attractive to attackers. They do not need host
access, as they do with host-level session hijacking. Nor do they need to customize attacks on a per-
application basis, as they do at the application level. Network-level session hijacking attacks allow
attackers to remotely take over sessions, usually undetected. But successfully hijacking a session at
the network level requires an attacker to overcome various obstacles, as you will see in the next few
sections.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 128
Hijacking a TCP Session
One of the key features of TCP is reliability and ordered delivery of packets. To accomplish this,
TCP uses acknowledgment (ACK) packets and sequence numbers. Manipulating these is the basis
for TCP session hijacking. As we mentioned earlier, the MITM attacker simply needs to be
positioned so that communications between the client and the server are relayed through him or her.
To understand how an attacker might sneak into the TCP session in a blind session hijack attack, you
need to look at what happens when a client initiates a TCP session with the server.
As shown in Figure 1, the client first initiates a session with the server by sending a synchronization
(SYN) packet to the server with initial sequence number x. The server responds with a SYN/ACK
packet that contains the server's own sequence number p and an ACK number for the client's original
SYN packet. This ACK number indicates the next sequence number the server expects from the
client. In our example, this is x+1, because the client's original SYN packet counted as a single byte.
The client acknowledges receipt of the SYN/ACK packet by sending back to the server an ACK
packet with the next sequence number it expects from the server, which in this case is p+1 (the
server's initial SYN packet sequence number plus one). The client and server are ready to start
exchanging data.
The sequence number values just described are important for understanding how to successfully
hijack this session later, so pay close attention to them in the paragraphs that follow. The same goes
for ACK numbers, which are key to understanding TCP ACK storms.
For now, observe what happens to these sequence numbers when the client starts sending data to the
server (see Figure 2). In order to keep the example simple, the client sends the character A in a
single packet to the server.
The client sends the server the single character in a data packet with the sequence number x+1. The
server acknowledges this packet by sending back to the client an ACK packet with number x+2 (x+1,
plus 1 byte for the A character) as the next sequence number expected by the server. Enter the
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 129
attacker. If the attacker wanted to inject data into the TCP session as the client, he or she would need
to:
The first and second tasks are easily accomplished, but the third is a bit trickier. Tricky, but not
impossible. Essentially, the attacker needs a way to prevent the client from sending into the session
new data that would shift sequence numbers forward. To do this, the attacker could just send the data
to inject and hope it is received before the real client can send new data, as shown in Figure 3. Or,
he or she could perform a denial of service (DoS) attack on the client, or perhaps some tricks that use
address resolution protocol (ARP) spoofing.
Here is how this might play out. The attacker sends a single Z character to the server with sequence
number x+2. The server accepts it and sends the real client an ACK packet with acknowledgment
number x+3 to confirm that it has received the Z character. When the client receives the ACK
packet, it will be confused, either because it did not send any data or because the next expected
sequence is incorrect. (Maybe the attacker sent something "nice" like "mv `which emacs` /vmunix
&& shutdown –r now" and not just a single character.) As you will see later, this confusion can
cause a TCP ACK storm, which can disrupt a network. In any case, the attacker has now
successfully hijacked this session.
Attackers can automate the session hijacking process just described with tools such as Juggernaut,
by Mike Schiffman, and Hunt, by Pavel Krauz.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 130
Figure 4 Session Hijacking over UDP
DNS queries, online games like the Quake series and Half-Life, and peer-to-peer sessions are
common protocols that work over UDP; all are popular targets for this kind of session hijacking.
As you read through the attack strategies discussed here, keep in mind that many can be easily
defeated by the countermeasures for network-level session hijacking. TCP ACK storms, for
example, are not possible when the attacker cannot inject data into a session. Routing table
modifications also quickly become a wasted effort for an attacker if they cannot interpret or modify
data that gets routed through them. It is still useful and interesting, however, to know what your
enemy has in his or her bag of tricks. Some common items include TCP ACK packet storms, ARP
table modifications, TCP resynchronizations, and remote modifications of routing tables.
To understand this threat, look at what happens when an attacker hijacks a TCP session from the
TCP protocol's point of view. Assume that the attacker has forged the correct packet information
(headers, sequence numbers, and so on) at some point during the session. When the attacker sends to
the server-injected session data, the server will acknowledge the receipt of the data by sending to the
real client an ACK packet. This packet will most likely contain a sequence number that the client is
not expecting, so when the client receives this packet, it will try to resynchronize the TCP session
with the server by sending it an ACK packet with the sequence number that it is expecting. This
ACK packet will in turn contain a sequence number that the server is not expecting, and so the
server will resend its last ACK packet. This cycle goes on and on and on, and this rapid passing back
and forth of ACK packets creates an ACK storm, as shown in Figure 5.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 131
Figure 5 ACK Storm
As the attacker injects more and more data, the size of the ACK storm increases and can quickly
degrade network performance. If neither the attacker nor the client explicitly closes the session, the
storm will likely stop itself eventually when ACK packets are lost in the storm.
Say that Host A (IP address 192.168.1. 100) wants to send data to Host B (IP address
192.168.1.250). No prior communications have occurred between Hosts A and B, so the ARP table
entries for Host B on Host A are empty. As shown in Figure 6, Host A broadcasts an ARP request
packet indicating that the owner of the IP address 192.168.1.250 should respond to Host A at
192.168.1.100 with its MAC address. The broadcast packet is sent to every machine in the network
segment, and only the true owner of the IP address 192.168.1.250 should respond. (As you will see
shortly, this is not always the case.) All other hosts discard this request packet, but Host A receives
an ARP reply packet from Host B indicating that its MAC address is BB:BB:BB:BB:BB:BB. Host A
updates its ARP table, and can now send data to Host B.
Attackers can also use ARP packet manipulation to quiet TCP ACK storms, which are noisy and
easily detected by devices such as intrusion detection system (IDS) sensors (see Figure 8). Session
hijacking tools such as Hunt accomplish this by sending unsolicited ARP replies. Most systems will
accept these packets and update their ARP tables with whatever information is provided. In our Host
A/Host B example, an attacker could send Host A a spoofed ARP reply indicating that Host B's
MAC address is something nonexistent (like C0:C0:C0: C0:C0:C0), and send Host B another
spoofed ARP reply indicating that Host A's MAC address is also something nonexistent (such as
D0:D0:D0:D0:D0:D0). Any ACK packets between Host A and Host B that could cause a TCP ACK
storm during a network-level session hijacking attack are sent to invalid MAC addresses and lost.
G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 133