Information Security

Information Security
Introduction
Attacks, services and mechanisms
Security attacks
Security services
Methods of Defense
A model for Internet work Security
Attacks, Services and Mechanisms
Security Attack: Any action that compromises the security of information.
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
Interruption: This is an attack on availability
Interception: This is an attack on confidentiality
Modification: This is an attack on integrity
Fabrication: This is an attack on authenticity

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 1
Security Services
Confidentiality (privacy)
Authentication (who created or sent the data)
Integrity (has not been altered)
Non-repudiation (the order is final)
Access control (prevent misuse of resources)
Availability (permanence, non-erasure)
Denial of Service Attacks
Virus that deletes files
Security Goals
Security Services (X.800)
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.
X.800 defines it in 5 major categories
Authentication - assurance that the communicating entity is the one claimed.

Access Control - prevention of the unauthorized use of a resource.
Data Confidentiality –protection of data from unauthorized disclosure.
Data Integrity - assurance that data received is as sent by an authorized entity.
Non-Repudiation - protection against denial by one of the parties in a communication.

Security Mechanisms (X.800)
Specific security mechanisms:

Encipherment, digital signatures, access controls, data integrity, authentication exchange, traffic
padding, routing control, notarization
Pervasive security mechanisms:

–Trusted functionality, security labels, event detection, security audit trails, security recovery.ery
Security Attacks (X.800)
Passive attacks - eavesdropping on, or monitoring of, transmissions to:
–Obtain message contents, or
–Monitor traffic flows
Active attacks – modification of data stream to:
–Masquerade of one entity as some other–Replay previous messages
–Modify messages in transit
–Denial of service
A Model for Internet work security

Basic Concepts
Cryptography: The Cryptography is the art or science encompassing the principles and methods of
transforming an intelligible message into one that is unintelligible, and then retransforming that
message back to its original form. The Cryptography is the study of Encryption Algorithm.
Plaintext: The original intelligible message.

Cipher text: The transformed message / coded message.
Cipher: An algorithm for transforming an intelligible message into one that is unintelligible by
transposition and/or substitution methods.
Shared key: Some critical information used by the cipher, known only to the sender & receiver
Encipher (encode): The process of converting plaintext to ciphertext using a cipher and a key
Decipher (decode): The process of converting ciphertext back into plaintext using a cipher and a
key.
Cryptanalysis: The study of principles and methods of transforming an unintelligible message back
into an intelligible message without knowledge of the key. Also called code breaking
Cryptology: The study of both cryptography and cryptanalysis.
Code: An algorithm for transforming an intelligible message into an unintelligible one using a code-
book.
Types of Cryptanalytic Attacks
Have several different types of attacks
Ciphertext only
Only have access to some enciphered messages
Use statistical attacks only
Known plaintext
Know (or strongly suspect) some plaintext-ciphertext pairs
Use this knowledge in attacking cipher
Chosen plaintext
Can select plaintext and obtain corresponding ciphertext.
Use knowledge of algorithm structure in attack.
Chosen plaintext-ciphertext
Can select plaintext and obtain corresponding ciphertext, or select ciphertext and obtain
plaintext.
Allows further knowledge of algorithm structure to be used.

Unconditional and Computational Security
Two fundamentally different ways ciphers may be secure
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.
Brute Force Search
Always possible to simply try every key.

Most basic attack, proportional to size of key space.
Assume either know / recognise plaintext.
Simplified Data Encryption Standard (S-DES)

The Simplified DES is developed by Professor Edward Schaefer of Santa Clara University, is an
educational rather than a secure encryption algorithm. It has similar properties and structure to DES
with mush faster parameters.
Data Encryption
The S-DES encryption algorithm takes an 8-bit block of of plaintext, and 10 bit key as input and
produces an 8 –bit ciphertext as output.
The S-DES decryption algorithm takes an 8-bit block of ciphertext as input and produces the original
8-bit block of plaintext.
The encryption algorithm involves five functions:
1. Initial Permutation
2. Complex function
3. Switches
4. Complex function
5. Inverse of the Initial Permutation
The complex function takes as input not only the data passing through the encryption algorithm, but
also an 8-bit key. The algorithm could have been designed to work with a 16-bit key, consisting of
two 8-bit subkeys; one used for each occurrence of complex function .The 8-bit key could have been
used with the same key used twice.
Key Generation

Complex Function
Stream Ciphers and Block Ciphers
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 .
Feistel Cipher Structure

Horst Feistel devised the Feistel cipher based on concept of invertible product cipher.
-partitions input block into two halves
– process through multiple rounds which
– perform a substitution on left data half
– based on round function of right half & subkey
– then have permutation swapping halves
-implements Shannon’s substitution-permutation network concept.

Feistel Cipher Design Principles
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.

Feistel Cipher Decryption
Data Encryption Standard (DES)

Designed at IBM during the 1970s and officially adopted as the NIST standard encryption algorithm
for unclassified data in 1976, DES has become the bastion of the cryptography market. However,
DES has since become outdated, its long reign as official NIST algorithm ending in 1997. Though
DES accepts a 64-bit key, the key setup routines effectively discard 8 bits, giving DES a 56-bit
effective key length. DES remains widely in use. During the design of DES, the NSA provided
secret S-Boxes. After differential cryptanalysis had been discovered outside the closed fortress of the
NSA, it was revealed that the DES S-boxes were designed to be resistant against differential
cryptanalysis. DES is becoming weaker and weaker over time; modern computing power is fast
approaching the computational horsepower needed to easily crack DES.
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.
DES is implemented in Kremlin (accessible through Kremlin SDK API).
DES Encryption
Initial Permutation
-First step of the data computation

-IP reorders the input data bits
-even bits to LH half, odd bits to RH half
-quite regular in structure (easy in h/w)
-purpose unclear
– Security value?
– Speed bump?
DES Round Structure
-uses two 32-bit L & R halves

-as for any Feistel cipher can describe as:
Li = Ri–1
Ri = Li–1 xor F(Ri–1, Ki)
-takes 32-bit R half and 48-bit subkey and:
– expands R to 48-bits using perm E
– adds to subkey
– passes through 8 S-boxes to get 32-bit result
– finally permutes this using 32-bit perm P
DES Round Structure

Substitution Boxes S
-have eight S-boxes, each maps 6 to 4 bits

-2 input bits select one of 4 permutations unique to that box
-selection depends on both data & key
-S-boxes are the nonlinear components
-linear systems can be solved!
-very sensitive design
DES Key Schedule
-forms subkeys used in each round

-consists of:
-initial permutation of the key (PC1) which selects 56-bits in two 28-bit halves
-16 stages consisting of:
-selecting 24-bits from each half
-permuting them by PC2 for use in function f,
-rotating each half separately either 1 or 2 places depending on the key rotation schedule K
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
-key desirable property of encryption alg

-where a change of one input or key bit results in changing approx half output bits
-making attempts to “home-in” by guessing keys impossible
-DES exhibits strong avalanche
Strength of DES – Key Size
-56-bit keys have 256 = 7.2 x 1016 values

-brute force search looks hard
-recent advances have shown is possible
-in 1997 on Internet in a few months
-in 1998 on dedicated h/w (EFF) in a few days
-in 1999 above combined in 22hrs!
-still must be able to recognize plaintext

Strength of DES – Timing Attacks
-attacks actual implementation of cipher

-use knowledge of consequences of implementation to derive knowledge of some/all subkey bits
-specifically use fact that calculations can take varying times depending on the value of the inputs
to it
-particularly problematic on smartcards
Strength of DES – Analytic Attacks
-now have several analytic attacks on DES

-these utilise some deep structure of the cipher
-by gathering information about encryptions
-can eventually recover some/all of the sub-key bits -if necessary then exhaustively search for the
rest
-generally these are statistical attacks
-include
-differential cryptanalysis
-linear cryptanalysis
-related key attacks

Modes of Operation
1. Electronic Codebook Mode (ECB)
2. Cipher Block Chaining Mode(CBC)
3. Cipher Feedback Mode (CFB)
4. Output Feedback Mode (OFB)
5. Counter Mode(CTR)
Electronic Codebook Mode (ECB)
-message is broken into independent blocks which are encrypted

-each block is a value which is substituted, like a codebook, hence name
-each block is encoded independently of the other blocks
Ci = DESK1 (Pi)
-uses: secure transmission of single values
– many insecure uses too

Advantages and Limitations of ECB
-repetitions in message may show in ciphertext

-if aligned with message block
-particularly with data such as graphics
-or with messages that change very little, which become a code-book analysis problem
-weakness due to encrypted message blocks being independent
-main use is sending a few blocks of data
Cipher Block Chaining Mode (CBC)
-message is broken into blocks

-but these are linked together in the encryption operation
-each previous cipher blocks is chained with current plaintext block, hence name
-use Initial Vector (IV) to start process
Ci = DESK1(Pi XOR Ci-1)
C-1 = IV
-uses: bulk data encryption, authentication

Advantages and Limitations of CBC
-each ciphertext block depends on all message blocks

-thus a change in the message affects all ciphertext blocks after the change as well as the original
block
-need Initial Value (IV) known to sender & receiver
-however if IV is sent in the clear, an attacker can change bits of the first block by
changing IV
-hence either IV must be a fixed value or it must be sent encrypted in ECB mode before
rest of message
-IV should be unpredictable, else cipher texts can be tested for plaintext equality
-at end of message, handle possible last short block
-by padding either with known non-data value (eg nulls)
-or pad last block with count of pad size
-eg. [ b1 b2 b3 0 0 0 0 5] <- 3 data bytes, then 5 bytes pad+count
Cipher FeedBack (CFB)
-message is treated as a stream of bits

