© 2001 Fotis Fotopoulos Boston - t-gr.com · decoding program (like ... consider the case where...

Applied Cryptography

© 2001 Fotis Fotopoulos

Boston

1

Contents

Table Of Contents 1. Introduction To Applied Cryptography................................................. 3 2. Lossless compression .......................................................................... 5

2.1 Shannon-Fano model ............................................................................. 5 2.1.1 Overview......................................................................................... 6 2.1.2 Variable Length Representations......................................................... 7 2.1.3 Huffman Algorithm ........................................................................... 8

2.2 Dictionary Based Compressors................................................................10 2.2.1 Overview........................................................................................11 2.2.2 LZ Algorithm...................................................................................11 2.2.3 Example.........................................................................................12 2.2.4 Variants .........................................................................................13

3. General .............................................................................................. 15 3.1 JPEG ...................................................................................................15 3.2 MP3 ....................................................................................................16

3.2.1 Overview........................................................................................16 3.2.2 The Concept ...................................................................................17 3.2.3 The Hybrid Filter Bank......................................................................18 3.2.3 The Psychoacoustic Model.................................................................19 3.2.4 Bit Allocation ..................................................................................19

4. Credit Cards ....................................................................................... 21 4.1 LUHN Algorithm....................................................................................21 4.2 Example ..............................................................................................22 4.3 Javascript Code ....................................................................................22

Cover page: An encryption masterpiece: 3 cloud pictures, a tree layer, 3 watermarks and a 256 bytes text information (hidden with steganography technique).

2

Chapter 1: Introduction

Introduction 1

1. Introduction To Applied Cryptography These notes are for the “Applied Cryptography” lecture given during Splash Fall 2001 at MIT. Although I’ve spent a lot of time composing them and making sure of their accuracy, no guaranteed can be given or even implied on their context. I hope that the students and all those interested in cryptography will find them useful. Cryptography is everywhere; it’s actually the basis on which computers operate. Some familiar applications of cryptography is the data compression and the media encryption. Sciences like programming and steganography are based on cryptographic techniques. Cryptography should not be confused with security. An encrypted algorithm is secure only if unauthorized users cannot view the encrypted contents. The raw data (or unencrypted source) will be called source while the encrypted data will be called as destination. The cryptographic algorithms can be distinguished in two major categories: the two ways and the one way. Two ways algorithm means that we can get the destination from the source if we use the algorithm and a password or key and we can get the source from the destination by reversing the process. One-way algorithms will only allow us to obtain the encrypted from the source. There is also one other major distinction between cryptographic algorithms, based on the comparison of the contents of the source and the destination. If the destination and the source have the same contents then we deal with lossless encryption while the opposite would indicate a lossy algorithm. The following table summarizes and gives example of the various algorithms:

Table 1-1: Example of various cryptographic algorithms. Category Lossless Lossy 2-way ZIP, DOC, XLS, Blowfish,

Twofish, DES, RSA, most cryptographic algorithms

JPEG, MP3, WAV, most media

1-way Secure HASH 128bit, 256bit, 1024 bit

Authentication based on watermarks

3

Consider for example an MP3 song at 128 Kbit and the same song at 256 Kbit. Both information is encrypted, i.e. you can’t use it if you don’t have a special decoding program (like WinAmp). It is not secure, because everyone with the same program can listen to the information. The two versions of the MP3 file differ in the way that the size is different and that the 256 Kbit version will probably contain

Chapter 1: Introduction

much more audio detail than the 128 Kbit (better quality). The question is does it matter? Probably not, most of us are not audiophiles and we don’t use perfect audio systems in order to distinguish the details between the two versions. But we DO care about the space, 100 MP3 songs of 3 minutes average duration at 256 Kbit will most likely occupy 800 MB space, while if we use 128 Kbit we will use about 400 MB space! In other cases it would be a disaster to lose data, like when we are dealing with word documents. Imagine what would happen if the encrypted .DOC (Word Document) would keep most of the text and saved features. Here we cannot afford for a lossy encryption. DOC is not secure in general, but it can be if we set a password. Then, unauthorized users cannot access the encrypted text. The information presented in Chapters 2,3 and 4, comes from online documents (documents I’ve found while searching the Internet) and it is provided “as-is”.

4

Chapter 2: Lossless compression

Lossless Compression 2

2. Lossless compression

2.1 Shannon-Fano model

Computers generally encode characters using the standard ASCII chart, which assigns an 8-bit code to each symbol. For an example, the letter ‘a’ has an ASCII value of 97, and is encoded as ‘01100001’. Characters that occur more frequently (such as ‘e’) are treated the same as rare characters, such as ‘ü’. A file that has 100 characters will require 800 bits – this value is fixed, whether the file contains 100 unique characters or if it has 100 occurrences of the same character. The advantages of the ASCII encoding scheme is that boundaries between characters are easily determined, and the pattern used for each character is fixed and universal.

However, in almost any given text file, some characters occur with more

frequency than others. Wouldn’t it thus make more sense to assign shorter bit codes to more frequent characters than less frequent ones? This idea is not new. An early example of data compression is Morse code, developed by Samuel Morse in the mid-19th century. Letters sent by telegraph are encoded with dots and dashes. Morse noticed that certain letters occurred more often than others. In order to reduce the average time required to send a message, he assigned shorter sequences to letters that occur more frequently such as e(·) and a(· -) , and longer sequences to letters that occur less frequently such as q(- - ·-) and j(·- - -).

This idea of using shorter codes for more frequently occurring characters was

taken into the field of computing by Claude Shannon and R.M. Fano in the 1950’s, when they developed the Shannon-Fano compression algorithm. However, D.A. Huffman published a paper in 1952 that improved the algorithm slightly, bypassing the Shannon-Fano compression algorithm with the aptly named Huffman coding.

To see the advantages of these compression algorithms, consider a text file

that has 35 letters with the following letter frequencies – A: 14; B: 7; C: 5; D: 5; E: 4. Using the ASCII encoding, each of these letters will have a separate bit pattern, consuming 35*8 = 280 bits of space. "Decoding" such a string (i.e. translate the binary encoding back into the original text file) simply consists of breaking the encoding into 8-bit bytes, and converting each byte into the character is represents using the ASCII table. A file that is encoded in this scheme has the advantage of needing no additional information to be passed along with the encoding, since all files and computers have the same binary-to-character mapping.

Variable-length encoding schemes such as the Huffman and Shannon-Fano

schemes have the following properties:

5


• Codes for more frequent characters are shorter than ones for less probable characters.

• Each code can be uniquely decoded. This is also called the prefix property, i.e. no character’s encoding is a prefix of any other. To see why this property is important, consider the case where ‘A’ is encoded as 0, and ‘B’ is encoded as ‘01’, and ‘C’ is encoded as ‘10’. If the decoder encounters the bit-stream ‘0010’, is this ‘ABA’ or ‘AAC’? With the prefix guarantee, there is no ambiguity in determining where the character boundaries are. We start reading from the beginning, and gather bits in a sequence until we find a match. That indicated the end of a character, and we move along to the next character.

2.1.1 Overview

One area of considerable interest in many applications is data compression, which is the science of reducing the number of bits required to store a given body of data. We consider one approach here, based on weight-balanced binary trees.

Suppose you were given the task of storing messages comprised of the 7 letters A-G plus space (just to keep things simple). In the absence of any information about their relative frequency of use, the best you could do would be to use a three-bit code - e.g.

Table 2-1: Letter representation using a 3-bit code system. Code Equivalence 000 Space 001 A 010 B 011 C 100 D 101 E 111 G

Suppose now that we have a 100-character combination using the letters mentioned above and that after counting the instances of each letter in the 100-character phrase we come up with the following results:

Table 2-2: Count of each letter in the 100-character long sentence. Letter Count Space 30 A 10 B 10 C 5 D 5 E 30 F 5 G 5

6


This phrase by itself would occupy 100x8=800 bits in our hard disk (since each letter in the ASCII table is described by 8 bits) but if we use Error! Reference source not found. representation, then each letter would occupy just 3 bits, so our 100-character phrase would only require 3x100=300 bits in our hard disk. To accomplish this, the only task necessary is to replace every 8-bit occurrence of a letter with the equivalent 3-bit representation. We’ve just accomplished 62.5% compression. 2.1.2 Variable Length Representations What would have happened if instead of the coding presented in Table 2-1, we used the one presented in Table 2-3?

Table 2-3: New code representation. Letter New code Space 11 A 000 B 001 C 0100 D 0101 E 10 F 0110 G 0111

This representation is of course arbitrary, but it is based on the rule of the unique identification. That is, in a row of 0 and 1, if we sequentially scan all bits, we will come up with one and only one interpretation. Consider the following row of bits (0’s and 1’s):

0101000010111001100101 To decode this, start from left to right, by reading the bits one by one and write down the result, when you find a combination mentioned in Table 2-3. We have: 0, which is not present in Table 2-3, 01, 010, 0101 which is present and is the letter D. Start again from the 5th bit: 0, 00, 000 which is A. If we continue we get:

DAD BED: 0101000010111001100101 Coming back to our 100 character long sentence, this would occupy (using the count mentioned in Table 2-2): (10x3) + (10x3) + (5x4) + (5x4) + (2x30) + (5x4) + (5x4) + (30x2) = 260 bits

This result compared to the original compression attempt yields additional savings of about 13%! It is obvious that the whole process can be further optimized but still it cannot be generalized. Imagine how difficult the problem will be if we had numbers, the whole alphabet and special characters (256 in total).

7


A variable length code can be represented by a decode tree, with external nodes representing characters and internal nodes representing a decision point at a single bit of the message – like the one illustrated in Figure 2-1. The optimum tree is the one having the smallest weighted external path length - sum of the levels of the leaves times their weights.

1st bit 0 1

2nd bit 2nd bit 0 1 0 1 3rd bit 3rd bit [E] [Space] 0 1 0 1 [A] [B] 4th bit 4th bit 0 1 0 1 [C] [D] [F] [G]

Figure 2-1: Tree representation of letter codes. 2.1.3 Huffman Algorithm An algorithm for computing weight-balanced code trees is the Huffman algorithm. Its principle is as follows: We work with a linked list of partial trees. Initially, the list contains one entry for each character. In each iteration, we choose the two partial trees of least weight and construct a new tree consisting of an internal node plus these two as its children. We put this new tree back on the list, with weight equal to the sum of its children's weights.

Since each step reduces the length of the list by 1 (two partial trees removed and one put back on), after n-1 iterations we have a list consisting of a single node, which is our decode tree. The following example demonstrates this principle. It should be noted, however, that this isn't the way the code actually works. For convenience, it builds the list backwards. Note: The least weight in each step is printed with italics. Initial list: A B C D E F G space .10 .10 .05 .05 .30 .05 .05 .30 / \ / \ / \ / \ / \ / \ / \ / \

8


Step 1 - remove C, D and add new node: () A B E F G space .10 .10 .10 .30 .05 .05 .30 / \ / \ / \ / \ / \ / \ / \ C D Step 2 - remove F, G and add new node: () () A B E space .10 .10 .10 .10 .30 .30 / \ / \ / \ / \ / \ / \ F G C D Step 3 - remove A, B and add new node: () () () E space .20 .10 .10 .30 .30 / \ / \ / \ / \ / \ A B F G C D Step 4 - remove two partial trees and add new node: () () E space .20 .20 .30 .30 / \ / \ / \ / \ () () A B / \ / \ C D F G Step 5 - remove two partial trees and add new node: () E space .40 .30 .30 / \ / \ / \ () () / \ / \ A B () () / \ / \ C D F G Step 6 - remove E, space and add new node: () () .60 .40 / \ / \ E space () () / \ / \ A B () () / \ / \

9

C D F G


Step 7 - construct final tree: () 1.00 / \ () () / \ / \ () () E space / \ / \ A B () () / \ / \ C D F G

For the performance of the algorithm (as presented), construction of the initial list is O(n). Transforming to a tree involves n-1 (= O(n)) iterations. On each iteration, we scan the entire list to find the two partial trees of least weight = O(n) - so this process, using the simplest mechanism for storing the list of partial trees is O(n2). (It can be made O(n log n) by storing the partial trees in a heap. Printing the tree is O(n). Overall is therefore O(n2). However, we could reduce time to O(n log n) by using a more sophisticated data structure for the "list" of partial trees - e.g. a heap based on weight. We have applied this technique to individual characters in an alphabet. It could also be profitably applied to larger units - e.g. we might choose to have a single code for frequently occurring words (such as "the") or sequences of letters within words (such as "th" or "ing").

2.2 Dictionary Based Compressors

Statistical models, such as the Huffman and Shannon-Fano models illustrated above, usually encode a single symbol at a time—by generating a one-to-one symbol-to-code map. The basic idea behind a dictionary-based compressor is to replace an occurrence of a particular phrase or group of bytes in a piece of data with a reference to a previous occurrence of that phrase.

Like the Huffman Algorithm, dictionary based compression schemes also have

a historical basis. Where Morse code uses the frequency of occurrence of single characters, a widely used form of Braille code, also developed in the mid-19th century, uses the frequency of occurrence of words to provide compression. In Braille coding, 2 x 3 arrays of dots are used to represent text.

10

Different letters are represented by different combinations of raised and flat dots. In Grade I Braille, each array of six dots represents a single character. However, given six dots with two positions for each dot, we can obtain 26 or 64 different combinations. If we use 26 of these for the different letters, we have 38


combinations left over. In Grade 2 Braille, some of these leftover combinations are used to represent words that occur frequently, such as "and" and "for". One of the combinations is used as a special symbol indicating that the symbol following is a word and not a character, thus allowing a large number of words to be represented by two arrays of dots. These modifications, along with contractions of some of the words, result in a significant compression in the average amount of space used.

In modern data compression, there are two main classes of dictionary-based schemes, named after Jakob Ziv and Abraham Lempel, who first proposed them in 1977 and 1978. These are called LZ77 and LZ78, respectively.

2.2.1 Overview

Lempel-Ziv 77 (LZ77) algorithm is the first Lempel-Ziv compression algorithm for sequential data compression. The dictionary is a portion of the previously encoded sequence. The encoder examines the input sequence through a sliding window as shown in Figure 9. The window consists of two parts:

• a search buffer that contains a portion of the recently encoded sequence, and • a look-ahead buffer that contains the next portion of the sequence to be

encoded.

In the Table 2-4 below, the search buffer contains eight symbols (in blue), while the look-ahead buffer contains nine symbols (in red). In practice, the sizes of the buffers are significantly larger.

Table 2-4: Flow demonstration diagram of LZ77. search buffer look-ahead buffer …a c c a b r a c a d a b r a r r a r r a c…

2.2.2 LZ Algorithm

To encode the sequence in the look-ahead buffer, the encoder moves a search pointer back through the search buffer until it encounters a match to the first symbol in the look-ahead buffer. The distance of the pointer from the look-ahead buffer is called the offset. The encoder then examines the symbols following the symbol at the pointer location to see if they match consecutive symbols in the look-ahead buffer.

The number of consecutive symbols in the search buffer that match

consecutive symbols in the look-ahead buffer, starting with the first symbol, is called the length of the match. The encoder searches the search buffer for the longest match. Once the longest match has been found, the encoder encodes it with a triple <o, l, c>, where o is the offset, l is the length of the match, and c is the codeword corresponding to the symbol in the look-ahead buffer that follows the match. For example, in the diagram above, the longest match is the first ‘a’ of the search buffer.

11


The offset o in this case is 7, the length of the match l is 4, and the symbol in the look-ahead buffer following the match is ‘r’. The reason for sending the third element in the triple is to take care of the situation where no match for the symbol in the look-ahead buffer can be found in the search buffer. In this case, the offset and match-length values are set to 0, and the third element of the triple is the code for the symbol itself. The algorithm looks like the following:

while( lookAheadBuffer not empty ) { get a pointer (position, match) to the longest match in the window for the lookAheadBuffer; output a (position, length, char()) triple; shift the window length+1 characters along; }

Figure 2-2: LZ-77 Algorithm flow chart.

For the decoding process, it is basically a table loop-up procedure and can be done by reversing the encoding procedures. We employ the same buffer sized n characters, and then use its first (N-n) spaces to hold the previously decoded characters, where N is the size of the window (sum of the size of the look-ahead buffer and the search buffer) used in the encoding process.

If we break up each triple that we encounter back into its components: -

position offset o, match length l, and the last symbol of the incoming stream c, we extract the match string from buffer according to o, and thus obtain the original content. What has been shifted out of the buffer is sent to the output. The process continues until all code words have been decoded, and the decoding is then complete. 2.2.3 Example

An LZ77 decoding example of the triple <7, 4, C(r)> is shown in Figure 2-3. All popular archivers (arj, lha, zip, zoo) are variations on the LZ77 theme. One of the main limitations of the LZ77 algorithm is that it uses only a small window into previously seen text, which means it continuously throws away valuable dictionary entries because they slide out of the dictionary. The longest match possible is roughly the size of the look-ahead buffer; many of the matches actually existing in the file may actually be much longer.

The sliding window makes the algorithm biased toward exploiting recency in

the text, and this is not necessarily a loss. This can be a significant advantage, e.g. in a phonebook streams of data tend "look" more like what has been seen recently that what was seen long ago." (Nelson, 277) However, the street address would only show compression faintly, when two listings with the same last name lived at the same address.

12

One obvious way to get around this problem is to increase the size of the search and look-ahead buffers. However, changing these parameters will drastically increase the CPU time needed for compression. Since string comparisons between the search buffer phrases and the look-ahead buffer proceed sequentially, the runtime here will increase in direct proportion to the length of the look-ahead buffer.


Also, changing the size of the search buffer will only marginally affect the efficiency because we are still using an algorithm that relies on recency to perform compression.

Figure 2-3: Example of the LZ algorithm 2.2.4 Variants

Below in Table 2-5, the most common LZ variations are listed, along with the Authors, the year that the variations were implemented and a short description.

Table 2-5: Summary of principal LZ variations. (N is the size of window used)

13

MethodAuthor Year Description LZ77 Ziv and Lempel 1977 Send pairs with pointer and character.

Pointer is fix-size and indicates a substringin the previous N characters.

LZR Rodeh et al. 1981 Send pairs with pointer and character.Pointer is variable-size and indicates asubstring anywhere in the previouscharacters.

LZSS Bell 1986 A flag bit distinguishes sending of pointeror character. Pointer is fix-size andindicates a substring in the previous Ncharacters.

LZB Bell 1987 Same as LZSS, except that pointer isvariable-size

LZH Bell 1987 Same as LZSS, except that Huffman codingis used for pointers on a second pass.


14

LZ78 Ziv and Lempel 1978 Send pairs of pointer and character.Pointer indicates a previously parsedsubstring which is stored in a dictionary

LZW Welch 1984 Include all alphabets in dictionary initially.Therefore only outputs fix-size pointers.

LZC Thoman et al. 1985 As suggested by Welch, a variable-sizepointer scheme is implemented.

LZT Tischer 1987 Same as LZW, except that the parsedstrings in dictionary are stored as a LeastRecently Used list.

LZJ Jakobsson 1985 Same as LZW, except that pointers canreach anywhere in the previous characters.

LZFG Fiala andGreece

1989 By breaking up strings in the slidingwindow, pointers are formed from a treedata structure.

Chapter 3: Lossy compression

Lossy Compression 3

3. General

Lossy compression differs from its counterpart, lossless compression, as its name implies—some amount of data may be lost in the process. Thus, after a compression/decompression cycle, the data set will be modified from the uncompressed original and information may be lost.

One may ask why the loss of data can be tolerated in any case. Lossy compression techniques attempt to eliminate unnecessary or redundant information, focusing more on saving space over preserving the accuracy of the data. Ideally, the loss is either minimal or undetectable by human observations. Lossy compression techniques are used for pictures and music files that can be trimmed at the edges. Unlike text files and processing files, pictures and music do not require reconstruction to be identical to the original, especially if the data dropped is insignificant or undetectable.

This section will introduce lossy compression in JPEG and MP3 technology.

3.1 JPEG

Programs using complex graphics are showing up in virtually every area of computing applications including games, education, desktop publishing, graphical design, and most recently the World Wide Web. Although graphics do a great deal to enhance the usability and visual aesthetics of such applications, they consume prodigious amounts of disk storage.

When research into image compression began in the late 1970s, most compression concentrated on using conventional lossless techniques. However, such types of compression, which included statistical and dictionary methods of compression, did not tend to perform well on photographic, or continuous tone images. The primary problem with statistical techniques stemmed from the fact that pixels in photographic images tend to be well spread out over their entire range. If the colors in an image are plotted as a histogram based on frequency, the histogram is not as "spiky" as one would like for statistical compression to be effective. Each pixel code has approximately the same chance of appearing as any other, negating any opportunity for exploiting entropy differences (Nelson 349).

15

By the late 1980s, extensive research pushed the development of lossy compression algorithms that take advantage of known limitations of the human eye. Such algorithms play on the idea that slight modifications and loss of information during the compression/decompression process often do not affect the quality of the


image as perceived by the human user. Eventually, the JPEG continuous tone image compression specification was standardized, named after the Joint Photographic Experts Group, the standards group consisting of members from both the CCITT and the ISO that wrote the specification. The JPEG specification includes separate lossy and lossless algorithms; however, the lossless algorithm is rarely used due to its poor compression ratios. Thus, when one mentions JPEG compression, it can almost be assumed that the reference is being made to the lossy algorithm, or the JPEG baseline algorithm. The baseline algorithm, which is capable of compressing continuous tone images to less that 10% of their original size without visible degradation of the image quality, is detailed below.

The JPEG lossy compression algorithm consists of three successive stages, shown in the flow chart below.

DCT Transformation --> Coeff Quantization --> Lossless Compression

Both DCT transformation and the final compression of the quantized data are, for the most part, lossless procedures (negligible precision may be lost during DCT transformation due to minor numerical round-offs). This leaves the coefficient quantization phase as the driving force behind JPEG’s overall "lossyness". It is in this step that insignificant data concerning the image is discarded.

3.2 MP3 3.2.1 Overview

The MPEG audio standard is a high-complexity, high-compression, and high audio quality algorithm. The Motion Pictures Experts Group (MPEG), a group that works on standards for both audio and video systems, saw the benefits of the digital representation of audio data. Its advantages include high immunity to noise (interference that destroys the integrity of signals), stability, reproducibility, and the efficient implementation of audio processing functions through a computer.

MPEG is a working group that was formed from the existing JPEG (Joint Photographic Experts Group) standard for bit reduction of still pictures. Its goal is to devise a suitable encoding scheme for transmitting moving pictures and sound over various broadcast links and recording them in standard digital storage media. Since moving pictures are often accompanied by sound, MPEG also defined a standard for encoding audio information. In 1992, a standard for audio and video encoding was devised known as MPEG-1.

MP3 stands for MPEG-1 Layer 3. Layers represent a family of coding algorithms. Layer 1 has the lowest complexity compared to the other layers. Layer 2 requires a more complex encoder and decoder and is directed more towards different applications. Thus, Layer 2 is more able than Layer 1 to remove the redundancy in the signal that takes up space. Layer 3 is again more complex and further reduces redundancy and relevance from the data. . The layers are backwards compatible, which means that any software or hardware capable of decoding Layer 3 audio should also be able to decode Layers 1 and 2.

16


So why has MP3 emerged as the leading tool for Internet audio delivery? MPEG-1 Layer 3 is defined as an open standard, so the specification is available to anyone interested in implementing the standard. Since no single company owns the standard, public example source code is available and the format is well defined. Also, driven by the demand for professional use, many MP3 encoders and decoders are readily available for use. This simplifies and accelerates the adoption of MP3 technology. Additionally, the widespread increase in usage of computers fast enough to decode audio, as well as increasingly fast and widely available Internet access, has contributed to the embracing of MP3 music format. 3.2.2 The Concept

Without any sort of compression, it would take 1.4 megabytes to represent just one second of CD quality music in WAV format, the de facto standard for sound on PCs. But by using MPEG audio coding, the size can be shrunk down by a factor of twelve without losing any of the sound quality.

Though MP3 compression is considered lossy because some data cannot be

recovered after compression, the MPEG algorithm can achieve transparent, or perceptually lossless, compression. After testing, it was concluded that expert listeners could not distinguish between coded and original audio clips even with a six to one compression ratio (Pan 3).

MP3 compression is so successful for imitating CD quality music because it utilizes the concept of auditory masking. Basically, this type of masking occurs when the presence of a strong audio signal makes weaker audio signals in the proximity imperceptible. This non-linear and adaptive threshold of hearing (the level below which a sound is not heard) varies with frequency and between individuals. Whether a person hears a sound or not depends on the frequency of the sound and whether the amplitude is above or below that persons hearing threshold at that frequency. For example, in the vicinity of a loud noise such as an airplane passing overhead, it is impossible to hear ordinary conversations due to the distortions present at the hearing thresholds of the individuals. Sounds that are inaudible due to dynamic adaptation of the hearing threshold are said to be masked.

This effect is particularly relevant to music. A loud orchestra easily masks the sounds of some individual instruments playing softly. Similarly, when this orchestra is recorded, the masked instruments will not be audible to the listener. A recording, in order to achieve efficiency, should discard the inaudible data and instead use that space to store other audible data. Drawing a parallel to digital audio compression, in order to achieve efficiency, an MP3 should drop the inaudible areas of data and, in that form of compression, save space.

When sounds are digitized, the computer grabs all the sound and stores it as

binary data. Even if parts of the sound are beyond the range of human hearing, they're digitized anyway. MP3 compresses the file by removing any numbers representing sounds beyond the range of human hearing. The Algorithm for MP3 Compression

17

The process of MP3 compression can be broken down into steps. First, the input audio stream passes through a filter bank that divides the sound into sub bands of frequency. Simultaneously, it passes through psycho-acoustic model that utilizes the concept of auditory masking to determine what can or cannot be heard in


each sub band. The bit allocation block minimizes the audibility of noise. Finally, the bit stream formatting block accumulates all the information and processes it into a coded bitstream (Pan 2).

3.2.3 The Hybrid Filter Bank

The purpose of the filter bank is to divide the audio signal into 32 equal-width frequency sub bands. Empirical evidence has shown that the human ear has a limited resolution that can be expressed in terms of critical bandwidths less than 100Hz and more than 4kHz. Within a critical bandwidth the human ear blurs frequencies. Thus the filter bank creates equal-width frequency sub bands that correlate to the critical bandwidths in a method diagrammed in the following figure.

While Layer 1 and Layer 2 uses just a poly-phase filter bank, an additional MDCT is used in Layer 3 compression.

18


3.2.3 The Psychoacoustic Model

The branch of psychoacoustics examines the concept of auditory masking and its effect on compression. Within each sub band where blurring occurs the presence of a strong tonal signal can mask a region of weaker signals. This is evidenced in the following figure.

If the noise resulting from approximation of sound data can be kept below the masking threshold for each partition, then the compression result should be indistinguishable from the original audio data.

3.2.4 Bit Allocation

Through an iterative algorithm, the bit allocation uses information from the psychoacoustic model to determine the number of code bits to be allocated to each sub band. This process can be described using the following formula:

MNRdB = SNRdB - SMRdB

where: MNRdB is the mask-to-noise ratio

SNRdB is the signal-to-noise ratio, given with the MPEG audio standard in a table

SMRdB is the signal-to-mask ratio, derived from the psychoacoustic model

19

Then the sub bands are placed in order of lowest to highest mask-to-noise ratio, and the lowest sub band is allocated the smallest number of code bits and this process continues until no more code bits can be allocated (Pan 5).


Two nested iteration loops called the rate loop and the distortion loop serve to quantize and code in MP3 encoders. The quantized values are coded using Huffman methods, which is lossless.

20

Chapter 4: Credit Cards

Credit Cards 4

4. Credit Cards

4.1 LUHN Algorithm

Based on ANSI X4.13, the LUHN formula (also known as the modulus 10 -- or mod 10 -- algorithm) is used to generate and/or validate and verify the accuracy of credit-card numbers.

Most credit cards contain a check digit, which is the digit at the end of the credit card number. The first part of the credit-card number identifies the type of credit card (Visa, MasterCard, American Express, etc.), and the middle digits identify the bank and customer.

To generate the check digit, the LUHN formula is applied to the number. To validate the credit-card number, the check digit is figured into the formula.

Here's how the algorithm works for verifying credit cards; the math is quite simple:

1) Starting with the second to last digit and moving left, double the value of all the alternating digits.

2) Starting from the left, take all the unaffected digits and add them to the results of all the individual digits from step 1. If the results from any of the numbers from step 1 are double digits, make sure to add the two numbers first (i.e. 18 would yield 1+8). Basically, your equation will look like a regular addition problem that adds every single digit.