-added to the output of the block cipher
-result is fed back for next stage (hence name)
-standard allows any number of bit (1,8 or 64 or whatever) to be feed back
-denoted CFB-1, CFB-8, CFB-64 etc
-is most efficient to use all 64 bits (CFB-64)
Ci = Pi XOR DESK1(Ci-1)
C-1 = IV
-uses: stream data encryption, authentication

Advantages and Limitations of CFB
-appropriate when data arrives in bits/bytes

-most common stream mode
-limitation is need to stall while do block encryption after every n-bits
-note that the block cipher is used in encryption mode at both ends
-errors propagate for several blocks after the error
Output Feedback (OFB)

-message is treated as a stream of bits
-output of cipher is added to message
-output is then fed back (hence name)
-feedback is independent of message
-can be computed in advance
Ci = Pi XOR Oi
Oi = DESK1(Oi-1)
O-1 = IV
-uses: stream encryption over noisy channels
Advantages and Limitations of OFB
-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

Counter (CTR)
-a “new” mode, though proposed early on

-similar to OFB but encrypts counter value rather than any feedback value
-must have a different key & counter value for every plaintext block (never reused)
Ci = Pi XOR Oi
Oi = DESK1(i)
-uses: high-speed network encryptions
Advantages and Limitations of CTR
-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)
Triple-DES
-clear a replacement for DES was needed

-theoretical attacks that can break it
-demonstrated exhaustive key search attacks
-AES is a new cipher alternative
-prior to this alternative was to use multiple encryption with DES implementations
-Triple-DES is the chosen form
Why Triple-DES?
-why not Double-DES? EK1[EK2[x]] ?

-What if K1 = K2 ?
-What if K1 != K2 ?
-DES is not a group, so seems OK
-meet-in-the-middle attack
-works whenever use a cipher twice
-since X = EK1[P] = DK2[C]
-attack by encrypting P with all keys and store
-then decrypt C with keys and match X value
-can show takes O(256) steps
Triple-DES with Two-Keys
-hence must use 3 encryptions

-would seem to need 3 distinct keys
-but can use 2 keys with E-D-E sequence
-C = EK1[DK2[EK1[P]]]
-nb encrypt & decrypt equivalent in security
-if K1=K2 then can work with single DES
Triple-DES with Three-Keys
-standardized in ANSI X9.17 & ISO8732

-no current known practical attacks
-although are no practical attacks on two-key Triple-DES, some concerns
-can use Triple-DES with Three-Keys to avoid even these
-C = EK3[DK2[EK1[P]]]
-has been adopted by some Internet applications, eg PGP, S/MIME
Advanced Encryption Standard
-clear a replacement for DES was needed
-have theoretical attacks that can break it
-have demonstrated exhaustive key search attacks
-can use Triple-DES – but slow with small blocks
-US NIST issued call for ciphers in 1997
-15 candidates accepted in Jun 98
-5 were shortlisted in Aug-99
-Rijndael was selected as the AES in Oct-2000
-issued as FIPS PUB 197 standard in Nov-2001
AES Requirements
-private key symmetric block cipher

-128-bit data, 128/192/256-bit keys
-stronger & faster than Triple-DES
-active life of 20-30 years (+ archival use)
-provide full specification & design details
-both C & Java implementations
-NIST have released all submissions & unclassified analyses
AES Evaluation Criteria

-initial criteria:
-security – effort to practically cryptanalyse
-cost – computational
-algorithm & implementation characteristics
-final criteria
-general security
-software & hardware implementation ease
-implementation attacks
-flexibility (in en/decrypt, keying, other factors)
AES Shortlist
-after testing and evaluation, shortlist in Aug-99:
-MARS (IBM) - complex, fast, high security margin
-RC6 (USA) - v. simple, v. fast, low security margin
-Rijndael (Belgium) - clean, fast, good security margin
-Serpent (Euro) - slow, clean, v. high security margin
-Twofish (USA) - complex, v. fast, high security margin
-then subject to further analysis & comment
-saw contrast between algorithms with
-few complex rounds verses many simple rounds
-which refined existing ciphers verses new proposals
The AES Cipher - Rijndael
-designed by Rijmen-Daemen in Belgium
-has 128/192/256 bit keys, 128 bit data
-an iterative rather than feistel cipher
-treats data in 4 groups of 4 bytes
-operates an entire block in every round
-designed to be:
-resistant against known attacks
-speed and code compactness on many CPUs
-design simplicity
Rijndael
-processes data as 4 groups of 4 bytes (state)
-has 9/11/13 rounds in which state undergoes:
-byte substitution (1 S-box used on every byte)
-shift rows (permute bytes between groups/columns)
-mix columns (subs using matrix multipy of groups)
-add round key (XOR state with key material)
-initial XOR key material & incomplete last round
-all operations can be combined into XOR and table lookups - hence very fast & efficient
Rijndael

Byte Substitution
-a simple substitution of each byte
-uses one table of 16x16 bytes containing a permutation of all 256 8-bit values
-each byte of state is replaced by byte in row (left 4-bits) & column (right 4-bits)
-eg. byte {95} is replaced by row 9 col 5 byte
-which is the value {2A}
-S-box is constructed using a defined transformation of the values in GF(28)
-designed to be resistant to all known attacks
Shift Rows
-a circular byte shift in each each
-1st row is unchanged
-2nd row does 1 byte circular shift to left
-3rd row does 2 byte circular shift to left
-4th row does 3 byte circular shift to left
-decrypt does shifts to right
-since state is processed by columns, this step permutes bytes between the columns
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
Add Round Key

-XOR state with 128-bits of the round key
-again processed by column (though effectively a series of byte operations)
-inverse for decryption is identical since XOR is own inverse, just with correct round key
-designed to be as simple as possible

AES Round
AES Key Expansion

-takes 128-bit (16-byte) key and expands into array of 44/52/60 32-bit words
-start by copying key into first 4 words
-then loop creating words that depend on values in previous & 4 places back
-in 3 of 4 cases just XOR these together
-every 4th has S-box + rotate + XOR constant of previous before XOR together
-designed to resist known attacks
AES Decryption
-AES decryption is not identical to encryption since steps done in reverse
-but can define an equivalent inverse cipher with steps as for encryption
-but using inverses of each step
-with a different key schedule
-works since result is unchanged when
-swap byte substitution & shift rows
-swap mix columns & add (tweaked) round key
Implementation Aspects
-can efficiently implement on 8-bit CPU
-byte substitution works on bytes using a table of 256 entries
-shift rows is simple byte shifting
-add round key works on byte XORs
-mix columns requires matrix multiply in GF(28) which works on byte values, can be
simplified to use a table lookup
-can efficiently implement on 32-bit CPU
-redefine steps to use 32-bit words
-can precompute 4 tables of 256-words
-then each column in each round can be computed using 4 table lookups + 4 XORs
-at a cost of 16Kb to store tables
-designers believe this very efficient implementation was a key factor in its selection as the AES
cipher
The RC5 Encryption Algorithm

Characteristics of RC5
-RC5 encryption algorithm, developed by RON RIVEST

-RC5 is designed to have the following characteristics:
-Suitable for hardware or software
-Fast
-Adaptable to processor of different word length
-Variable number of rounds
-Variable-length key
-Simple
-Low memory requirement
-High security
-Data- dependent rotations
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 adaptable to processors of different word-lengths. For example, as 64-bit

processors become available, it should be possible for RC5 to exploit their longer word length.
Therefore, the number w of bits in a word is a parameter of RC5; different choices of this parameter
result in different RC5 algorithms.
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
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
RC5 is actually a family of encryption algorithms determined by three parameters as follows
Configurable parameters
word length w
number of rounds r
key size (bytes) b
Denoted as RC5-w/r/b
Key Expansion
Key table has t = 2(r +1) elements: S [0,1…. t]

S is generated using b byte key
Data Encryption

Data Encryption & Decryption

A Parameterized Family of Encryption Algorithms
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.
The RC5 Algorithm

In this section we describe the RC5 algorithm, which consists of three components: a key expansion
algorithm, an encryption algorithm, and a decryption algorithm. We present the encryption and
decryption algorithms first.
Recall that the plaintext input to RC5 consists of two w-bit words, which we denote A and B. Recall
also that RC5 uses an expanded key table, S[Q...t—1], consisting of t = 2(r+1) w-bit words. The key-
expansion algorithm initializes S from the user's given secret key parameter K. (We note that the S
table in RC5 encryption is not an "S-box" such as is used by DES; RC5 uses the entries in S
sequentially, one at a time.)
We assume standard little-endian conventions for packing bytes into input/output blocks: the first
byte occupies the low-order bit positions of register A, and so on, so that the fourth byte occupies the
high-order bit positions in A, the fifth byte occupies the low-order bit positions in B, and the eighth
(last) byte occupies the high-order bit positions in B.
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 Encryption Algorithm
The Blowfish Algorithm is designed by Bruce Schneier (1993)
Block cipher: 64-bit block
Variable key length: 32 bits to 448 bits
Much faster than DES and IDEA
No license required
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.
Decryption of the Algorithm
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.
1. The P-array consists of 18 32-bit sub keys:
P1, P2, P3, P4……………………………………… P18.
2. There are four 32-bit S-boxes with 256 entries each:

S1,0, S1,1,.…………….., S1,255;
S2,0, S2,1,…………….,, S2,255;
S3,0, S3,1,.………….., S3,255;
S40, S4,1,..,……….., S4,255.
Encryption:
Blowfish is a Feistel network consisting of 16 rounds

The input is a 64-bit data element, x Divide x into two 32-bit halves: xL, xR
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.
Generating the Sub keys:
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

2. XOR P1 with the first 32 bits of the key, XOR P2 with the second 32-bits of the key, and so on for
all bits of the key (possibly up to P14). P-array and K-array, reusing words from the K-array as
needed. For example for the maximum length key (14 32bit words) P1=P1 XOR k1, P2=P2 XOR
K2, P3=P3 XOR K3…………………………..P14=P14 XOR k14
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).
4. Replace P1 and P2 with the output of step (3).
5. Encrypt the output of step (3) using the Blowfish algorithm with the modified subkeys.
6. Replace P3 and P4 with the output of step (5).
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.

Design Decisions
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
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.
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.
The time-consuming subkey-generation process adds considerable complexity for a brute-force

attack. The subkeys are too long to be stored on a massive tape, so they would have to be generated
by a brute-force cracking machine as required. A total of 522 iterations of the encryption algorithm
are required to test a single key, effectively adding 29 steps to any brute-force attack.
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.
Possible Simplifications
I am exploring several possible simplifications, aimed at decreasing memory requirements and

execution time. These are outlined below:
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.

RC-2 Encryption Algorithm
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.
R[0] = R[0] + K[j] + (R[3] & R[2]) + ((~R[3] & R[1]);

R[0] = R[0] <<< 1;
j = j + 1;
R[1] = R[1] + K[j] + (R[0] & R[3]) + ((~R[0] & R[2]);
R[1] = R[1] <<< 2;
j = j + 1;
R[2] = R[2] + K[j] + (R[1] & R[0]) + ((~R[1] & R[3]);
R[2] = R[2] <<< 3;
j = j + 1;
R[3] = R[3] + K[j] + (R[2] & R[1]) + ((~R[2] & R[0]);
R[3] = R[3] <<< 5;
j = j + 1;
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.

CAST-128 Encryption Algorithm
Introduction
CAST, designed by Carlisle Adams and Stafford Taveres, is shaping up to be a solid

algorithm. Its design is very similar to Blowfish's, with key-dependent S-Boxes, a non-
invertible f function, and a Feistel network-like structure (called a substitution-permutation
network). David Wagner, John Kelsey, and Bruce Schneier have discovered a related-key
attack on the 64-bit version of CAST that requires approximately 217 chosen plaintexts, one
related query, and 248 offline computations.The attack is infeasible at best. CAST is patented
by Entrust Technologies, which has generously released it for free use. The CAST cipher
design process is described in this paper and the 128-bit version is described in this addendum.
Carlisle Adams has submitted a version of CAST (CAST-256) as an AES candidate.
CAST-128 is implemented in Kremlin.
CAST is used in IPSec.
64-bit block, 40- to 128-bit keys (in 8-bit increments)
Classical Feistel network structure
–Sixteen rounds
–Two subkeys per round, one 32-bit (Kmi), one 5-bit (Kri)
–Three different round functions
–Four operations: addition(+) and subtraction(-) modulo 232, XOR, and (variable)
circular left rotate (<<<)
–5-bit subkey (Kri) determines rotate amount.
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.
INPUT: plaintext m1...m64; key K = k1...k128.

OUTPUT: ciphertext c1...c64.
1. (key schedule) Compute 16 pairs of subkeys {Kmi, Kri} from K
2. (L0,R0) <-- (m1...m64). (Split the plaintext into left and

right 32-bit halves L0 = m1...m32 and R0 = m33...m64.)
3. (16 rounds) for i from 1 to 16, compute Li and Ri as follows:

Li = Ri-1;
Ri = Li-1 ^ f(Ri-1,Kmi,Kri), where f is defined (f is of Type 1, Type 2, or Type 3, depending
on i).
4. c1...c64 <-- (R16,L16). (Exchange final blocks L16, R16 and concatenate to form the
ciphertext.)

Decryption is identical to the encryption algorithm given above,except that the rounds (and
therefore the subkey pairs) are used in reverse order to compute (L0,R0) from (R16,L16).
Pairs of Round Keys
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.
Type 1: I = ((Kmi + D) <<< Kri)

f = ((S1[Ia] ^ S2[Ib]) - S3[Ic]) + S4[Id]
Type 2: I = ((Kmi ^ D) <<< Kri)

f = ((S1[Ia] - S2[Ib]) + S3[Ic]) ^ S4[Id]
Type 3: I = ((Kmi - D) <<< Kri)

f = ((S1[Ia] + S2[Ib]) ^ S3[Ic]) - S4[Id]
Rounds 1, 4, 7, 10, 13, and 16 use f function Type 1.

Rounds 2, 5, 8, 11, and 14 use f function Type 2.
Rounds 3, 6, 9, 12, and 15 use f function Type 3.
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 the 128-bit key be x0x1x2x3x4x5x6x7x8x9xAxBxCxDxExF, where x0 represents the

most significant byte and xF represents the least significant byte.
Let z0..zF be intermediate (temporary) bytes.

Let Si[] represent s-box i and let "^" represent XOR addition.
The subkeys are formed from the key x0x1x2x3x4x5x6x7x8x9xAxBxCxDxExF

as follows.
z0z1z2z3 = x0x1x2x3 ^ S5[xD] ^ S6[xF] ^ S7[xC] ^ S8[xE] ^ S7[x8]

z4z5z6z7 = x8x9xAxB ^ S5[z0] ^ S6[z2] ^ S7[z1] ^ S8[z3] ^ S8[xA]
z8z9zAzB = xCxDxExF ^ S5[z7] ^ S6[z6] ^ S7[z5] ^ S8[z4] ^ S5[x9]
zCzDzEzF = x4x5x6x7 ^ S5[zA] ^ S6[z9] ^ S7[zB] ^ S8[z8] ^ S6[xB]
K1 = S5[z8] ^ S6[z9] ^ S7[z7] ^ S8[z6] ^ S5[z2]
K2 = S5[zA] ^ S6[zB] ^ S7[z5] ^ S8[z4] ^ S6[z6]
K3 = S5[zC] ^ S6[zD] ^ S7[z3] ^ S8[z2] ^ S7[z9]
K4 = S5[zE] ^ S6[zF] ^ S7[z1] ^ S8[z0] ^ S8[zC]
x0x1x2x3 = z8z9zAzB ^ S5[z5] ^ S6[z7] ^ S7[z4] ^ S8[z6] ^ S7[z0]
x4x5x6x7 = z0z1z2z3 ^ S5[x0] ^ S6[x2] ^ S7[x1] ^ S8[x3] ^ S8[z2]
x8x9xAxB = z4z5z6z7 ^ S5[x7] ^ S6[x6] ^ S7[x5] ^ S8[x4] ^ S5[z1]
xCxDxExF = zCzDzEzF ^ S5[xA] ^ S6[x9] ^ S7[xB] ^ S8[x8] ^ S6[z3]
K5 = S5[x3] ^ S6[x2] ^ S7[xC] ^ S8[xD] ^ S5[x8]
K6 = S5[x1] ^ S6[x0] ^ S7[xE] ^ S8[xF] ^ S6[xD]
K7 = S5[x7] ^ S6[x6] ^ S7[x8] ^ S8[x9] ^ S7[x3]
K8 = S5[x5] ^ S6[x4] ^ S7[xA] ^ S8[xB] ^ S8[x7]
K9 = S5[z3] ^ S6[z2] ^ S7[zC] ^ S8[zD] ^ S5[z9]
K10 = S5[z1] ^ S6[z0] ^ S7[zE] ^ S8[zF] ^ S6[zC]
K11 = S5[z7] ^ S6[z6] ^ S7[z8] ^ S8[z9] ^ S7[z2]
K12 = S5[z5] ^ S6[z4] ^ S7[zA] ^ S8[zB] ^ S8[z6]
K13 = S5[x8] ^ S6[x9] ^ S7[x7] ^ S8[x6] ^ S5[x3]
K14 = S5[xA] ^ S6[xB] ^ S7[x5] ^ S8[x4] ^ S6[x7]
K15 = S5[xC] ^ S6[xD] ^ S7[x3] ^ S8[x2] ^ S7[x8]
K16 = S5[xE] ^ S6[xF] ^ S7[x1] ^ S8[x0] ^ S8[xD]
[The remaining half is identical to what is given above, carrying on

from the last created x0..xF to generate keys K17 - K32.]

K17 = S5[z8] ^ S6[z9] ^ S7[z7] ^ S8[z6] ^ S5[z2]
K18 = S5[zA] ^ S6[zB] ^ S7[z5] ^ S8[z4] ^ S6[z6]
K19 = S5[zC] ^ S6[zD] ^ S7[z3] ^ S8[z2] ^ S7[z9]
K20 = S5[zE] ^ S6[zF] ^ S7[z1] ^ S8[z0] ^ S8[zC]
K21 = S5[x3] ^ S6[x2] ^ S7[xC] ^ S8[xD] ^ S5[x8]
K22 = S5[x1] ^ S6[x0] ^ S7[xE] ^ S8[xF] ^ S6[xD]
K23 = S5[x7] ^ S6[x6] ^ S7[x8] ^ S8[x9] ^ S7[x3]
K24 = S5[x5] ^ S6[x4] ^ S7[xA] ^ S8[xB] ^ S8[x7]
K25 = S5[z3] ^ S6[z2] ^ S7[zC] ^ S8[zD] ^ S5[z9]
K26 = S5[z1] ^ S6[z0] ^ S7[zE] ^ S8[zF] ^ S6[zC]
K27 = S5[z7] ^ S6[z6] ^ S7[z8] ^ S8[z9] ^ S7[z2]
K28 = S5[z5] ^ S6[z4] ^ S7[zA] ^ S8[zB] ^ S8[z6]
K29 = S5[x8] ^ S6[x9] ^ S7[x7] ^ S8[x6] ^ S5[x3]
K30 = S5[xA] ^ S6[xB] ^ S7[x5] ^ S8[x4] ^ S6[x7]
K31 = S5[xC] ^ S6[xD] ^ S7[x3] ^ S8[x2] ^ S7[x8]
K32 = S5[xE] ^ S6[xF] ^ S7[x1] ^ S8[x0] ^ S8[xD]

Masking Subkeys And Rotate Subkeys
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.
for (i=1; i<=16; i++) { Kmi = Ki; Kri = K16+i; }
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.

International Data Encryption Algorithm (IDEA)
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
IDEA Basic Operations
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 Algorithm steps in single round
1. Multiply X1 with first Subkey

2. Add X2 with second subkey
3. Add X3 with third subkey
4. Multiply X4 with fourth subkey
5. XOR the results of step 1 and step 3
7. Multiply the results of step 5 with fifth subkey
8. Add the results of step 6 and step 7
9. Multiply the results of step 8 with sixth subkey
10. Add the results of step 7 and step 9

Data Encryption Standard (DES)
The DES Algorithm Illustrated
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.
It is recognized that encryption (otherwise known as scrambling, enciphering or privacy

transformation) represents the only means of protecting such data during transmission and a useful
means of protecting the content of data stored on various media, providing encryption of adequate
strength can be devised and validated and is inherently integrable into system architecture. The
National Bureau of Standards solicits proposed techniques and algorithms for computer data
encryption. The Bureau also solicits recommended techniques for implementing the cryptographic
function: for generating, evaluating, and protecting cryptographic keys; for maintaining files
encoded under expiring keys; for making partial updates to encrypted files; and mixed clear and
encrypted data to permit labelling, polling, routing, etc. The Bureau in its role for establishing
standards and aiding government and industry in assessing technology, will arrange for the
evaluation of protection methods in order to prepare guidelines.
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.
Some Preliminary Examples of DES
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).

For example, take the message "Your lips are smoother than vaseline". This plaintext message is 38
bytes (76 hexadecimal digits) long. So this message must be padded with some extra bytes at the tail
end for the encryption. Once the encrypted message has been decrypted, these extra bytes are thrown
away. There are, of course, different padding schemes--different ways to add extra bytes. Here we
will just add 0s at the end, so that the total message is a multiple of 8 bytes (or 16 hexadecimal
digits, or 64 bits).
The plaintext message "Your lips are smoother than vaseline" is, in hexadecimal,
"596F7572206C6970 732061726520736D 6F6F746865722074 68616E2076617365

6C696E650D0A".
(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:
"596F7572206C6970 732061726520736D 6F6F746865722074 68616E2076617365

6C696E650D0A0000".
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:
"C0999FDDE378D7ED 727DA00BCA5A84EE 47F269A4D6438190 9DD52F78F5358499

828AC9B453E0E653".
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!)
How DES Works in Detail
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.)
Example: Let M be the plain text message M = 0123456789ABCDEF, where M is in hexadecimal

(base 16) format. Rewriting M in binary format, we get the 64-bit block of text:
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.

DES operates on the 64-bit blocks using key sizes of 56- bits. The keys are actually stored as being
64 bits long, but every 8th bit in the key is not used (i.e. bits numbered 8, 16, 24, 32, 40, 48, 56, and
64). However, we will nevertheless number the bits from 1 to 64, going left to right, in the following
calculations. But, as you will see, the eight bits just mentioned get eliminated when we create
subkeys.
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):
K = 00010011 00110100 01010111 01111001 10011011 10111100 11011111 11110001
The DES algorithm uses the following steps:
Step 1: Create 16 subkeys, each of which is 48-bits long.
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
Example: From the original 64-bit key
K = 00010011 00110100 01010111 01111001 10011011 10111100 11011111 11110001
we get the 56-bit permutation
K+ = 1111000 0110011 0010101 0101111 0101010 1011001 1001111 0001111
Next, split this key into left and right halves, C0 and D0, where each half has 28 bits.
Example: From the permuted key K+, we get
C0 = 1111000 0110011 0010101 0101111

D0 = 0101010 1011001 1001111 0001111
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.
Example: From original pair pair C0 and D0 we obtain:
C0 = 1111000011001100101010101111
D0 = 0101010101100110011110001111
C1 = 1110000110011001010101011111
D1 = 1010101011001100111100011110
C2 = 1100001100110010101010111111
D2 = 0101010110011001111000111101
C3 = 0000110011001010101011111111
D3 = 0101011001100111100011110101

C4 = 0011001100101010101111111100
D4 = 0101100110011110001111010101
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
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
which, after we apply the permutation PC-2, becomes
K1 = 000110 110000 001011 101111 111111 000111 000001 110010
For the other keys we have
K2 = 011110 011010 111011 011001 110110 111100 100111 100101

K3 = 010101 011111 110010 001010 010000 101100 111110 011001
K4 = 011100 101010 110111 010110 110110 110011 010100 011101
K5 = 011111 001110 110000 000111 111010 110101 001110 101000
K6 = 011000 111010 010100 111110 010100 000111 101100 101111
K7 = 111011 001000 010010 110111 111101 100001 100010 111100
K8 = 111101 111000 101000 111010 110000 010011 101111 111011
K9 = 111000 001101 101111 101011 111011 011110 011110 000001
K10 = 101100 011111 001101 000111 101110 100100 011001 001111
K11 = 001000 010101 111111 010011 110111 101101 001110 000110
K12 = 011101 010111 000111 110101 100101 000110 011111 101001
K13 = 100101 111100 010111 010001 111110 101011 101001 000001
K14 = 010111 110100 001110 110111 111100 101110 011100 111010
K15 = 101111 111001 000110 001101 001111 010011 111100 001010
K16 = 110010 110011 110110 001011 000011 100001 011111 110101
So much for the subkeys. Now we look at the message itself.
Step 2: Encode each 64-bit block of data.
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.

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.
Example: From IP, we get L0 and R0
L0 = 1100 1100 0000 0000 1100 1100 1111 1111

R0 = 1111 0000 1010 1010 1111 0000 1010 1010
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 .
Example: For n = 1, we have
K1 = 000110 110000 001011 101111 111111 000111 000001 110010

L1 = R0 = 1111 0000 1010 1010 1111 0000 1010 1010
R1 = L0 + f(R0,K1)
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

call the use of this selection table the function E. Thus E(Rn-1) has a 32 bit input block, and a 48 bit
output block.
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.
Example: We calculate E(R0) from R0 as follows:
R0 = 1111 0000 1010 1010 1111 0000 1010 1010

E(R0) = 011110 100001 010101 010101 011110 100001 010101 010101
(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).
Example: For K1 , E(R0), we have
K1 = 000110 110000 001011 101111 111111 000111 000001 110010

E(R0) = 011110 100001 010101 010101 011110 100001 010101 010101
K1+E(R0) = 011000 010001 011110 111010 100001 100110 010100 100111.
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.
Write the previous result, which is 48 bits, in the form:

Kn + E(Rn-1) =B1B2B3B4B5B6B7B8,
where each Bi is a group of six bits. We now calculate
S1(B1)S2(B2)S3(B3)S4(B4)S5(B5)S6(B6)S7(B7)S8(B8)
where Si(Bi) referres to the output of the i-th S box.
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.
The tables defining the functions S1,...,S8 are the following:
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
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
Example: For the first round, we obtain as the output of the eight S boxes:
K1 + E(R0) = 011000 010001 011110 111010 100001 100110 010100 100111.
S1(B1)S2(B2)S3(B3)S4(B4)S5(B5)S6(B6)S7(B7)S8(B8) = 0101 1100 1000 0010 1011 0101 1001

0111
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
Example: From the output of the eight S boxes:
S1(B1)S2(B2)S3(B3)S4(B4)S5(B5)S6(B6)S7(B7)S8(B8) = 0101 1100 1000 0010 1011 0101 1001

0111
we get
f = 0010 0011 0100 1010 1010 1001 1011 1011
R1 = L0 + f(R0 , K1 )
= 1100 1100 0000 0000 1100 1100 1111 1111

+ 0010 0011 0100 1010 1010 1001 1011 1011
= 1110 1111 0100 1010 0110 0101 0100 0100
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

R16L16
and apply a final permutation IP-1 as defined by the following table:
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,
L16 = 0100 0011 0100 0010 0011 0010 0011 0100

R16 = 0000 1010 0100 1100 1101 1001 1001 0101
We reverse the order of these two blocks and apply the final permutation to
R16L16 = 00001010 01001100 11011001 10010101 01000011 01000010 00110010 00110100
IP-1 = 10000101 11101000 00010011 01010100 00001111 00001010 10110100 00000101
which in hexadecimal format is
85E813540F0AB405.
This is the encrypted form of M = 0123456789ABCDEF: namely, C = 85E813540F0AB405.
Decryption is simply the inverse of encryption, follwing the same steps as above, but reversing the
order in which the subkeys are applied.
DES Modes of Operation
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.
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).