3) The total from step 2 must end in zero for the credit-card number to be valid.

The LUHN formula was created in the late 1960s by a group of mathematicians. Shortly thereafter, credit card companies adopted it. Because the algorithm is in the public domain, it can be used by anyone.

The LUHN formula is also used to check Canadian Social Insurance Number (SIN) validity. In fact, the LUHN formula is widely used to generate the check digits of many different primary account numbers. Almost all institutions that create and require unique account or identification numbers use the Mod 10 algorithm.

Actual Credit Cards have prefixes that are unique to each card. Table 4-1 lists the prefixes for the most common credit cards.

21


Table 4-1: Credit card prefixes.

Card Type Prefix Length

MASTERCARD 51-55 16

VISA 4 13, 16

AMEX 34, 37 15

Diners Club/ Carte Blanche

300-305 36, 38

14

Discover 6011 16

JCB 3 16

JCB 2131, 1800 15

4.2 Example Suppose we want to generate a VISA card number. We know that it will have 16 digits and start with 4 (from Table 4-1). We select a random number like 4321 2342 7567 8190 and we follow the LUHN algorithm’s procedure:

Position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Number 4 3 2 1 2 3 4 2 7 5 6 7 8 1 9 0 Multiplier 2 2 2 2 2 2 2 2 Total 8 3 4 1 4 3 8 2 14 5 12 7 16 1 18 0 Sum 8 3 4 1 4 3 8 2 5 5 3 7 7 1 9 0

The row “number” is a random credit card number, subject to verification. The multiplier row is always the same. The total row is the product of the multiplication of “multiplier” times “number” columns. When the total is 10 or greater, we use the sum row, where we add the digits of the total row. For example, if we get a 14 in the total row, the equivalent sum will be 1+4=5. We add all digits in the sum row: 8+3+4+…+9=70. If this result is divided by 10 exactly, then the credit card number is valid. In this example, the credit card IS valid!

4.3 Javascript Code

You can freely use this Javascript code in your .html pages in order to perform a “quick ‘n’ dirty” credit card number verification. Note, that an online verification at a later time is still required to make sure that the credit card actually exists. However, with the following code you can implement the LUHN algorithm check, which is sufficient to tell you if the credit card number could be correct, thus redirecting your clients to enter their credit card number again and save you a check with the bank.

22

<HEAD> <SCRIPT LANGUAGE="JavaScript"> <!-- Begin var Cards = new makeArray(8); Cards[0] = new CardType("MasterCard", "51,52,53,54,55", "16"); var MasterCard = Cards[0]; Cards[1] = new CardType("VisaCard", "4", "13,16"); var VisaCard = Cards[1]; Cards[2] = new CardType("AmExCard", "34,37", "15"); var AmExCard = Cards[2]; Cards[3] = new CardType("DinersClubCard", "30,36,38", "14"); var DinersClubCard = Cards[3]; Cards[4] = new CardType("DiscoverCard", "6011", "16"); var DiscoverCard = Cards[4]; Cards[5] = new CardType("enRouteCard", "2014,2149", "15"); var enRouteCard = Cards[5]; Cards[6] = new CardType("JCBCard", "3088,3096,3112,3158,3337,3528", "16"); var JCBCard = Cards[6]; var LuhnCheckSum = Cards[7] = new CardType(); /***********************************************************\ CheckCardNumber(form) function called when users click the "check" button. \***********************************************************/ function CheckCardNumber(form) { var tmpyear; if (form.CardNumber.value.length == 0) { alert("Please enter a Card Number."); form.CardNumber.focus(); return; } if (form.ExpYear.value.length == 0) { alert("Please enter the Expiration Year."); form.ExpYear.focus(); return; } if (form.ExpYear.value > 96) tmpyear = "19" + form.ExpYear.value; else if (form.ExpYear.value < 21) tmpyear = "20" + form.ExpYear.value; else { alert("The Expiration Year is not valid."); return; } tmpmonth = form.ExpMon.options[form.ExpMon.selectedIndex].value; // The following line doesn't work in IE3, you need to change it // to something like "(new CardType())...". // if (!CardType().isExpiryDate(tmpyear, tmpmonth)) { if (!(new CardType()).isExpiryDate(tmpyear, tmpmonth)) {

23

alert("This card has already expired.");


return; } card = form.CardType.options[form.CardType.selectedIndex].value; var retval = eval(card + ".checkCardNumber(\"" + form.CardNumber.value + "\", " + tmpyear + ", " + tmpmonth + ");"); cardname = ""; if (retval) // comment this out if used on an order form alert("This card number appears to be valid."); else { // The cardnumber has the valid luhn checksum, but we want to know which // cardtype it belongs to. for (var n = 0; n < Cards.size; n++) { if (Cards[n].checkCardNumber(form.CardNumber.value, tmpyear, tmpmonth)) { cardname = Cards[n].getCardType(); break; } } if (cardname.length > 0) { alert("This looks like a " + cardname + " number, not a " + card + " number."); } else { alert("This card number is not valid."); } } } \***********************************************************/ Object CardType([String cardtype, String rules, String len, int year, int month]) cardtype : type of card, eg: MasterCard, Visa, etc. rules : rules of the cardnumber, eg: "4", "6011", "34,37". len : valid length of cardnumber, eg: "16,19", "13,16". year : year of expiry date. month : month of expiry date. eg: var VisaCard = new CardType("Visa", "4", "16"); var AmExCard = new CardType("AmEx", "34,37", "15"); \***********************************************************/ function CardType() { var n; var argv = CardType.arguments; var argc = CardType.arguments.length; this.objname = "object CardType"; var tmpcardtype = (argc > 0) ? argv[0] : "CardObject"; var tmprules = (argc > 1) ? argv[1] : "0,1,2,3,4,5,6,7,8,9";