Key Distribution
• 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

Key Management
• public-key encryption helps address key distribution problems

• have two aspects of this:
– distribution of public keys
– use of public-key encryption to distribute secret keys
Distribution of Public Keys
• can be considered as using one of:
– Public announcement
– Publicly available directory
– Public-key authority
– Public-key certificates
Public Announcement
• users distribute public keys to recipients or broadcast to community at large
– eg. append PGP keys to email messages or post to news groups or email list
• major weakness is forgery
– anyone can create a key claiming to be someone else and broadcast it
– until forgery is discovered can masquerade as claimed user
Publicly Available Directory

• can obtain greater security by registering keys with a public directory
• directory must be trusted with properties:
– contains {name,public-key} entries
– participants register securely with directory
– participants can replace key at any time
– directory is periodically published
– directory can be accessed electronically
• still vulnerable to tampering or forgery

Public-Key Authority
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

Public-Key Distribution of Secret Keys
• use previous methods to obtain public-key
• can use for secrecy or authentication
• but public-key algorithms are slow
• so usually want to use private-key encryption to protect message contents
• hence need a session key
• have several alternatives for negotiating a suitable session
Simple Secret Key Distribution
• proposed by Merkle in 1979
– A generates a new temporary public key pair
– A sends B the public key and their identity
– B generates a session key K sends it to A encrypted using the supplied public key
– A decrypts the session key and both use
• problem is that an opponent can intercept and impersonate both halves of protocol