24

var tmplen = (argc > 2) ? argv[2] : "13,14,15,16,19";


this.setCardNumber = setCardNumber; // set CardNumber method. this.setCardType = setCardType; // setCardType method. this.setLen = setLen; // setLen method. this.setRules = setRules; // setRules method. this.setExpiryDate = setExpiryDate; // setExpiryDate method. this.setCardType(tmpcardtype); this.setLen(tmplen); this.setRules(tmprules); if (argc > 4) this.setExpiryDate(argv[3], argv[4]); this.checkCardNumber = checkCardNumber; // checkCardNumber method. this.getExpiryDate = getExpiryDate; // getExpiryDate method. this.getCardType = getCardType; // getCardType method. this.isCardNumber = isCardNumber; // isCardNumber method. this.isExpiryDate = isExpiryDate; // isExpiryDate method. this.luhnCheck = luhnCheck;// luhnCheck method. return this; } \***********************************************************/ boolean checkCardNumber([String cardnumber, int year, int month]) return true if cardnumber pass the luhncheck and the expiry date is valid, else return false. \***********************************************************/ function checkCardNumber() { var argv = checkCardNumber.arguments; var argc = checkCardNumber.arguments.length; var cardnumber = (argc > 0) ? argv[0] : this.cardnumber; var year = (argc > 1) ? argv[1] : this.year; var month = (argc > 2) ? argv[2] : this.month; this.setCardNumber(cardnumber); this.setExpiryDate(year, month); if (!this.isCardNumber()) return false; if (!this.isExpiryDate()) return false; return true; } /**************************************************************\ String getCardType() return the cardtype. \**************************************************************/ function getCardType() { return this.cardtype; } /**************************************************************\

25

String getExpiryDate()


return the expiry date. \**************************************************************/ function getExpiryDate() { return this.month + "/" + this.year; } /**************************************************************\ boolean isCardNumber([String cardnumber]) return true if cardnumber pass the luhncheck and the rules, else return false. \**************************************************************/ function isCardNumber() { var argv = isCardNumber.arguments; var argc = isCardNumber.arguments.length; var cardnumber = (argc > 0) ? argv[0] : this.cardnumber; if (!this.luhnCheck()) return false; for (var n = 0; n < this.len.size; n++) if (cardnumber.toString().length == this.len[n]) { for (var m = 0; m < this.rules.size; m++) { var headdigit = cardnumber.substring(0, this.rules[m].toString().length); if (headdigit == this.rules[m]) return true; } return false; } return false; } /**************************************************************\ boolean isExpiryDate([int year, int month]) return true if the date is a valid expiry date, else return false. \**************************************************************/ function isExpiryDate() { var argv = isExpiryDate.arguments; var argc = isExpiryDate.arguments.length; year = argc > 0 ? argv[0] : this.year; month = argc > 1 ? argv[1] : this.month; if (!isNum(year+"")) return false; if (!isNum(month+"")) return false; today = new Date(); expiry = new Date(year, month); if (today.getTime() > expiry.getTime()) return false; else return true; }