Message Authentication
• message authentication is concerned with:
– protecting the integrity of a message
– validating identity of originator
– non-repudiation of origin (dispute resolution)
• will consider the security requirements
• then three functions used in construction:
– message encryption
– message authentication code (MAC)
– hash function
Security Requirements
• disclosure
• traffic analysis
• masquerade
• content modification
• sequence modification
• timing modification
• source repudiation
• destination repudiation
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
Message Authentication Code (MAC)

• generated by an algorithm that creates a small fixed-sized block
– depending on both message and some key
– like encryption though need not be reversible
• appended to message as a signature
• receiver performs same computation on message and checks it matches the MAC
• provides assurance that message is unaltered and comes from sender

• as shown the MAC provides authenticity
• can also use encryption for secrecy
– generally use separate keys for each
– can compute MAC either before or after encryption
– is generally regarded as better done before
• why use a MAC?
– sometimes only authentication is needed
– sometimes need authentication to persist longer than the encryption (eg. archival use)
• note that a MAC is not a digital signature
– what is the main difference?
MAC Properties
• a MAC is a cryptographic checksum
MAC = CK(M)
– condenses a variable-length message M
– using a secret key K
– to a fixed-sized authenticator
• is a many-to-one function
– potentially many messages have same MAC
– but finding these needs to be very difficult
Requirements for MACs
• taking into account the types of attacks
• need the MAC to satisfy the following:
1. knowing a message and MAC (but not secret K), is infeasible to find another message
with same MAC
2. MACs should be uniformly distributed
3. MAC should depend equally on all bits of the 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 Function Properties
• a Hash Function produces a fingerprint of some file/message/data
h = H(M)
– condenses a variable-length message M
– to a fixed-sized fingerprint
• assumed to be public
Requirements for Hash Functions
1. can be applied to any sized message M
2. produces fixed-length output h
3. is easy to compute h=H(M) for any message M
4. given h is infeasible to find x s.t. H(x)=h
• one-way property
5. given x is infeasible to find y s.t. H(y)=H(x)
• weak collision resistance
6. is infeasible to find any x,y s.t. H(y)=H(x)
• strong collision resistance
• Note that 6 => 5 => 4
Simple Hash Functions

• are several proposals for simple functions
• based on XOR of message blocks
• not secure since can manipulate any message and either not change hash or change hash also
• need a stronger cryptographic function (next chapter)
Hash Functions & MAC Security
• like block ciphers have:
• brute-force attacks exploiting
– strong collision resistance hash have cost 2m/2
• have proposal for h/w MD5 cracker
• 128-bit hash looks vulnerable, 160-bits better
– MACs with known message-MAC pairs
• can either attack keyspace (cf key search) or MAC
• at least 128-bit MAC is needed for security
• cryptanalytic attacks exploit structure
– like block ciphers want brute-force attacks to be the best alternative
• have a number of analytic attacks on iterated hash functions
– CVi = f[CVi-1, Mi]; H(M)=CVN
– typically focus on collisions in function f
– like block ciphers is often composed of rounds
– attacks exploit properties of round functions
Hash Algorithms
• see similarities in the evolution of hash functions & block ciphers

– increasing power of brute-force attacks
– leading to evolution in algorithms
– from DES to AES in block ciphers
– from MD4 & MD5 to SHA-1 & RIPEMD-160 in hash algorithms
• likewise tend to use common iterative structure as do block ciphers
MD5
• designed by Ronald Rivest (the R in RSA)
• latest in a series of MD2, MD4
• produces a 128-bit hash value
• until recently was the most widely used hash algorithm
– in recent times have both brute-force & cryptanalytic concerns
• specified as Internet standard RFC1321
Hash Function Structure

MD5 Overview
1. pad message so its length is 448 mod 512
2. append a 64-bit length value to message
3. initialise 4-word (128-bit) MD buffer (A,B,C,D)
4. process message in 16-word (512-bit) blocks:
– using 4 rounds of 16 bit operations on message block & buffer
– add output to buffer input to form new buffer value
5. output hash value is the final buffer value
MD5 Compression Function

• each round has 16 steps of the form:
a = b+((a+g(b,c,d)+X[k]+T[i])<<<s)
• a,b,c,d refer to the 4 words of the buffer, but used in varying permutations
– note this updates 1 word only of the buffer
– after 16 steps each word is updated 4 times
• where g(b,c,d) is a different nonlinear function in each round (F,G,H,I)
• T[i] is a constant value derived from sin

MD5 Compression Function
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

Secure Hash Algorithm (SHA-1)
• SHA was designed by NIST & NSA in 1993, revised 1995 as SHA-1
• US standard for use with DSA signature scheme
– standard is FIPS 180-1 1995, also Internet RFC3174
– nb. the algorithm is SHA, the standard is SHS
• produces 160-bit hash values
• now the generally preferred hash algorithm
• based on design of MD4 with key differences
SHA Overview
3. initialise 5-word (160-bit) buffer (A,B,C,D,E) to
67452301,efcdab89,98badcfe,10325476,c3d2e1f0)
1. process message in 16-word (512-bit) chunks:
– expand 16 words into 80 words by mixing & shifting
– use 4 rounds of 20 bit operations on message block & buffer
– add output to input to form new buffer value
SHA-1 Compression Function

• each round has 20 steps which replaces the 5 buffer words thus:
(A,B,C,D,E) <-(E+f(t,B,C,D)+(A<<5)+Wt+Kt),A,(B<<30),C,D)
• a,b,c,d refer to the 4 words of the buffer
• t is the step number
• f(t,B,C,D) is nonlinear function for round
• Wt is derived from the message block
• Kt is a constant value derived from sin

SHA-1 versus MD5
• brute force attack is harder (160 vs 128 bits for MD5)
• not vulnerable to any known attacks (compared to MD4/5)
• a little slower than MD5 (80 vs 64 steps)
• both designed as simple and compact
• optimised for big endian CPU's (vs MD5 which is optimised for little endian CPU’s)
Revised Secure Hash Standard
• NIST have issued a revision FIPS 180-2
• adds 3 additional hash algorithms
• SHA-256, SHA-384, SHA-512
• designed for compatibility with increased security provided by the AES cipher
• structure & detail is similar to SHA-1
• hence analysis should be similar
RIPEMD-160
• RIPEMD-160 was developed in Europe as part of RIPE project in 96

• by researchers involved in attacks on MD4/5
• initial proposal strengthen following analysis to become RIPEMD-160
• somewhat similar to MD5/SHA
• uses 2 parallel lines of 5 rounds of 16 steps
• creates a 160-bit hash value
• slower, but probably more secure, than SHA
RIPEMD-160 Overview
3. initialise 5-word (160-bit) buffer (A,B,C,D,E) to
(67452301,efcdab89,98badcfe,10325476,c3d2e1f0)
1. process message in 16-word (512-bit) chunks:
– use 10 rounds of 16 bit operations on message block & buffer – in 2 parallel lines of 5
– add output to input to form new buffer value

RIPEMD-160 Round
RIPEMD-160 Compression Function

RIPEMD-160 Design Criteria
• use 2 parallel lines of 5 rounds for increased complexity
• for simplicity the 2 lines are very similar
• step operation very close to MD5
• permutation varies parts of message used
• circular shifts designed for best results
RIPEMD-160 verses MD5 & SHA-1
• brute force attack harder (160 like SHA-1 vs 128 bits for MD5)
• not vulnerable to known attacks, like SHA-1 though stronger (compared to MD4/5)
• slower than MD5 (more steps)
• all designed as simple and compact
• SHA-1 optimised for big endian CPU's vs RIPEMD-160 & MD5 optimised for little endian
CPU’s
Keyed Hash Functions as MACs
• have desire to create a MAC using a hash function rather than a block cipher
– because hash functions are generally faster
– not limited by export controls unlike block ciphers
• hash includes a key along with the message
• original proposal:
KeyedHash = Hash(Key|Message)
– extension attack
• eventually led to development of HMAC
HMAC
• specified as Internet standard RFC2104
• uses hash function on the message:
HMACK = Hash[(K+ XOR opad) ||
Hash[(K+ XOR ipad)||M)]]
• where K+ is the key padded out to size
• and opad, ipad are specified padding constants
• overhead is just 3 more hash iterations than the message needs alone
• any of MD5, SHA-1, RIPEMD-160 can be used

HMAC Overview
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

Private-Key Cryptography
• traditional private/secret/single key cryptography uses one key