26


/***********************************************************\ boolean isNum(String argvalue) return true if argvalue contains only numeric characters, else return false. \***********************************************************/ function isNum(argvalue) { argvalue = argvalue.toString(); if (argvalue.length == 0) return false; for (var n = 0; n < argvalue.length; n++) if (argvalue.substring(n, n+1) < "0" || argvalue.substring(n, n+1) > "9") return false; return true; } /************************************************************\ boolean luhnCheck([String CardNumber]) return true if CardNumber pass the luhn check else return false. Reference: http://www.ling.nwu.edu/~sburke/pub/luhn_lib.pl \***********************************************************/ function luhnCheck() { var argv = luhnCheck.arguments; var argc = luhnCheck.arguments.length; var CardNumber = argc > 0 ? argv[0] : this.cardnumber; if (! isNum(CardNumber)) { return false; } var no_digit = CardNumber.length; var oddoeven = no_digit & 1; var sum = 0; for (var count = 0; count < no_digit; count++) { var digit = parseInt(CardNumber.charAt(count)); if (!((count & 1) ^ oddoeven)) { digit *= 2; if (digit > 9) digit -= 9; } sum += digit; } if (sum % 10 == 0) return true; else return false; }

27

/***********************************************************\


ArrayObject makeArray(int size) return the array object in the size specified. \***********************************************************/ function makeArray(size) { this.size = size; return this; } /***********************************************************\ CardType setCardNumber(cardnumber) return the CardType object. \***********************************************************/ function setCardNumber(cardnumber) { this.cardnumber = cardnumber; return this; } /***********************************************************\ CardType setCardType(cardtype) return the CardType object. \***********************************************************/ function setCardType(cardtype) { this.cardtype = cardtype; return this; } /************************************************************\ CardType setExpiryDate(year, month) return the CardType object. \***********************************************************/ function setExpiryDate(year, month) { this.year = year; this.month = month; return this; } /************************************************************\ CardType setLen(len) return the CardType object. \***********************************************************/ function setLen(len) { // Create the len array. if (len.length == 0 || len == null) len = "13,14,15,16,19"; var tmplen = len; n = 1; while (tmplen.indexOf(",") != -1) { tmplen = tmplen.substring(tmplen.indexOf(",") + 1, tmplen.length); n++; } this.len = new makeArray(n);

28

n = 0;


while (len.indexOf(",") != -1) { var tmpstr = len.substring(0, len.indexOf(",")); this.len[n] = tmpstr; len = len.substring(len.indexOf(",") + 1, len.length); n++; } this.len[n] = len; return this; } /************************************************************\ CardType setRules() return the CardType object. \***********************************************************/ function setRules(rules) { // Create the rules array. if (rules.length == 0 || rules == null) rules = "0,1,2,3,4,5,6,7,8,9"; var tmprules = rules; n = 1; while (tmprules.indexOf(",") != -1) { tmprules = tmprules.substring(tmprules.indexOf(",") + 1, tmprules.length); n++; } this.rules = new makeArray(n); n = 0; while (rules.indexOf(",") != -1) { var tmpstr = rules.substring(0, rules.indexOf(",")); this.rules[n] = tmpstr; rules = rules.substring(rules.indexOf(",") + 1, rules.length); n++; } this.rules[n] = rules; return this; } // End --> </script> </HEAD> <BODY> <center> <form name="ThisForm"> Card Number: <input name="CardNumber" size="16" maxlength="19"><br> Card Type: <select name="CardType"> <option value="MasterCard">MasterCard <option value="VisaCard">Visa <option value="AmExCard">American Express <option value="DinersClubCard">Diners Club <option value="DiscoverCard">Discover

29

<option value="enRouteCard">enRoute


<option value="JCBCard">JCB </select> <br> Expiration Date: Month <select name="ExpMon"> <option value="1" selected>1 <option value="2">2 <option value="3">3 <option value="4">4 <option value="5">5 <option value="6">6 <option value="7">7 <option value="8">8 <option value="9">9 <option value="10">10 <option value="11">11 <option value="12">12 </select> Year <input name="ExpYear" size="2" maxlength="2">(Range: 1997~2020)<br> <input type="button" value="Check" OnClick="CheckCardNumber(this.form)"><br> </form> </center>

30

</html>

© 2001 Fotis Fotopoulos Boston - t-gr.com · decoding program (like ... consider the case where...

Documents

Transcript of © 2001 Fotis Fotopoulos Boston - t-gr.com · decoding program (like ... consider the case where...