• shared by both sender and receiver
• if this key is disclosed communications are compromised
• also is symmetric, parties are equal
• hence does not protect sender from receiver forging a message & claiming is sent by sender
• or prevent an actual sender from denying it sent the message (repudiating)
Public-Key Cryptography
• probably most significant advance in the 3000 year history of cryptography
• uses two keys – a public & a private key
• asymmetric since parties are not equal
• uses clever application of number theoretic concepts
• complements rather than replaces secret key crypto
• public-key/two-key/asymmetric cryptography involves the use of two keys:
• a public-key, which may be known by anybody, and can be used to encrypt
messages, and verify signatures
• a private-key, known only to the recipient, used to decrypt messages, and sign
(create) signatures
• is asymmetric because
• those who encrypt messages or verify signatures cannot decrypt messages or create
signatures
Why Public-Key Cryptography?
• developed to address two key issues:
– key distribution – how to have secure communications in general without having to
trust a KDC with your key
– digital signatures – how to verify a message comes intact from the claimed sender
• public invention due to Whitfield Diffie & Martin Hellman at Stanford in 1976
– known earlier in classified community
Public-Key Characteristics
• Public-Key algorithms rely on two keys with the characteristics that it is:
– computationally infeasible to find decryption key knowing only algorithm &
encryption key
– computationally easy to en/decrypt messages when the relevant (en/decrypt) key is
known
– either of the two related keys can be used for encryption, with the other used for
decryption (in some schemes)
Public-Key Applications
• can classify uses into 3 categories:
– encryption/decryption (provide secrecy)
– digital signatures (provide authentication)
– key exchange (of session keys)
• some algorithms are suitable for all uses, others are specific to one
Security of Public Key Schemes
• like private key schemes brute force exhaustive search attack is always theoretically
possible
• but keys used are too large (>512 bits)
– not comparable to symmetric key sizes
• security relies on a large enough difference in difficulty between easy (en/decrypt) and hard
(to cryptanalyze) problems
• more generally the hard problem is known, its just made too hard to do in practice
• requires the use of very large numbers
• hence is slow compared to secret key schemes
RSA
• by Rivest, Shamir & Adleman of MIT in 1977
– patent expired in September 2000
• best known & widely used public-key scheme
• based on modular exponentiation
– exponentiation takes O((log n)3) bit operations (easy)
– still, 1000 times slower than DES (hardware); 100 times slower in software
• uses large integers (eg. 1024 bits)
• security due to cost of factoring large numbers
– nb. factorization takes O(e log n log log n) operations (hard)
RSA Key Setup
• each user generates a public/private key pair by:
• selecting two large primes at random - p, q
• computing their system modulus N=pq
– note ø(N)=(p-1)(q-1)
• selecting the encryption key e
• where 1<e<ø(N), gcd(e,ø(N))=1
• solve following equation to find decryption key d
– ed=1 mod ø(N) and 0≤d≤N
• publish their public encryption key: KU={e,N}
• keep secret private decryption key: KR={d,p,q}
RSA Use
• to encrypt a message M the sender:
– obtains public key of recipient KU={e,N}
– computes: C=Me mod N, where 0≤M<N
• to decrypt the ciphertext C the owner:
– uses their private key KR={d,p,q}
– computes: M=Cd mod N
• note that the message M must be smaller than the modulus N (block if needed)
Why RSA Works
• because of Euler's Theorem:
• aø(n)mod N = 1
– where gcd(a,N)=1
• in RSA have:
– N=pq
– ø(N)=(p-1)(q-1)
– carefully chosen e & d to be inverses mod ø(N)
– hence ed=1+kø(N) for some k
• hence :
Cd = (Me)d = M1+kø(N) = M1(Mø(N))k = M1(1)k = M1 = M mod N

RSA Example
1. Select primes: p=17 & q=11
2. Compute n = pq =17×11=187
3. Compute ø(n)=(p–1)(q-1)=16×10=160
4. Select e : gcd(e,160)=1; choose e=7
5. Determine d: de=1 mod 160 and d < 160 Value is d=23 since 23×7=161= 10×160+1
6. Publish public key KU={7,187}
7. Keep secret private key KR={23,17,11}
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

Authentication
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
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)
DSA Signature Creation

• to sign a message M the sender:
– generates a random signature key k, k<q
– nb. k must be random, be destroyed after use, and never be reused
• then computes signature pair:
r = (gk(mod p))(mod q)
s = (k-1.SHA(M)+ x.r)(mod q)
• sends signature (r,s) with message M
DSA Signature Verification
• having received M & signature (r,s)
• to verify a signature, recipient computes:
w = s-1(mod q)
u1= (SHA(M).w)(mod q)
u2= (r.w)(mod q)
v = (gu1.yu2(mod p)) (mod q)
• if v=r then signature is verified
• see book web site for details of proof why

Email Security
• email is one of the most widely used and regarded network services
• currently message contents are not secure
– may be inspected either in transit
– or by suitably privileged users on destination system
Email Security Enhancements
• confidentiality
– protection from disclosure
• authentication
– of sender of message
• message integrity
– protection from modification
• non-repudiation of origin
– protection from denial by sender
Pretty Good Privacy (PGP)
• Philip R. Zimmerman is the creator of PGP.
• PGP provides a confidentiality and authentication service that can be used for electronic mail
and file storage applications.
Why Is PGP Popular?

• It is availiable free on a variety of platforms.
• Based on well known algorithms.
• Wide range of applicability
• Not developed or controlled by governmental or standards organizations
Operational Description
• Consist of five services:
– Authentication
– Confidentiality
– Compression
– E-mail compatibility
– Segmentation
PGP Operation – Authentication

1. sender creates a message
2. SHA-1 used to generate 160-bit hash code of message
3. hash code is encrypted with RSA using the sender's private key, and result is attached to
message
4. receiver uses RSA or DSS with sender's public key to decrypt and recover hash code
5. receiver generates new hash code for message and compares with decrypted hash code, if
match, message is accepted as authentic
PGP Operation – Confidentiality
1. sender generates message and random 128-bit number to be used as session key for this
message only
2. message is encrypted, using CAST-128 / IDEA/3DES with session key
3. session key is encrypted using RSA with recipient's public key, then attached to message
4. receiver uses RSA with its private key to decrypt and recover session key
5. session key is used to decrypt message
PGP Operation – Confidentiality & Authentication

• uses both services on same message
– create signature & attach to message
– encrypt both message & signature
– attach RSA encrypted session key
PGP Operation – Compression
• by default PGP compresses message after signing but before encrypting
– so can store uncompressed message & signature for later verification
– & because compression is non deterministic
• uses ZIP compression algorithm
PGP Operation – Email Compatibility
• when using PGP will have binary data to send (encrypted message etc)
• however email was designed only for text
• hence PGP must encode raw binary data into printable ASCII characters
• uses radix-64 algorithm
– maps 3 bytes to 4 printable chars
– also appends a CRC
• PGP also segments messages if too big
PGP Operation – Summary

Compression
• PGP compresses the message after applying the signature but before encryption
• The placement of the compression algorithm is critical.
• The compression algorithm used is ZIP (described in appendix 5A)
E-mail Compatibility
• The scheme used is radix-64 conversion (see appendix 5B).
• The use of radix-64 expands the message by 33%.

Segmentation and Reassembly
• Often restricted to a maximum message length of 50,000 octets.
• Longer messages must be broken up into segments.
• PGP automatically subdivides a message that is to large.
• The receiver strip of all e-mail headers and reassemble the block.
Sumary of PGP Services
Function Algorithm Used

Digital Signature DSS/SHA or
RSA/SHA
Message CAST or IDEA or
Encryption three-key triple DES
with Diffie-Hellman
or RSA
Compression ZIP
E-mail Radix-64 conversion
Compatibility
Segmentation -

PGP Session Keys
• need a session key for each message
– of varying sizes: 56-bit DES, 128-bit CAST or IDEA, 168-bit Triple-DES
• generated using ANSI X12.17 mode
• uses random inputs taken from previous uses and from keystroke timing of user
PGP Public & Private Keys
• since many public/private keys may be in use, need to identify which is actually used to
encrypt session key in a message
– could send full public-key with every message
– but this is inefficient
• rather use a key identifier based on key
– is least significant 64-bits of the key
– will very likely be unique
• also use key ID in signatures
PGP Key Management

• rather than relying on certificate authorities
• in PGP every user is own CA
– can sign keys for users they know directly
• forms a “web of trust”
– trust keys have signed
– can trust keys others have signed if have a chain of signatures to them
• key ring includes trust indicators
• users can also revoke their keys
Format of PGP Message

S/MIME
• Secure/Multipurpose Internet Mail Extension
• S/MIME will probably emerge as the industry standard.
• PGP for personal e-mail security
Simple Mail Transfer Protocol (SMTP, RFC 822)
• SMTP Limitations - Can not transmit, or has a problem with:
– executable files, or other binary files (jpeg image)
– “national language” characters (non-ASCII)
– messages over a certain size
– ASCII to EBCDIC translation problems
– lines longer than a certain length (72 to 254 characters)
Header fields in MIME
• MIME-Version: Must be “1.0” -> RFC 2045, RFC 2046
• Content-Type: More types being added by developers (application/word)
• Content-Transfer-Encoding: How message has been encoded (radix-64)
• Content-ID: Unique identifying character string.
• Content Description: Needed when content is not readable text (e.g.,mpeg)
S/MIME Functions
• Enveloped Data: Encrypted content and encrypted session keys for recipients.
• Signed Data: Message Digest encrypted with private key of “signer.”
• Clear-Signed Data: Signed but not encrypted.
• Signed and Enveloped Data: Various orderings for encrypting and signing.
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).
User Agent Role

• S/MIME uses Public-Key Certificates - X.509 version 3 signed by Certification Authority
• Functions:
– Key Generation - Diffie-Hellman, DSS, and RSA key-pairs.
– Registration - Public keys must be registered with X.509 CA.
– Certificate Storage - Local (as in browser application) for different services.
– Signed and Enveloped Data - Various orderings for encrypting and signing.
• Example: Verisign (www.verisign.com)

Class-1: Buyer’s email address confirmed by emailing vital info.
Class-2: Postal address is confirmed as well, and data checked against directories.
Class-3: Buyer must appear in person, or send notarized documents.
Security Concerns
• key concerns are confidentiality and timeliness
• to provide confidentiality must encrypt identification and session key info
• which requires the use of previously shared private or public keys
• need timeliness to prevent replay attacks
• provided by using sequence numbers or timestamps or challenge/response
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
A Simple Authentication Dialogue

(1) C AS: IDc || Pc || IDv
(2) AS C: Ticket
(3) C V: IDc || Ticket
Ticket = EKv[IDc || Pc || IDv]

Version 4 Authentication Dialogue
• Problems:
– Lifetime associated with the ticket-granting ticket
– If too short repeatedly asked for password
– If too long greater opportunity to replay
• The threat is that an opponent will steal the ticket and use it before it expires
Version 4 Authentication Dialogue
Authentication Service Exhange: To obtain Ticket-Granting Ticket
(1) C AS: IDc || IDtgs ||TS1
(2) AS C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]
Ticket-Granting Service Echange: To obtain Service-Granting Ticket

(3) C TGS: IDv ||Tickettgs ||Authenticatorc
(4) TGS C: EKc [Kc,¨v|| IDv || TS4 || Ticketv]
Client/Server Authentication Exhange: To Obtain Service

(5) C V: Ticketv || Authenticatorc
(6) V C: EKc,v[TS5 +1]
Overview of Kerberos

Request for Service in Another Realm
Difference Between Version 4 and 5

• Encryption system dependence (V.4 DES)
• Internet protocol dependence
• Message byte ordering
• Ticket lifetime
• Authentication forwarding
• Interrealm authentication

Kerberos Encryption Techniques
Kerberos - in practice
• Currently have two Kerberos versions:

• 4 : restricted to a single realm
• 5 : allows inter-realm authentication, in beta test
• Kerberos v5 is an Internet standard
• specified in RFC1510, and used by many utilities
• To use Kerberos:
• need to have a KDC on your network
• need to have Kerberised applications running on all participating systems
• major problem - US export restrictions
• Kerberos cannot be directly distributed outside the US in source format (& binary versions
must obscure crypto routine entry points and have no encryption)
• else crypto libraries must be reimplemented locally
X.509 Authentication Service

• Distributed set of servers that maintains a database about users.
• Each certificate contains the public key of a user and is signed with the private key of a CA.
• Is used in S/MIME, IP Security, SSL/TLS and SET.
• RSA is recommended to use.
X.509 Formats

Obtaining a User’s Certificate
• Characteristics of certificates generated by CA:
– Any user with access to the public key of the CA can recover the user public key that
was certified.
– No part other than the CA can modify the certificate without this being detected.
Revocation of Certificates
• Reasons for revocation:
– The users secret key is assumed to be compromised.
– The user is no longer certified by this CA.
– The CA’s certificate is assumed to be compromised.
Authentication Procedures

IP Security
• Internetworking and Internet Protocols

• IP Security Overview
• IP Security Architecture
• Authentication Header
• Encapsulating Security Payload
• Combinations of Security Associations
• Key Management
TCP/IP Example

IPv4 Header
IPv6 Header

IP Security Overview
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

IP Security Architecture
• IPSec documents:
– RFC 2401: An overview of security architecture
– RFC 2402: Description of a packet encryption extension to IPv4 and IPv6
– RFC 2406: Description of a packet emcryption extension to IPv4 and IPv6
– RFC 2408: Specification of key managament capabilities
IPSec Document Overview
IPSec Services
• Access Control
• Connectionless integrity
• Data origin authentication
• Rejection of replayed packets
• Confidentiality (encryption)
• Limited traffic flow confidentiallity
Security Associations (SA)

• A one way relationsship between a sender and a receiver.
• Identified by three parameters:
– Security Parameter Index (SPI)
– IP Destination address
– Security Protocol Identifier

Authentication Header
• Provides support for data integrity and authentication (MAC code) of IP packets.
• Guards against replay attacks.
Encapsulating Security Payload

Encryption and Authentication Algorithms
• Encryption:
– Three-key triple DES
– RC5
– IDEA
– Three-key triple IDEA
– CAST
– Blowfish
• Authentication:
– HMAC-MD5-96
– HMAC-SHA-1-96
Key Management
• Two types:
– Manual
– Automated
• Oakley Key Determination Protocol
• Internet Security Association and Key Management Protocol (ISAKMP)
Oakley
• a key exchange protocol
• based on Diffie-Hellman key exchange
• adds features to address weaknesses
– cookies, groups (global params), nonces, DH key exchange with authentication
• can use arithmetic in prime fields or elliptic curve fields
• Three authentication methods:
– Digital signatures
– Public-key encryption
– Symmetric-key encryption
ISAKMP
• Internet Security Association and Key Management Protocol
• provides framework for key management
• defines procedures and packet formats to establish, negotiate, modify, & delete SAs
• independent of key exchange protocol, encryption alg, & authentication method

Web Security
• Web Security Considerations

• Secure Socket Layer (SSL) and Transport Layer Security (TLS)
• Secure Electronic Transaction (SET)
Web Security Considerations
• The WEB is very visible.
• Complex software hide many security flaws.
• Web servers are easy to configure and manage.
• Users are not aware of the risks.
Security facilities in the TCP/IP protocol stack
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
SSL Record Protocol Operation

• confidentiality
– using symmetric encryption with a shared secret key defined by Handshake Protocol
– IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128
– message is compressed before encryption
• message integrity
– using a MAC with shared secret key
– similar to HMAC but with different padding
• https
– “use security” bit
– server authenticated, client not (typically)
SSL Record Format
SSL Change Cipher Spec Protocol
• 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
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
Transport Layer Security

• The same record format as the SSL record format.
• Defined in RFC 2246.
• Similar to SSLv3.
• Differences in the:
– version number
– message authentication code
– pseudorandom function
– alert codes
– cipher suites
– client certificate types
– certificate_verify and finished message
– cryptographic computations
– padding
– in record format version number
– uses HMAC for MAC
– a pseudo-random function expands secrets
– has additional alert codes
– some changes in supported ciphers
– changes in certificate negotiations
– changes in use of padding
Secure Electronic Transactions (SET)
• An open encryption and security specification.

• Protect credit card transaction on the Internet.
• Companies involved:
– MasterCard, Visa, IBM, Microsoft, Netscape, RSA, Terisa and Verisign
• Not a payment system.
• Set of security protocols and formats.
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
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
Purchase Request – Customer
Cardholder sends Purchase Request
Cardholder sends Purchase Request
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
Payment Gateway Authorization

1. verifies all certificates
2. decrypts digital envelope of authorization block to obtain symmetric key & then decrypts
authorization block
3. verifies merchant's signature on authorization block
4. decrypts digital envelope of payment block to obtain symmetric key & then decrypts
payment block
5. verifies dual signature on payment block
6. verifies that transaction ID received from merchant matches that in PI received (indirectly)
from customer
7. requests & receives an authorization from issuer
8. sends authorization response back to merchant
Payment Capture
• merchant sends payment gateway a payment capture request
• gateway checks request
• then causes funds to be transferred to merchants account
• notifies merchant using capture response
Network Management Security(SNMP)
• Basic Concepts of SNMP

• SNMPv1 Community Facility
• SNMPv3
• Recommended Reading and WEB Sites
Basic Concepts of SNMP

• An integrated collection of tools for network monitoring and control.
– Single operator interface
– Minimal amount of separate equipment. Software and network communications
capability built into the existing equipment
• SNMP key elements:
– Management station
– Managament agent
– Management information base
– Network Management protocol
• Get, Set and Notify
Protocol context of SNMP
Proxy Configuration
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.
Comparison of SNMPv1 and SNMPv2
SNMPv1 PDU SNMPv2 PDU Direction Description

GetRequest GetRequest Manager to agent Request value for
each listed object
GetRequest GetRequest Manager to agent Request next value
for each listed
object
------ GetBulkRequest Manager to agent Request multiple
values
SetRequest SetRequest Manager to agent Set value for each
listed object
------ 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
SNMPv1 Community Facility

• SNMP Community – Relationship between an SNMP agent and SNMP managers.
• Three aspect of agent control:
– Authentication service
– Access policy
– Proxy service
SNMPv1 Administrative Concepts
SNMPv3
• SNMPv3 defines a security capability to be used in conjunction with SNMPv1 or v2
Traditional SNMP Manager
SNMP3 Message Format with USM
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
View-Based Access Control Model (VACM)

• VACM has two characteristics:
– Determines wheter access to a managed object should be allowed.
– Make use of an MIB that:
• Defines the access control policy for this agent.
• Makes it possible for remote configuration to be used.
Access control decision
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.
Prevention: Enforce good password selection (Ij4Gf4Se%f#)

UNIX Password Scheme
UNIX Password Scheme
Storing UNIX Passwords

• UNIX passwords were kept in in a publicly readable file, etc/passwords.
• Now they are kept in a “shadow” directory and only visible by “root”.
”Salt”
• The salt serves three purposes:
– Prevents duplicate passwords.
– Effectively increases the length of the password.
– Prevents the use of hardware implementations of DES
Password Selecting Strategies

• User ducation
• Computer-generated passwords
• Reactive password checking
• Proactive password checking
Proactive Password Checking
• most promising approach to improving password security
• allow users to select own password
• but have system verify it is acceptable
– simple rule enforcement (see previous slide)
– compare against dictionary of bad passwords
– use algorithmic (markov model or bloom filter) to detect poor choices
Password Guessing
• one of the most common attacks
• attacker knows a login (from email/web page etc)
• then attempts to guess password for it
– try default passwords shipped with systems
– try all short passwords
– then try by searching dictionaries of common words
– intelligent searches try passwords associated with the user (variations on names,
birthday, phone, common words/interests)
– before exhaustively searching all possible passwords
• check by login attempt or against stolen password file
• success depends on password chosen by user
• surveys show many users choose poorly
Password Capture
• another attack involves password capture
– watching over shoulder as password is entered
– using a trojan horse program to collect
– monitoring an insecure network login (eg. telnet, FTP, web, email)
– extracting recorded info after successful login (web history/cache, last number dialed
etc)
• using valid login/password can impersonate user
• users need to be educated to use suitable precautions/countermeasures
Intrusion Detection
• inevitably will have security failures
• so need also to detect intrusions so can
– block if detected quickly
– act as deterrent
– collect info to improve security
• assume intruder will behave differently to a legitimate user
– but will have imperfect distinction between
Approaches to Intrusion Detection
• statistical anomaly detection
– threshold
– profile based
• rule-based detection
– anomaly
– penetration identification
Audit Records
• fundamental tool for intrusion detection
• native audit records
– part of all common multi-user O/S
– already present for use
– may not have info wanted in desired form
• detection-specific audit records
– created specifically to collect wanted info
– at cost of additional overhead on system
Statistical Anomaly Detection
• threshold detection
– count occurrences of specific event over time
– if exceed reasonable value assume intrusion
– alone is a crude & ineffective detector
• profile based
– characterize past behavior of users
– detect significant deviations from this
– profile usually multi-parameter
Audit Record Analysis
• foundation of statistical approaches
• analyze records to get metrics over time
– counter, gauge, interval timer, resource use
• use various tests on these to determine if current behavior is acceptable
– mean & standard deviation, multivariate, markov process, time series, operational
• key advantage is no prior knowledge used
Rule-Based Intrusion Detection
• observe events on system & apply rules to decide if activity is suspicious or not
• rule-based anomaly detection
– analyze historical audit records to identify usage patterns & auto-generate rules for
them
– then observe current behavior & match against rules to see if conforms
– like statistical anomaly detection does not require prior knowledge of security flaws
• rule-based penetration identification
– uses expert systems technology
– with rules identifying known penetration, weakness patterns, or suspicious behavior
– rules usually machine & O/S specific
– rules are generated by experts who interview & codify knowledge of security admins
– quality depends on how well this is done
– compare audit records or states against rules
Distributed Intrusion Detection
• traditional focus is on single systems
• but typically have networked systems
• more effective defense has these working together to detect intrusions
• issues
– dealing with varying audit record formats
– integrity & confidentiality of networked data
– centralized or decentralized architecture
Distributed Intrusion Detection – Architecture
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
• 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).
Taxanomy of Malicious Programs
• Virus - code that copies itself into other programs.

• A “Bacteria” replicates until it fills all disk space, or CPU cycles.
• Payload - harmful things the malicious program does, after it has had time to spread.
• Worm - a program that replicates itself across the network (usually riding on email messages
or attached documents (e.g., macro viruses).
• Trojan Horse - instructions in an otherwise good program that cause bad things to happen
(sending your data or password to an attacker over the net).
• Logic Bomb - malicious code that activates on an event (e.g., date).
• Trap Door (or Back Door) - undocumented entry point written into code for debugging that
can allow unwanted users.
• Easter Egg - extraneous code that does something “cool.” A way for programmers to show
that they control the product.
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).
• Stealth Virus - explicitly designed to hide from Virus Scanning programs.
• Polymorphic Virus - mutates with every new host to prevent signature detection.
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.
Advanced Antivirus Techniques

• Generic Decryption (GD)
– CPU Emulator
– Virus Signature Scanner
– Emulation Control Module
• For how long should a GD scanner run each interpretation?
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
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
• Firewall Design Principles

– Firewall Characteristics
– Types of Firewalls
– Firewall Configurations
• Trusted Systems
– Data Access Control
– The Concept of Trusted systems
– Trojan Horse Defense
• Effective means of protection a local system or network of systems from network-based
security threats while affording access to the outside world via WAN`s or the Internet
Firewall Design Principles
• 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
– 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
• Possible attacks and appropriate countermeasures

– IP address spoofing
– Source routing attacks
– Tiny fragment attacks
Application-level
Gateway
• 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
• 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
Data Access Control

• Through the user access control procedure (log on), a user can be identified to the system
• Associated with each user, there can be a profile that specifies permissible operations and file
accesses
• The operation system can enforce rules based on the user profile
• General models of access control:
• Access matrix
• Access control list
• Capability list
Access Matrix
• 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
The Concept of Trusted Systems

• Multilevel security
– Definition of multiple categories or levels of data
• A multilevel secure system must enforce:
– No read up: A subject can only read an object of less or equal security level (Simple
Security Property)
– No write down: A subject can only write into an object of greater or equal security
level (*-Property)
• Reference Monitor Concept: Multilevel security for a data processing system
• 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
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.
Right now, you might be asking:
"How does this work?"

"Is my network susceptible to this?"
"What can I do to prevent this from happening?"
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.
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.
Figure 1 TCP Three-Way Handshake
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.
Figure 2 Sending Data over TCP
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
attacker. If the attacker wanted to inject data into the TCP session as the client, he or she would need
to:
Spoof the client's IP address

Determine the correct sequence number that is expected by the server from the client
Inject data into the session before the client sends its next packet
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.
Figure 3 Blind Injection
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.
Hijacking a UDP Session

Hijacking a session over a User Datagram Protocol (UDP) is exactly the same as over TCP, except
that UDP attackers do not have to worry about the overhead of managing sequence numbers and
other TCP mechanisms. Since UDP is connectionless, injecting data into a session without being
detected is extremely easy. Figure 4 shows how an attacker could do this.
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.
Tricks and Techniques

Successfully hijacking a network session depends on a few conditions falling into place, so an
attacker has several tricks and techniques for creating these conditions. For instance, to conduct a
true MITM attack, the attacker must get hosts to route traffic through him or her. To make this
happen, he or she can use tricks with Internet Control Message Protocol (ICMP) Redirect packets or
ARP spoofing.
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.
TCP ACK Packet Storms

If an attacker is not careful when hijacking TCP sessions in your organization's networks, those
networks can be disrupted by TCP ACK packet storms.
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.
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.
ARP Table Modifications

The address resolution protocol is used by each host on an IP network to map local IP addresses to
hardware addresses or MAC addresses. Here is a quick look at how this protocol works.
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.
Figure 6 Finding the Owner of a MAC Address

Can you see the security problem here? Does Host A know that Host B really did send the ARP
reply? The answer is no, and attackers take advantage of this. In our example, attackers could spoof
an ARP reply to Host A before Host B responded, indicating that the hardware address
E0:E0:E0:E0:E0:E0 corresponds to Host B's IP address, as shown in Figure 7. Host A would then
send any traffic intended for Host B to the attacker, and the attacker could choose to forward that
data (probably after some tampering) to Host B.
Figure 7 Spoofed Reply
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.
Figure 8 Stopping a TCP ACK Storm

Information Security

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Security

Uploaded by

Copyright:

Available Formats

Information Security

Attacks, services and mechanisms

A model for Internet work Security

Attacks, Services and Mechanisms

Security Attack: Any action that compromises the security of information.

Interruption: This is an attack on availability

Interception: This is an attack on confidentiality

Modification: This is an attack on integrity

Fabrication: This is an attack on authenticity

Authentication (who created or sent the data)

Integrity (has not been altered)

Non-repudiation (the order is final)

Access control (prevent misuse of resources)

Availability (permanence, non-erasure)

Denial of Service Attacks

Virus that deletes files

Security Services (X.800)

X.800 defines it in 5 major categories

Authentication - assurance that the communicating entity is the one claimed.

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 2

Specific security mechanisms:

Pervasive security mechanisms:

A Model for Internet work security

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 3

Plaintext: The original intelligible message.

Types of Cryptanalytic Attacks

Have several different types of attacks

Only have access to some enciphered messages

Use statistical attacks only

Know (or strongly suspect) some plaintext-ciphertext pairs

Use this knowledge in attacking cipher

Can select plaintext and obtain corresponding ciphertext.

Use knowledge of algorithm structure in attack.

Allows further knowledge of algorithm structure to be used.

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 4

Two fundamentally different ways ciphers may be secure

Brute Force Search

Always possible to simply try every key.

Simplified Data Encryption Standard (S-DES)

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 6

Stream Ciphers and Block Ciphers

Feistel Cipher Structure

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 7

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 8

Data Encryption Standard (DES)

-First step of the data computation

DES Round Structure

-uses two 32-bit L & R halves

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 11

-have eight S-boxes, each maps 6 to 4 bits

DES Key Schedule

-forms subkeys used in each round

-key desirable property of encryption alg

Strength of DES – Key Size

-56-bit keys have 256 = 7.2 x 1016 values

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 12

-attacks actual implementation of cipher

Strength of DES – Analytic Attacks

-now have several analytic attacks on DES

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 13

Electronic Codebook Mode (ECB)

-message is broken into independent blocks which are encrypted

G Sanjiv Rao Associate Professor Sai Aditya Engineering College Surampalem 14