public-key cryptography - the rsa and the rabin cryptosystems

UNIVERSITATEA “BABEŞ-BOLYAI” CLUJ-NAPOCA

FACULTATEA DE MATEMATICĂ ŞI INFORMATICĂ

DEPARTAMENTUL INFORMATICĂ

PUBLIC-KEY CRYPTOGRAPHY :

THE RSA AND THE RABIN CRYPTOSYSTEMS

LUCRARE DE DIPLOMĂ

Coordonator ştiinţific: Student:

Conf. Dr. Septimiu Crivei Mihnea Rădulescu

2008

“BABEŞ-BOLYAI” UNIVERSITY CLUJ-NAPOCA

FACULTY OF MATHEMATICS AND COMPUTER SCIENCE

DEPARTMENT OF COMPUTER SCIENCE

PUBLIC-KEY CRYPTOGRAPHY :

THE RSA AND THE RABIN CRYPTOSYSTEMS

BACHELOR OF SCIENCE THESIS

Scientific Coordinator: Student:

Assoc. Prof. Dr. Septimiu Crivei Mihnea Rădulescu

2008

To my fiancée

i

ABSTRACT

Starting in the 50s, there has been a growing interest in securing sensitive digital data, for the

purpose of storing it safely, as well as transmitting it securely over unsecured communication

channels. To address some the drawbacks of symmetric-key cryptography (mainly the key

distribution and authentication issues), Diffie and Hellman set the stage in 1976 for what became

the standard entitled public-key cryptography. From the 90s on, the interest in digital data

security has drifted also to the realm of non-governmental computing, that is companies and

common computer users.

This paper’s main goal is to deliver an accurate image on the concepts of data security and

cryptography, by presenting the theory and applications of two of the fundamental public-key

cryptosystems used nowadays, namely the RSA and the Rabin cryptosystems. To prove the

usefulness and power of public-key cryptography from a practical standpoint, two software

applications have been designed, one for each cryptosystem, that implement every algorithm

inherent to the process of securing data (primes generation, key generation, encryption and

decryption). Also, the paper promotes public-key cryptography as an efficient means of testing

the speed of today's computer processors, due to the computational intensiveness of its

underlying operations.

This work is organized into five chapters, as follows:

Chapter 1 – Introduction to Cryptography explains the basics of cryptography

(terminology and the symmetric-key cryptography), in order to allow a smooth transition

to the main topic of the paper, as well as provide the reader with an understanding of the

reasons that made symmetric-key cryptography insufficient for modern-day data security

tasks.

ii

Chapter 2 – Mathematical Foundations of Public-key Cryptography displays the

mathematical background of public-key cryptosystems (Euclidean algorithms, modular

arithmetic, modular equations and equation systems, primality testing), each

mathematical model being tested against an example and then converted into a suitable

computational algorithm.

Chapter 3 – Public-key Cryptosystems focuses on detailing the structure, algorithms

and real-world applicability (encryption of small amounts of data, symmetric-key

exchange and digital signatures) of two remarkable cryptosystems (RSA and Rabin),

while relying on the mathematical background exposed in the previous chapter.

Chapter 4 – Implementing the RSA and the Rabin Cryptosystems covers the steps

needed for developing a powerful and up-to-date public-key encryption software

application for each cryptosystem (outline, analysis and design, implementation, testing),

conforming strictly to the encryption security standards of today and even trying to

surpass them in some respects.

Chapter 5 – Processor Core Benchmarking unlocks a rather innovative aspect of

public-key cryptography, that of employing its underlying computationally-demanding

algorithms as an effective way of assessing the relative performance of the processor

cores of modern-day CPU’s.

1

TABLE OF CONTENTS

Chapter 1 - Introduction to Cryptography.................................................................................3

1.1 Preliminaries....................................................................................................... ...........3

1.2 Symmetric-key cryptosystems......................................................................................9

Chapter 2 - Mathematical Foundations of Public-key Cryptography....................................18

2.1 One-way and trapdoor functions.................................................................................18

2.2 The Euclidean algorithms............................................................................................21

2.3 Modular arithmetic......................................................................................................24

2.4 Primality testing methods............................................................................................45

Chapter 3 - Public-key Cryptosystems......................................................................................54

3.1 The RSA cryptosystem................................................................................................54

3.2 The Rabin cryptosystem..............................................................................................63

3.3 Applications of the RSA and the Rabin cryptosystems...............................................73

Chapter 4 - Implementing the RSA and the Rabin Cryptosystems.......................................81

4.1 Use cases......................................................................................................................83

4.2 Subsystem model.........................................................................................................84

4.3 Package diagram..........................................................................................................85

4.4 Class diagram.................................................................................................... ...........87

4.5 Sequence diagram........................................................................................................98

4.6 Explaining the implementation..................................................................................100

4.7 Revealing the applications’ functionality..................................................................106

Chapter 5 – Processor Core Benchmarking...........................................................................132

5.1 The concept of benchmarking....................................................................................132

5.2 Benchmark development fundamentals.....................................................................133

5.3 Implementing the benchmark.....................................................................................141

Conclusions.................................................................................................................. ...............151

References...................................................................................................................................153

Chapter 1 - Introduction to Cryptography

3

CHAPTER 1 - INTRODUCTION TO CRYPTOGRAPHY

1.1 Preliminaries

Cryptography (derived from Greek κρσπτός kryptós "hidden," and the verb γράφω gráfo

"write") is the study of message secrecy. Cryptography is one of the oldest intellectual pursuits

available to man, almost as old as mathematics itself. Nowadays it is regarded as a science in

continuous and rapid development, at the junction between mathematics and computer science,

with sensible applications in various domains, such as electronic commerce, banking procedures,

computer authentication protocols and information exchange services, just to name a few.

1.1.1 The story of Alice and Bob

Put in an oversimplified perspective, cryptography is concerned with enabling two people, Alice

and Bob, to communicate over an insecure message-passing network, in such a way that the

content of the messages being exchanged is fully understood by the participants (Alice and Bob),

but cannot be exposed by an opponent (eavesdropper, Oscar).

Fig.1.1 Simplified communication network

receives a message sends a message

eavesdrops

Alice Bob

communication channel

Oscar

sends a message receives a message


4

The story of Alice and Bob expresses the basic principles, foundations and challenges of

cryptography using allegory and abstraction to set the framework for a formal, rigorous and

systematic approach to the domain.

“Alice and Bob are apparently ordinary people, which have some interesting twists to their

personalities: Bob is a stockbroker illicitly selling stock shares to speculators, while Alice is a

speculator herself, this being her primary reason for talking to Bob. Besides being concerned on

eavesdropping because of the illegality of their stock “operations”, Alice is worried about her

husband not knowing her involvement in the stock scheme, while Bob is preoccupied on his other

subversive enterprises not being discovered.

Alice communicates with Bob either by telephone or by e-mail. As they talk very often on the

phone, the telephone service becomes increasingly expensive, coupled with Alice being overly

miserly, one of Alice’s immediate goals is minimizing the cost of the phone call.

The telephone line connecting Alice to Bob is very noisy and prone to interferences as well as

communication failure. Due to these difficulties, at some times, Alice and Bob can hardly

communicate with each other. So Alice has to deal with network noise and failures.

It seems the pursuits of Alice and Bob are well-known to the Tax Authority and Secret Police,

governmental organizations which both have almost limitless resources and always listen to the

conversations between Alice and Bob. Because some of the favorite subjects of Alice and Bob

involve tax fraud and the overthrowing of the government, Alice has to ensure the confidentiality

of the conversation with Bob.

One of the tactics employed by the agents of the previously-mentioned organizations is to

telephone Alice and pretend to be Bob. As Alice has never met Bob in person, another challenge

arises for her, namely the identification problem.

To further complicate matters, there is also a trust issue between Alice and Bob, because of some

previous deceitful behavior of Bob. As such, Alice has an extra authentication issue.“ [net01]


5

To summarize, for allowing Alice to successfully communicate with Bob, while taking into

account the inherent communication protocols, cryptography must be powerful enough to:

maintain a minimal cost of equipment and active network connection

retain information consistency even over a faulty connection

ensure confidentiality of the information being passed across the channel

securely identify and authenticate the protagonists

1.1.2 Terminology

Plaintext ( ) = a sequence of characters (either letters from the alphabet, numbers or bytes of

data) that is in a form at which no effort has been made to render the information unreadable and

thus, that can be easily read from and understood. [wiki]

Ciphertext ( ) = a sequence of characters (either letters from the alphabet, numbers or bytes of

data) that is encrypted using an encryption algorithm. Plaintext cannot be deduced from properly

encrypted ciphertext.

Encryption = the process of turning plaintext into ciphertext (encoding).

Decryption = the process of turning ciphertext into plaintext (decoding).

Key ( ) = a piece of information (or parameter) that controls the execution of a cryptography

algorithm. A key can be used either for encryption (obtaining the ciphertext out of the plaintext),

or decryption (obtaining the plaintext out of the ciphertext). In many cryptographic systems (see

Public-Key Cryptography), the key for encryption and the one for decryption are not the same.


6

Fig.1.2 Encryption-decryption scheme [Sch96]

Cipher = algorithm for performing encryption and decryption

Cryptanalysis = (derived from the Greek kryptós, "hidden", and analýein, "to loosen" or "to

untie") the studying and devising of methods and strategies to allow obtaining the meaning of

encrypted data, without having access to the secret information used to generate the encryption.

[wiki] In more formal terms, it means trying to compute the key that generated the encryption,

having access to only the ciphertext. [Cri06]

Cryptology = the science encompassing both cryptography and cryptanalysis, which studies the

security and safety behind data communication and storage.

Cryptosystem = a suite of notations and algorithms required to implement a particular form of

encryption and decryption. [wiki]

Formally, a cryptosystem can be defined as a 5-tuple (P, C, K, E, D): [Sti95]

P is a finite set of possible plaintexts

C is a finite set of possible ciphertexts

K is a finite set of possible keys (the keyspace)

E is a finite set of possible encryption functions (encryption rules)

D is a finite set of possible decryption functions (decryption rules)

K, there are:

an encryption rule : P → C, E

a decryption rule : C → P, D

plaintext plaintext encryption

ciphertext decryption

key key


7

a fundamental constraint: P

an implementation constraint: given , and should be efficiently

computable

Notes on cryptosystems:

In order to satisfy the fundamental constraint previously stated, the encryption function

P → C must always be injective.

If P = C, each encryption rule and each decryption rule are permutations.

1.1.3 A simple encryption-decryption example

The following example uses the Caesar cipher, supposedly employed by the Romans during the

time of Julius Caesar to send orders from Rome to military commanders on the field and back. It

is a simple rotation cipher, in which each plaintext character is replaced by the character to

the right, modulo the size of the alphabet.

Formalization of the Caesar cipher [Cri06]:

P = C = K =

Example:

English alphabet enriched with character “space” ⇒

shift to the right of 3 positions ⇒

English alphabet enriched with character “space” to correspondence:

_ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26


8

Encryption:

Plaintext: julius caesar

Numerical correspondence:

Encryption (using ):

Ciphertext: MXOLXVCFDHVDU

Decryption:

Ciphertext: MXOLXVCFDHVDU


Decryption (using ):

Plaintext: julius caesar

1.1.4 Cryptography vs. steganography

Generally, there a two methods of hiding the content of a message: [Sta05]

cryptography - applying of various transformations to the message content, making it

unintelligible to outsiders

steganography - concealing the message existence itself

Steganography uses a supposedly harmless message cover (for instance, a digital picture) inside

which it adds its message, overwriting the least-significant bit(s) of (some of) the bytes of the

cover message. Therefore, the maximum length the hidden message can have, without spoiling its

concealment, is directly proportional to the length of the cover message. [wiki]

The main drawback of steganography against cryptography is that the discovery of the

information-hiding system used leads to steganography being utterly useless, while for

cryptography the information regarding the encryption system used is already assumed to be

known by an intruder.

Steganography might hold a significant advantage over cryptography in cases where even the

acknowledged existence of the communication between parties poses a problem. [Sta05]


9

Modern steganographic techniques involve hiding the secret message inside:

digital pictures (BMP, JPEG, TIF, PNG, PhotoCD file formats)

digital music (WAV, MP3, OGG file formats)

digital binary files (executables) [Elk07]

1.1.5 A simple steganography example

Hiding the message inside a Kodak Photo-CD (PCD) file: [Sta05]

PCD maximum image resolution (in pixels) : 2048 x 3072

each pixel contains 24-bit of RGB (red-green-blue) encoded color information, meaning

there are 8 bits = 1 byte for each color channel

by altering the least-significant bit of each color channel byte (storing a hidden message

bit of data in it), the image remains unchanged to the human eye

applying the previously-stated reasoning, each pixel of the image can hold 3 bits of

hidden data

as such, the maximum amount of hidden data a PCD image can safely store is 2048 x

3072 x 3 = 18’874’368 bits = 2’359’296 bytes = 2.25 MB

1.2 Symmetric-key cryptosystems

Consider the cryptosystem (P, C, K, E, D) with key K K, E and D the encryption

and decryption rules, respectively. The given cryptosystem is said to be symmetric-key, if for

each key K K and encryption-decryption pair depending on K, it is computationally

feasible (“easy") to compute knowing only and knowing only . [Men96] Symmetric-

key cryptography is also referred to as single-key, one-key and private-key cryptography.

Since most of the symmetric-key cryptosystems employ the same plaintext and ciphertext spaces

(P = C) and many the same function for both encryption and decryption ( : (P = C)

→ (P = C), key K K ), the term symmetric-key becomes completely justified. Such a

function , : P → P, where is called an involution. [Men96]


10

1.2.1 A simple symmetric-key encryption-decryption example

A rather standard example of involutive symmetric-key cryptography is the binary XOR

function, applied to bytes or groups of bytes. This function is extensively used in computer

science in low-level byte-manipulating routines as well as in applications desiring to obscure data

in circumstances where security is not a defining characteristic.

Formalization of the XOR cryptosystem:

P = C = K = (1 byte = 8 bits)

, , and , where the XOR-

ing occurs bit-by-bit on corresponding bit positions of and , from the lowest to the

highest bit:

XOR 0 1

0 0 1

1 1 0

Example:

is a 1-byte key, = (125)10 = (01111101)2

Encryption:

Plaintext:

Base 2 correspondence:

Encryption using XOR:

Ciphertext:

Decryption:

Ciphertext:

Base 2 correspondence:

Decryption using XOR:


11

Plaintext:

1.2.2 Characteristics of symmetric-key cryptosystems

Advantages:

Speed - of the two main types of cryptosystems in use today (symmetric-key and

asymmetric-key), the symmetric-key is the fastest by a large margin. In terms of the

practical computational intensiveness of its underlying operations, symmetric-key

cryptography is considered hundreds of times less intensive than its asymmetrical-key

counterpart. [wiki]

Small key size - the key size for symmetric-key cryptosystems is several orders of

magnitude smaller than the key size of asymmetric-key cryptosystems. [Cri06]

Disadvantages:

Key distribution problem - requires a communication channel that is both confidential and

authentic to exchange the symmetric-key securely between parties. [Men96] To reduce

the impact of being discovered by an opponent, the shared secret key should be changed

regularly and kept secure during distribution and when in service. Also, it is to be noted

that the number of keys required for communicating between parties increases

dramatically with each new party being added to the communication network. As such,

for a network of n users, the number of private keys required is . [wiki]


12

Fig.1.3 Communication scheme in a symmetric-key cryptosystem [Men96]

No digital signing - symmetric-key cryptosystems cannot be used for the authentication

(establishing or confirming a user’s digital identity as authentic) or non-repudiation

(eliminating any possibility of denying having sent or having received a message)

purposes. [wiki]

1.2.3 Block ciphers vs. stream ciphers

A block cipher is a symmetric-key cryptographic scheme, in which the message (either plaintext

or ciphertext) is split into blocks (groups) of equally-sized data. The operations to be applied on

the message as a whole entity, are, in fact, reduced to the successive manipulation (for encryption

or decryption purposes) of the blocks of data composing the message.

Most of the remarkable symmetric-key cryptosystems in use today utilize block ciphers (our two

previous cryptosystem examples, namely the Caesar cipher and the XOR function, both operate

on block ciphers). The flagship of block-cipher cryptosystems today is the AES (Advanced

x x

K

K

y unsecured channel

secured channel

plaintext

source

encryption

key source

plaintext

destination

decryption

Opponent

Alice Oscar Bob


13

Encryption Standard), embraced in 2001 by the National Institute of Standards and Technology

(NIST) as the de-facto standard for protecting classified information in non-governmental

systems. [wiki]

AES works with a block size of 128 bits and three candidate key sizes (of 128, 192 or 256 bits,

respectively). Benefiting from a scalable key-size design, AES can be promoted as a

cryptosystem appropriate for diverse security needs (128-bit key size for secret-level data, while

196 and 256-bit key sizes for top secret data).

Fig.1.4 Block cipher encryption diagram

Fig.1.5 Block cipher decryption diagram

Key K

Ciphertext

block

decryption

Plaintext

block

. . . Ciphertext

block

decryption

Plaintext

block

Key K

Plaintext

block

encryption

Ciphertext

block

. . . Plaintext

block

encryption

Ciphertext

block


14

A stream cipher is a symmetric-key cryptographic scheme, in which the message stream (either

plaintext or ciphertext) is processed byte-by-byte (or bit-by-bit). [wiki] What sets stream ciphers

apart from block ciphers, is that the encryption (and, consequently, decryption) rules are not

restricted to using the same key for each iteration. Unlike in the case of block ciphers, where the

key space K was, in fact, composed out of one-element key sets, for stream ciphers a key K

is made out of several (distinct) keys , , forming a keystream.

The most widespread stream-cipher cryptosystem of today (including its variations) is RC4,

employed in communication protocols such as SSL (Secure Socket Layer) and WEP (Wireless

Encryption Protocol). Because of its age (since 1987), it no longer represents a good information-

security choice for modern needs, although some systems still using it are adequately secure for

practical purposes. [wiki]

Working with stream ciphers can become a very profitable enterprise when the data buffer pool

of the system is severely limited, plaintext comes in quantities of unknowable length, the amount

of computations required to manipulate the data (for encryption or decryption) increases

exponentially with the amount of data processed at once, or when error propagation issues are of

concern to the system.

Fig.1.6 Stream cipher encryption diagram

. . . Plaintext

byte

Ciphertext byte

. . .

Key

encryption

Plaintext

byte

Ciphertext byte

Key

encryption


15

Fig.1.7 Stream cipher decryption diagram

1.2.4 A simple steam cipher encryption-decryption example

The following example uses the Vigenère cipher, a cryptosystem developed by the Italian

mathematician Giovan Batista Belaso, published in the year 1553 A.D. and misattributed to

Blaise de Vigenère. [wiki]

Formalization of the Vigenère cipher [Cri06]:

P = C = , K =

K, ,

Example:



. . . Ciphertext

byte

Plaintext byte

. . .

Key

decryption

Ciphertext

byte

Plaintext byte

Key

decryption


16


0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

encryption keyword GIOVAN, therefore and

Encryption:

Plaintext: vigenere



Ciphertext: BRV_OSYN

Decryption:

Ciphertext: BRV_OSYN



Plaintext: vigenere

1.2.5 Possible attacks on symmetric-key cryptosystems

The objective of an attack against a cryptosystem is deducing the plaintext from the ciphertext,

or, even more dramatically, to recover the encryption-decryption key itself. Careful searching and

identification of potentially “secure” cryptographic functions greatly reduces the chance of

success of such attacks.

Possible attack types and their strategies:

ciphertext-only attack - the opponent has access only to some ciphertext and is trying to

deduce the encryption-decryption key or the plaintext solely by observing the ciphertext.

This is the least efficient type of attack, and, should it succeed, the underlying

cryptosystem is proven to be completely insecure. [Men96]


17

known plaintext attack - the intruder has a quantity of plaintext along with its

corresponding ciphertext and tries to detect the encryption-decryption protocol employed.

Such an attack is one step ahead in terms of efficiency to the ciphertext-only attack,

although not by a significant margin. [Men96]

chosen plaintext attack - the opponent has the opportunity to chose its own plaintexts

and be given their corresponding ciphertexts in return. [wiki]

chosen ciphertext attack - the adversary has access to the decryption equipment (but not

to the decryption key) for a limited amount of time as is able to decrypt any ciphertext of

its choosing. The goal of such an attack is to be able to determine the plaintext from

ciphertexts after the access to the decryption equipment has been terminated. [Men96]

Chapter 2 – Mathematical Foundations of Public-Key Cryptography

18

CHAPTER 2 - MATHEMATICAL FOUNDATIONS OF PUBLIC-KEY

CRYPTOGRAPHY

Consider the cryptosystem (P, C, K, E, D) with key K, E and D the encryption

and decryption rules, respectively. The given cryptosystem is said to be public-key (or

asymmetric-key), if for each key K and encryption-decryption pair depending on

K, it is computationally infeasible [Men96] (impossible for practical goals) to compute

knowing only .

2.1 One-way and trapdoor functions

One-way functions are functions that are easily computable, but infeasible to invert (considering

the average-case complexity of inversion, rather than the worst case). Formally, a mapping

, and sets, is called one-way, if, , is easy to evaluate, but it is

computationally infeasible, for essentially all of the elements , to find any such

that . [Men96]

Trapdoor functions are one-way functions , for which, given an extra information

(called the trapdoor), it becomes feasible to determine an for any such that

. [Men96]

Although there are many contenders for the status of one-way function, the existence of one-way

mappings has neither been proven nor dismissed, remaining as an open conjecture in

cryptography theory. [wiki] The security of each of the public-key cryptosystems is based on the

presumption of ininvertibility of the one-way function the cryptosystem is built upon.


19

Some one-way (trapdoor) function candidates:

Integer Multiplication function (revealing the Integer Factorization Problem)

Let P be the set of all the prime numbers greater or equal to . Let be a

map, where . Even for large primes , it is reasonably easy

to compute , but determing the unique decomposition of a large

natural number into the product of two distinct primes is a hard

computational problem. The Integer Factorization Problem is at the foundation of most

of the one-way (trapdoor) functions utilized in public-key cryptography. Possible

trapdoor (trivial): one of the primes factoring the number n.

Example:

Let and both primes. Then,

. Such a number n is difficult to factor using pen-and-paper methods,

although any contemporary computer would find its unique decomposition in negligible

time. However, the computational cost required for factoring such a natural number

increases exponentially with its size (number of digits). In 2005, a computer network

employing 80 AMD Opteron processors needed several months to factorize a 663-bit

(roughly 200 decimal digit) number [wiki].

RSA encryption function (revealing the RSA Problem)

Let , , distinct primes, . Compute

and (randomly) choose a natural odd number , such that .

Determine , with the property that . Let

. [Cri06] Even when choosing large numbers and , the

computation of is rather forthright, while finding an , given and

, such that is much harder to achieve. Possible trapdoor:

the number , then computing as . It has been asserted (although

not yet proven) that the computational difficulty of determining an inverse modulo ,

without knowing ’s decomposition into primes (the RSA Problem), is computationally

equivalent to the Integer Factorization Problem.


20

Fig.2.1 RSA encryption function , for and

Example:

Let and both primes, , and .

Then, . Given such a

number , it is noticeably hard to determine the corresponding , such that

.

Rabin encryption function (revealing the Modular Square Root Problem)

Let , , distinct primes, . Let

. Even for a large and a large , the computation of is rather

straightforward, while determining an given , such that

is significantly more difficult. Possible trapdoor: one of the primes factoring

the number , which leads to a computationally feasible solution. The Modular Square

Root Problem is proven to be computationally equivalent to the Integer Factorization

Problem [Cri06].


21

Fig.2.2 Rabin encryption function , for

Example:

Let and both primes, and . Then,

. Given such a number

, it is remarkably difficult to determine the corresponding , such that

.

2.2 The Euclidean algorithms

The Euclidean algorithm represents a means of determining the gcd (greatest common divisor)

of two numbers without requiring their factorization. The extended Euclidean

algorithm not only computes the gcd of two numbers , it also finds , such that

.

2.2.1 The Euclidean algorithm

The division algorithm: [Cri06]

such that .


22

The Euclidean algorithm:

.

Example:

Compute .

We have:

Therefore, .

Computational algorithm:

Prototype: function Gcd(a, b) : result

Input: a, b N

Output: N, result =

Pseudocode:

if (a < b) then

temp := a

a := b

b := temp

endif

while (b > 0) do

r := a mod b

a := b

b : = r

endwhile

return a


23

2.2.2 The extended Euclidean algorithm

Bezout’s identity [wiki]

and , such that .

Corollary to Bezout’s identity [Cri06]

Let . Then, .

Example:

Determine u, v , such that .

Using a bottom-up approach to the solution of the example from the Euclidean algorithm, we

obtain:

Therefore, , and .

Computational algorithm: [Cri06]

Prototype: function ExtendedEuclid(a, b) : (d, u, v)

Input: a, b N

Output: and , such that

Pseudocode:

if (a < b) then

temp := a

a := b

b := temp

endif

u2 := 1; u1 := 0; v2 := 0; v1 := 1


24

while (b > 0) do

endwhile

d := a; u := u2; v := v2

return (d, u, v)

2.3 Modular arithmetic

Modular congruence: [Cri06]

Let , . Then, .

A partition of a set , , is a set of subsets of , having the

following properties:

The relation “ ” is an equivalence relation on and its corresponding partition is

. [Cri06] is called the set of congruence classes

modulo . is a commutative ring, where:

For convenience, we may use the standard notation , rather than , to denote the equivalence

class of and the standard equality sign “ ” to denote the equivalence relation “ ” of .

Also, since , , we have , we can safely assume that

, we have , without restricting the generality of the problem.


25

2.3.1 Modular multiplicative inverses

Let , . Then, a number , , satisfying

is called the modular multiplicative inverse (or simply modular inverse) of

modulo .

Properties: [Cri06]

is invertible in such that , in

which case

is a field ⇔ every is invertible ⇔ is prime

Determining a modular inverse:

Let , , . Then, such that:

Using the extended Euclidean algorithm, we can easily obtain .

Example:

Determine the inverse of .

The problem is successively equivalent to:

Applying the extended Euclidean algorithm, we get .


Prototype: function ModularInverse(a, n) : u

Input: , ,

Output:


26

Pseudocode:

(d, u, v) := ExtendedEuclid(a, n)

if (u < 0) then

u := u + n

endif

return u

2.3.2 Modular congruence equations

Let us consider the basic modular congruence equation , where

. Then:

if , the equation has the unique solution

if :

if , the equation has no solutions

if , the equation has the same general solution as the unique solution to the

equation and the solution , for

Example:

Solve the modular congruence equations:

1)

, therefore the solution to the equation is:

2)

, but, since , the equation has no solutions


27

3)

, and, since , the equation is equivalent to ,

whose general solution is:

, thus, the final solution is:


Prototype: function ModularCongruence(a, b, n) : x

Input:

Output: either one of the following:

the unique solution to the equation

(no solution)

the solution vector , with , to the equation

Pseudocode:

d := gcd(a, n)

if (d = 1) then

x := (ModularInverse(a,n) * b) mod n

else if (b mod d 0) then

x :=

else

y := ModularCongruence

for k := 1 to d – 1 do

:=

endfor

endif

return x


28

2.3.3 Modular congruences equations systems

The Chinese remainder theorem: [Cri06]

Consider the modular congruences equations system:

, where:

, , ,

, ,

Then, the system has the unique solution , where:

,

,

Example:

Solve the modular congruences equations system:

At first, we notice that , and , therefore the system is

solvable. We now determine:

, ,

, for :


29


Prototype: function ChineseRemainder(r, a, n) : (x, N)

Input: vectors of size , with ,

Output:

(x, N), such that (x mod N) solves the system,

or

(no solution)

Pseudocode:

existsSolution := true

for i := 1 to r - 1 do

for j := i + 1 to r do

if (Gcd( ) 1) then

existsSolution := false

x :=

endif

endfor

endfor

if (existsSolution = true) then

N := 1

for i := 1 to r do

N := N *

endfor

x := 0

for i := 1 to r do

:=

:= ModularInverse( , )

x := mod N

endfor

endif

return (x, N)


30

2.3.4 Modular exponentiation

Computing numbers of the type , , , , can be very

time-consuming, using the traditional step-by-step multiplication (for e – 1 multiplications) and

applying the modulo after each multiplication (for e – 1 modulo operations). A more powerful

and time-conserving solution to this challenge is the repeated squaring modular

exponentiation method.

Applying the repeated squaring modular exponentiation method: [wiki]

1) Convert the exponent e to binary notation, that is write the exponent as

, , and

2) Using 1), write = =

3) compute =

4) Using 2) and 3), determine

Example:

Let . Compute .

Steps:

1)

2)

3)


31

4)

Computational algorithm: [Sch96]

Prototype: function ModularExponentiation(b, e, n) : result

Input: b, e, n , n 2, b < n

Output: result , result = mod n

Pseudocode:

if (b = 0) then

result := 0

else if (e = 0) then

result := 1

else

while e > 0

if (e mod 2 = 1) then

result := (result * b) mod n

endif

e := e / 2

b := (b * b) mod n

endwhile

endif

return result


32

2.3.5 Modular square roots

A modular square root of a number modulo , , , is a number ,

having the property .

2.3.5.1 Quadratic residues

Consider the modular equation , .

if the equation has a solution ( satisfying it), then is called a quadratic

residue modulo

if the equations lacks any solutions ( satisfying it), then is called a

quadratic non-residue modulo

Legendre symbol: [Kob94]

Let , , prime. We now introduce the Legendre symbol, denoted by ,

having the following definition:

Properties of the Legendre symbol: [Men96]

Let , , primes.

1) Euler’s criterion: , thus:

2) , hence ,

3)

4) Law of quadratic reciprocity:


33

Note: In order to decisively speed up the Legendre symbol calculation, instead of factoring the

number into primes to be able to apply the law of quadratic reciprocity until the symbol

evaluates to , or one could use Euler’s criterion to determine the symbol’s value, relying

on the modular exponentiation algorithm.

Example:

1) Let . Compute .

Applying Euler’s criterion, we have:

Using the modular exponentiation algorithm, we get:

Therefore, is a quadratic non-residue modulo , proving that the

modular equation does not have a solution.

2) Let . Compute .

Applying Euler’s criterion, we have:

Using the modular exponentiation algorithm, we get:

Therefore, is a quadratic residue modulo , certifying that the

modular equation does have a solution.


34


Prototype: function ComputeLegendreSymbol(a, p) : result

Input: a, p N, p 3, p prime

Output: result , result =

Pseudocode:

if (a p) then

a := a mod p

endif

expr := ModularExponentiation(a, (p - 1) / 2, p)

if (expr = p - 1)

result := -1

else

result := expr

endif

return result

Problem

Solve the following modular equation:

,

where quadratic residue modulo .

2.3.5.2 Solving the equation , prime

We already know that the equation has a solution , because

is a quadratic residue modulo . Since, in the ring we have

, ,

the equation admits a second solution . Also, because is odd, it becomes

clear that , thus such an equation will always have two distinct solutions.


35

The solution depends on the choosing of the prime , allowing the next cases:

1)

2)

3)

Case 1) - using the Tonelli-Shanks algorithm [Cri06]

1) Uniquely write , , odd

2) Choose a random number such that is a quadratic non-

residue modulo .

3) Compute .

4) Compute .

5) Determine .

6) Compute , until

One solution is

Case 2) [wiki]

One solution is

Case 3) [Cri06]

One solution is

The other solution is .

Examples:

Solve the following modular equations:


36

a)

At first, we notice that the corresponding Legendre symbol , therefore the

equation has a solution. Seeing that , we find ourselves in the 1st case

of the problem.

1) Writing .

2) Testing for quadratic non-residues modulo .

is a quadratic non-residue modulo

3) Computing

4) Computing

5) Computing

6) Computing

The solutions to the equation are:

b)

We begin by noticing that the corresponding Legendre symbol , hence the

equation has a solution. Observing that , we find ourselves in the 2nd

case of the problem. Accordingly, the solutions to the equation are:


37

c)

We start by computing the corresponding Legendre symbol , thus the equation

has a solution. Remarking that , we find ourselves in the 3rd

case of

the problem.

First, we compute , consequently the

solutions to the equation are:


Prototype: function SolveCase1(a, p) : x

Input: a, p , p 3, p prime, , the equation has

solutions

Output: one solution to the equation

Pseudocode:

t := p - 1

s := 0

while (t mod 2 = 0) do

t := t / 2

s := s + 1

endwhile

d := 2


38

dFound := false

while ( (d < p) and (dFound = false) ) do

if (ComputeLegendreSymbol(d, p) = -1) then

dFound := true

else

d := d + 1

endif

endwhile

A := ModularExponentiation(a, t, p)

D := ModularExponentiation(d, t, p)

DInverse := ModularInverse(D, p)

k := 0

powerFound := false

while ( (k < Power(2, s - 1)) and (powerFound = false) ) do

if (ModularExponentiation(DInverse, 2 * k, p) = A) then

powerFound := true

else

k := k + 1

endif

endwhile

Dk := ModularExponentiation(D, k, p)

x := (ModularExponentiation(a, (t + 1) / 2, p) * Dk) mod p

return x


Prototype: function SolveEquationModP(a, p) : x

Input: a, p , p 3, p prime, the equation has solutions

Output: the solution vector x = (x1, x2) to the equation , x1, x2

Pseudocode:


39

if (p mod 8 = 1) then

x1 := SolveCase1(a, p)

else

if ( (p mod 8 = 3) or (p mod 8 = 7) ) then

x1 := ModularExponentiation(a, (p + 1) / 4, p)

else

if (ModularExponentiation(a, (p - 1) / 4, p) = 1) then

x1 := ModularExponentiation(a, (p + 3) / 8, p)

else

x1 := ( (2 * a) * ModularExponentiation((4 * a), (p - 5) / 8, p) ) mod p

endif

endif

endif

x2 := p - x1

return x = (x1, x2)

2.3.5.3 Solving the equation , prime,

The starting point for solving such an equation is knowing the solution to the equation

. Consider one of the solutions of the previous modular equation. We then

apply the following algorithm:

one solution is

one solution is , , ,

chosen such that (depending on ) satisfies the equation .

…

one solution is , ,

, chosen such that (depending on ) satisfies the equation

.


40

Therefore, the previously-stated algorithm has at most steps, considering the solution to

the equation known from the beginning. The final solution, depending on the

solution and on , for , is:

Example:

Solve the modular equation .

We know from the preceding examples that one solution to the equation

is . Let us begin the algorithm to determine the solution to the equation

.

one solution is:

one solution is:

,

for

The solutions to the equation are:


Prototype: function SolveEquationModPT(a, t, p) : x

Input: a, t, p , t 2, p 3, p prime, the equation has solutions

Output: the solution vector (x[t, 1], x[t, 2]) to the equation ),

x[t, 1], x[t, 2]

Pseudocode:


41

(x[1,1], x[1,2]) := SolveEquationModP(a, p)

currentPower := p

modularPower := p * p

index := 2

while (index t) do

k := 0

kFound := false

while ( (k < p) and (kFound = false) ) do

possibleValue := x[index - 1, 1] + k * currentPower

if (ModularExponentiation(possibleValue, 2, modularPower) = a) then

x[index, 1] := possibleValue

kFound := true

else

k := k + 1

endif

endwhile

x[index, 2] := modularPower - x[index, 1]

currentPower := modularPower

modularPower := modularPower * p

index := index + 1

endwhile

return (x[t,1], x[t,2])

2.3.5.4 Solving the equation , composite

Let be a set of primes, such that . Then, solving this

type of equation is reduced to:

1) Verifying that, for each equation , , is a quadratic residue

modulo , otherwise the equation does not have a solution.

2) Finding the solution to each equation ,


42

3) Determining the solution to each equation , ,

where

4) Obtaining the final solution modulo ( distinct solutions, in fact), by merging all the

previous solutions to the equations , ,

, using the Chinese Remainder Theorem.

Example:

Find the solution to the modular equation .

1) We now check if the following equations are solvable:

. Since is a quadratic residue modulo , the

equation has a solution

. Because is a quadratic residue modulo , the

equation admits a solution

2) We now move on to solving the equations:

has the solution (solved

at a previous example)

. Since , one solution of the equation

is .

Hence, the solution to this equation is

3) Seeing that, in our case, , we may skip this step.

4) There are systems of equations to be solved using the Chinese Remainder

Theorem, each having one solution. The solution to our main equation is the union of

these separate solutions.

The general system is:

,


43

By applying the Chinese Remainder Theorem on this system, we obtain successively:

,

We now solve the equations systems, by replacing and in the general solution of

with their concrete values, respectively.


44

The final solution to the equation is:


Prototype: procedure BackTrackSolutionsModN(m, n, x, equationIndex, solutionIndex,

xFinal)

Input:

a set of primes such that

vector of size (m, 2), with x[i,1], x[i,2] , x[i,1], x[i,2] , , x

is the solution vector to the equations

equationIndex is the index of the equation generating a solution

solutionIndex is the index of the solution inside the vector xFinal

Output: the solution vector xFinal of size , xFinal[j] , xFinal[j] < n,

Pseudocode:

if (equationIndex > m) then

xFinal[solutionIndex] := ChineseRemainder(m, solution, n);

solutionIndex := solutionIndex + 1

else

for i := 1 to 2 do

solution[equationIndex] := x[equationIndex, i]

call BackTrackSolutionsModN(m, n, x, equationIndex + 1, solutionIndex, xFinal)

endfor

endif


45


Prototype: function SolveEquationModN(m, n, x) : xFinal

Input:

a set of primes such that

vector of size (m, 2), with x[i,1], x[i,2] , x[i,1], x[i,2] , , x

is the solution vector to the equations

Output: the solution vector xFinal of size , xFinal[j] , xFinal[j] < n,

Pseudocode:

solutionIndex := 1

call BackTrackSolutionsModN(m, n, x, 1, solutionIndex, xFinal)

return xFinal

2.4 Primality testing methods

A primality test is an algorithm used to determine whether or not a given number ,

is prime. It is important to distinguish between primality testing and integer factorization

testing. Although in the case of naïve primality tests, the integer factorization is implicit,

competent primality tests do not involve the decomposition (if any) of the candidate prime into

its proper factors.

Types of primality tests: [wiki]

naïve (inefficient deterministic methods) - trial division, Sieve of Eratosthenes

slow deterministic methods (requiring exponential time) - cyclotomy test, elliptic curve

primality test

fast deterministic methods (requiring polynomial time) - AKS primality test [Agr04]

probabilistic methods (requiring polynomial time) - Fermat, Solovay-Strassen, Miller-

Rabin primality tests

For cryptography purposes, the fastest and most efficient primality tests are the probabilistic ones

(with the Miller-Rabin test being the most effective), their downside residing in the fact that,

regardless of the number of test iterations applied on the candidate prime, the candidate number


46

cannot be proven to be prime with 100% confidence, although its compositeness (if any) can be

established with absolute certainty.

2.4.1 Fermat primality test

Let , and . The map is called

Euler’s totient function. [Cri06]

Euler’s totient function properties: [Cri06]

1) if ,

2) if p is prime,

3) if , p prime,

4) if ,

Fig.2.3 Euler’s totient function ,


47

Euler totient theorem [Sta05]

Let , , then

Fermat’s little theorem [Men96]

Let , prime and . Then, . Fermat’s little theorem is a

particular case of Euler’s totient theorem, in which is a prime number, and, by applying the

property 2) of Euler’s totient function, we obtain .

Fermat’s primality test

Let , . If , then is prime.

Let , odd and composite, . Then, is said to be pseudoprime to the base , if

. [Men96] Put slightly differently, is a number pretending to be prime, by

passing the Fermat test for a given base . The probability of a composite number passing

Fermat’s tests for different bases is at most . [Cri06] After passing 6 different

Fermat’s tests, the probability that the tested number is prime is at least .

A defining weakness of Fermat’s test are the Carmichael numbers. A natural composite number

is called a Carmichael number, if it passes Fermat’s test for any base . It has been proven that,

for a large-enough , the number of Carmichael numbers less than is greater than , and, as a

consequence to this fact, that the set of Carmichael numbers is infinite [Men96].

Distinguishing the Carmichael numbers

Let , odd and composite. Let be a set of primes, such that

.

if , for some , then is not a Carmichael number

if and , for every , then is a Carmichael number


48

Carmichael number example:

Let . Let , such that . Also, ,

and . Therefore, is a Carmichael number.

Fermat’s primality test example:

Let

1)

2)

3)

4)

5)

6)

Seeing that, for 6 bases of our choosing, the number has passed Fermat’s

primality test, we can conclude that is a prime, with a probability of at least

.

Let

1)

The number failed Fermat’s primality test for the base , therefore we can

conclude that is not a prime, with complete confidence.


Prototype: function FermatTest(n, k) : res

Input: n N, n 3, k *

Output: res , corresponding to being either composite (with

complete certainty) or prime

Pseudocode:

for i :=1 to k do

Randomly choose a, 1 < a < n - 1

result := ModularExponentiation(a, n - 1, n)


49

if (result 1) then

return COMPOSITE

endif

endfor

return PRIME

2.4.2 Miller-Rabin primality test

Let be a prime number, . Uniquely write as , , odd. Let

, . Then, either:

or

, for some [Men96]

Miller-Rabin primality test

Let be an odd number, . Uniquely express as , , odd. Let

, . If either:

or

, for some

then is prime.

A natural composite number , , , , odd, is said to be strong

pseudoprime to the base *, if either or , for some

. Regarded from a distinct perspective, is a number acting as a prime, by passing

the Miller-Rabin test for a given base . The maximum probability of a composite number

passing the Miller-Rabin test for different bases is [Cri06]. After passing 3

different Miller-Rabin tests, the probability that the tested number is prime is at least

.


50

Miller-Rabin primality test example:

Let ⇒

1) ⇒

1.

2.

3.

4.

5.

2) ⇒

1.

2.

3.

4.

5.

6.

3) ⇒

1.

2.

3.

4.

5.

Observing that our number has passed the Miller-Rabin test for 3 different

bases, we can infer that is a prime, with a probability of at least

.

Let ⇒

1) ⇒

1.


51

2.

Seeing that our number has failed the Miller-Rabin test for the base , we

can claim that is not a prime, with complete confidence.


Prototype: function MillerRabinTest(n, k) : res

Input: n N, n 3, k *

Output: res , corresponding to being either composite (with

complete certainty) or prime

Pseudocode:

Write , r,s *, r odd

for i :=1 to k do

Randomly choose a, 1 < a < n - 1

result := ModularExponentiation(a, r, n)

if ( (result 1) and (result n - 1) ) then

j :=1

while ( (j s - 1) and (result n - 1) ) do

result := (result * result) mod n

if (result 1) then

return COMPOSITE

endif

j := j + 1

endwhile

if (result n - 1) then

return COMPOSITE

endif

endif

endfor

return PRIME


52

2.4.3 The Miller-Rabin test vs. Fermat’s test

Correctness. The Miller-Rabin test is a significant improvement over Fermat’s test in

terms of correctness, since, unlike Fermat’s, it does not contain a characteristic weakness

regarding a particular type of numbers (like Fermat’s Carmichael numbers) that would

render the test completely ineffective for that category of numbers.

Speed. The Miller-Rabin average-case amount of computations is much smaller than

Fermat’s, becoming approximatively equal to Fermat’s amount of computations only for

the worst-case.

The algorithms for both tests employ operations of the same computational

complexity.

Both tests can determine composite numbers with absolute certainty. Since the set

of strong liars (bases for which a given composite number passes the Miller-

Rabin test) is a narrow subset of the set of Fermat liars (bases for which a given

composite number passes Fermat’s test), the Miller-Rabin test generally requires

a smaller amount of bases, to be tested against a number in order to prove its

compositeness, than Fermat’s.

Fig. 2.4 Relationship between the Fermat and the strong liars for any composite

number [Men96]

strong liars for

Fermat liars for


53

The probability that a natural number is a prime, is, for both tests, directly

dependent on the amount of bases tested against . However, since the

probability of a number being prime is at least for the Miller-Rabin test

and at least for Fermat’s test, it becomes clear that the Miller-Rabin test

requires only half of the bases Fermat’s test would need in order to achieve the

same confidence on the primality of .

Chapter 3 – Public-Key Cryptosystems

54

CHAPTER 3 - PUBLIC-KEY CRYPTOSYSTEMS

This chapter introduces the RSA and the Rabin public-key cryptosystems, describing their key-

generation, encryption and decryption algorithms, covering their implementation options,

security issues and real-world applicability, as well as outlining similarities and differences

between the two cryptosystems.

3.1 The RSA cryptosystem

The RSA cryptosystem was first published in 1977, as the joint effort of Ron Rivest, Adi Shamir

and Leonard Adleman from the Massachusetts Institute of Technology, USA. [wiki]

3.1.1 Description [Men96]

Key generation

Summary: Entity generates the keys required for the encryption and decryption processes.

1) Generate two random and distinct prime numbers, and , having roughly the same size.

2) Compute:

, , where represents Euler’s totient

function.

3) Select a random number , , such that .

4) Determine , , such that , that is

.

5) The keys are:

the public key:

the private key:


55

Encryption

Summary: Entity encrypts a message , using the public key received from entity .

1) Receive the public key from .

2) Express the message plaintext as a number , .

3) Compute , .

4) Send the ciphertext to .

Decryption

Summary: Entity decrypts the encrypted message received from , using the private key .

1) Receive the ciphertext from .

2) Recover the message plaintext, by computing .

Reliability of the decryption algorithm

We need to prove that . Since and are primes, , it is

enough to prove that:

.

Because , such that .

We now demonstrate that . The subsequent proof is split into the following

cases:

if , being prime, it is clear that is a multiple of , therefore

and, consequently, .

if , we apply Fermat’s theorem and obtain

.

The same reasoning can be applied analogously for proving that .


56

3.1.2 Encryption-decryption example

Formalization of the RSA cipher:

P = C = , K = ,

, ,

Example:




0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

The plaintext is split into blocks of length , while the ciphertext is divided into blocks

of length , fulfilling the condition ⇒

Encryption:

Plaintext: rsa

Splitting: rs / a_


rs →

a_ →



57

Ciphertext: _MBAQG

→ _MB

→ AQG

Decryption:

Ciphertext: _MBAQG

Splitting: _MB / AQG


_MB →

AQG →


Plaintext: rsa

→ rs

→ a_

3.1.3 The security of the RSA cryptosystem

1) The factoring problem [Men96]

An adversary wanting to decrypt a ciphertext message into the plaintext message ,

knowing only the public key is faced with the RSA problem. Such an opponent

must try to:

factor in order to determine and, consequently, . Up to now, there is no

efficient algorithm for determining the proper factors of a given composite

number.

or

if, as an extra acquired information, the opponent also knows the decryption

exponent , he/she can easily factor as follows:

because ⇒ , for certain


58

since , , , due to Euler’s totient theorem, we

have

determine the unique , such that , odd

then, , , such that, for at least half of the numbers

, , and

after finding a number , satisfying the previous relations for a single

chosen number , , a proper factor of is revealed as

Usage: The opponent selects random numbers , , until

the conditions above are fulfilled. The expected number of trials until is

factored is .

2) Small encryption exponent [Men96]

In order to speed up the encryption process (by reducing the amount of operations

involved), one can select a small encryption exponent to be used for each encryption.

However, let us consider the case in which the same plaintext message is encrypted is

sent to destinations using the same encryption exponent , but distinct moduli ,

, . An eavesdropper intercepting messages out of the sent messages is

faced with the following system:

, where

One notices that, in most of the real-life situations, , , .

By applying the Chinese remainder theorem, one obtains a solution , with

. Since and, as such, , one can reach the plaintext message

simply by extracting the integer -th order root of .


59

There are two solutions to this issue:

refraining from using small encryptions exponents, like , in favor of larger

ones, an usual choice being

salting the message , that is appending a distinct and appropriately long

pseudorandom bitstream, prior to each encryption modulo

3) Forward search attack

If a ciphertext message is very short and/or predictable, an eavesdropper can decrypt it

simply by encrypting all possible plaintext messages , until is obtained. Such an attack

can be prevented by salting the message, prior to its encryption.

4) Small decryption exponent [Cri06]

If is a small number (the most natural case) and

the size of the decryption exponent is less than of the size of the modulus , there

exists an algorithm through which the decryption exponent can be determined knowing

only the public key .

Such a situation can be avoided by choosing at first the decryption exponent ,

, such that and ’s number of digits exceeds of the

size of the modulus and only afterwards determine the encryption exponent ,

, such that , that is .

5) Adaptive chosen ciphertext attack [Cri06]

Let be plaintext messages, whose correspondent ciphertexts are . We know

that .

Let us assume that an opponent desires to decrypt the cyphertext ,

having access to the decryption equipment for a timespan and being able to decrypt any

chosen ciphertext, other than itself, without posessing the decryption key . This attack

allows the adversary to select a random number , conceal the ciphertext as


60

and present it to the decryption machine. In turn, the decryption

machine provides the opponent with , out of

which the adversary determines the plaintext message as .

To prevent such attacks, some structural constraints should be placed upon the plaintext

messages. If a decrypted plaintext violates any of the imposed constraints, its

encryption should be flagged as fraudulent and rejected by the decryption machine.

6) Common modulus attack [Cri06]

If a central trusted authority designates a single public key modulus and one distinct

encryption-decryption exponent pair for each entity in a network, the following

situations may arise:

any entity in the network can easily factor , since knowing the private key for

a public-key pair allows the user to easily factor (as shown at 1)) and

then to determine each private key in the network

an opponent outside the network who intercepts a message being encrypted and

sent to at least two different entities has a change to decrypt the message as

follows:

If , then, using the corollary to the extended Euclidean theorem,

we get , for some . Hence, we have:

Because, with a high probability, , an eavesdropper is almost

always able to decrypt the plaintext , without requiring knowledge of the private

keys .

Both of the previously presented situations can be avoided by providing each entity in the

network with a unique modulus .


61

7) Cycling attacks [Cri06]

Let be a ciphertext. Since an encryption is, in fact, a permutation on the

message space , such that and, consequently,

. As such, finding a for which means obtaining the

private key .

To mount such an attack, an eavesdropper should successively compute ,

until . However, this algorithm can be viewed as a factorization algorithm,

and, as any factorization algorithm to this day, needs exponential time to succeed.

Therefore, for a sufficiently large modulo , this type of attack does not push a problem

to RSA.

8) Message concealing [Men96]

A message may be considered unconcealed if . Regardless of the

choosing of the modulus and the encryption exponent , there are always some

unconcealed messages ( ). If and are random primes and if is either

chosen at random or is a small number ( or ), then the proportion of

these unconcealed messages is negligibly small, so they do not pose a threat to the

security of RSA.

3.1.4 Guidelines to a successful RSA implementation

The size of the modulus should be of at least 1024 bits (128 bytes), in order to avoid its

factorization into primes. Considering the rapid improvement in computer technology,

using even the previously-considered suitable 768 bit (96 bytes) modulus has become a

rather risky enterprise.

The primes and , whose product is the modulus , should be of roughly the same size,

but extra care must be taken that is not very small, otherwise could be factored by


62

trial division by all the natural numbers close to . Random choosing of and

generally eliminates this problem.

To thwart any non-brute-force attempt to guess the prime numbers and used to factor

the modulus , the random prime generation should be intractable. The best solution to

this would be using a true random generator (such as a device to measure the radioactive

decay of uranium atoms).

To avoid salting the message (required when using small encryption exponents like

), one could use a somewhat larger, but still computation-wise efficient encryption

exponent (like , which only requires modular squarings and one

modular multiplication).

If, due to the choosing of the encryption exponent , the decryption exponent

has the size less than of the size of the modulus , then, either the

selection of and, subsequently, of finding its inverse must be repeated until is of

appropriate size, or a sufficiently large decryption exponent shall be chosen at first, and

the encryption exponent computed as .

The size of the message should be large enough, in order to foil attempts to extract the

integer -th order root of , that is:

⇒

The size of the message may be increased through salting to reach the required length.

Although speed in not quite the concern for RSA as it is for symmetric-key

cryptosystems, efficient polynomial-time algorithms should be used for all the operations

involved in the process:

key generation - the Miller-Rabin primality test (to check if a randomly

generated number is prime) (see 2.4.2), the extended Euclidean algorithm

(to compute the decryption exponent as the inverse of the encryption

exponent modulo ) (see 2.3.1)


63

encryption and decryption - the repeated squaring modular

exponentiation method (to compute or )

(see 2.3.4)

3.2 The Rabin cryptosystem

The Rabin cryptosystem specifications were published in January 1979 by Michael Rabin, in an

effort to improve the already existing RSA cryptosystem, by presenting a cryptographic solution

whose security was mathematically proven to be based on the difficulty of the integer

factorization problem.

3.2.1 Description [Men96]

Key generation

Summary: Entity generates the keys required for the encryption and decryption processes.

1) Generate two random and distinct prime numbers, and , of roughly the same size.

2) Compute

3) The keys are:

the public key:

the private key:

Encryption

Summary: Entity encrypts a message , using the public key received from entity .

1) Receive the public key from .

2) Express the message plaintext as a number , .

3) Compute , .

4) Send the ciphertext to .


64

Decryption

Summary: Entity decrypts the encrypted message received from , using the private key

.

1) Receive the ciphertext from .

2) Recover the 4 message plaintexts , , , satisfying ,

(see section 2.3.5)

3) Discern which of the 4 message plaintexts , , , resembles the original

message .

3.2.2 Encryption-decryption example (without use of redundancy)

Formalization of the Rabin cipher (without redundancy):

P = C = , K = ,

, such that ,

Example:




0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

The plaintext is split into blocks of length , while the ciphertext is divided into blocks

of length , fulfilling the condition ⇒

Encryption:

Plaintext: rabin

Splitting: rab / in_



65

rab →

in_ →


Ciphertext: _QAE_LFN

→ _QAE

→ _LFN

Decryption:

Ciphertext: _QAE_LFN

Splitting: _QAE / _LFN


_QAE →

_LFN →


4 possible roots:

4 possible roots:

Plaintext: rabin

→ rab

→ in_

3.2.3 Use of redundancy

The most obvious drawback of the Rabin cryptosystem in comparison to RSA is the ambiguity of

the decryption, the user being faced with choosing which of the four decryption possibilities is, in

fact, the initially encrypted message. One can alleviate this issue by adding a redundancy to the

message prior to its encryption and, after decryption, checking which of the four possible values

matches the redundancy.


66

More formally, let us consider the initial message , written in the base , as

, where are the digits of in the base . To add a

redundancy to the message , one adds , digits to the end of the representation of ,

matching the last digits of as follows:

before replication:

after replicating the last digits of :

Put differently, one observes that replicating the last digits of the representation of (adding a

-digit size redundancy) can be seen as:

,

where is the message before replication and is the message after its last digits were

replicated.

After the redundancy has been added to , the message is encrypted as usually as

. When the decryption is performed, the user can easily distinguish which of the four

messages is the message , by selecting the only message of the four with

matching redundancy. After the solution has been found, the redundancy is removed as follows:

,

where is the initial message, prior to the applying of the redundancy, while is the message

with corresponding redundancy, obtained through decryption.

Note:

1) To ensure that only one of the messages has matching redundancy, the

added redundancy should be long enough to avoid ambiguity. Today’s standards impose a

redundancy of at least 64 bits.

2) To allow the use of redundancy, the initial message must be small enough to

accommodate a -digit replication, that is:

, where is the size of the modulus

If the initial message is too long for such a purpose, it can be split into two messages

and , for which, individually, the redundancy adding is applicable.


67

3.2.4 Encryption-decryption example (with use of redundancy)

Formalization of the Rabin cipher (with redundancy):

P = C = , K = ,

the message is padded with its redundancy

, such that and the redundancy matches

the redundancy is removed from the solution

Example:




0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

redundancy of decimal digits

The initial plaintext is split into blocks of length , while the ciphertext is divided into

blocks of length , fulfilling the conditions:

⇒

Encryption:

Plaintext: rabin

Splitting: ra / bi / n_


ra →

bi →

n_ →

Adding the replication ( decimal digits):


68

→

→

→


Ciphertext: EOYPBFZMETJH

→ EOYP

→ BFZM

→ ETJH

Decryption:

Ciphertext: EOYPBFZMETJH

Splitting: EOYP / BFZM / ETJH


EOYP →

BFZM →

ETJH →


4 possible roots: → is

the only value to match the replication →

4 possible roots: → is the

only value to match the replication →

4 possible roots: → is the

only value to match the replication →

Plaintext: rabin

→ ra

→ bi

→ n_


69

3.2.5 The security of the Rabin cryptosystem

1) The factoring problem

An opponent desiring to decrypt a ciphertext message into the plaintext message ,

knowing only the public key , is faced with the modular square root problem. The

only known efficient algorithm to determine out of the equation

requires ’s decomposition into primes and, as such, the modular square root problem is

equivalent in terms of difficulty to the integer factorization problem.

2) Small encryption exponent

Let us consider the highly probable situation (much more so than in the case of RSA) in

which the same plaintext message is encrypted is sent to entities, using distinct

moduli , , . An eavesdropper intercepting messages out of the sent

messages is faced with the following system:

, where

We can remark that, in most of the real-life situations, . By applying the

Chinese remainder theorem, one obtains a solution , with . Since

and, as such, , one can reach the plaintext message simply by

extracting the integer square root of .

There is but a single workaround to this situation, namely salting the message , that is

appending a distinct and appropriately long pseudorandom bitstream, prior to each

encryption modulo .

3) Forward search attack

As in the case of RSA, a ciphertext message that is very short and/or predictable can be

decrypted by an opponent simply by encrypting all possible plaintext messages , until

is obtained. Such an attack is generally not an issue to the Rabin cryptosystem, as the

salting of messages prior to their encryption is mandatory (see also 2)).


70

4) Chosen ciphertext attack [Men96]

To be able to mount such an attack, an opponent having access to the decryption machine

(but not to the decryption key) encrypts a plaintext as and sends the

ciphertext to the decryption machine. Two situations may arise, following the previous

assumption:

The decryption machine returns all of the four possible plaintexts , , ,

. The opponent searches for a plaintext out of the four retrieved plaintexts,

having the property . Irrespective of the modulus or the initial

message , there are always two plaintexts satisfying the aforementioned

property. Then, a proper factor of the modulus is obtained as .

The decryption machine returns only one (probably the smallest root) of the four

possible plaintexts, namely the plaintext . If the received plaintext fulfills the

property , then a proper factor of the modulus can be

determined as . If , then the process of

encrypting a chosen plaintext and sending it to the decryption machine to be

decrypted is repeated, until can be factored.

To deter such attacks from being successful, it is enough for the decryption machine to

request the existence of a redundancy in any plaintext , prior to its encryption.

If the redundancy has indeed been added to the plaintext , the decryption of its

corresponding ciphertext provides the eavesdropper with merely the same

plaintext that he/she encrypted.

If the redundancy has not been added by the adversary, the machine fails to

distinguish the correct plaintext and disregards the ciphertext submitted as

fraudulent or damaged.

5) Adaptive chosen ciphertext attack

Let be plaintext messages, whose correspondent ciphertexts are . It is known

that .


71

Assuming that an opponent who has access to the decryption equipment for a period of

time desires to decrypt the cyphertext , while being able to decrypt any

chosen ciphertext, other than itself. This attack permits the opponent to choose a

random number , conceal the ciphertext as and forward it

to the decryption machine. In return, the decryption machine gives the opponent the

decryption of , that is , out of which the opponent computes the

plaintext message as . For this type of attack to succeed, the use of

redundancy to distinguish between the four roots of the modular squaring equation is

necessary.

To avoid such attacks, some structural constraints should be placed upon the plaintext

messages. If a decrypted plaintext violates any of the imposed constraints, its

encryption should be regarded as fraudulent and rejected by the decryption machine.

6) Message concealing

A message shall be regarded as unconcealed if . Regardless of the

choosing of the modulus , there are always some unconcealed messages ( ). If

and are random primes, then the number of these unconcealed messages is

insignificantly small, posing no real threat to the security of the Rabin cryptosystem.

3.2.6 Guidelines to a successful Rabin implementation

A size of the modulus of at least 1024 bits is recommended to render brute-force attacks

of trying to factor useless. Since Rabin’s security is based on the difficulty of the

factorization of large integers, the constraints regarding the size of the modulus are the

same as in the case of RSA.

As in the case of RSA, some care must be taken when choosing the primes and ,

whose product is the modulus . and ought to be of roughly the same size, but

should not be very small, otherwise could be factored by trial division by all the natural


72

numbers close to . Random choosing of and eliminates this problem for most of

the situations.

Considering the significant amount of extra decryption computations (the Tonelli-Shanks

algorithm - see 2.3.5.2) when using a modulus with a prime factor , the

random prime generation algorithm should eliminate primes having such a form.

To impede any non-brute-force attempt to guess the prime numbers and factoring the

modulus , the random prime generation should be intractable. The best answer to this

issue would be relying on a true random generator (such as a device to measure the

atmospheric noise at a given time).

Any message plaintext that is to be encrypted using the Rabin cryptosystem should have a

redundancy of at least 64 bits in order to be able to easily discern between the four

message plaintexts obtained at decryption, so that no more than one message has the

expected redundancy.

Although not a general issue to the RSA, salting any message (regardless of its initial

length) is of the utmost importance to the security of the Rabin cryptosystem, since, more

often than not, the same message can be encrypted and sent to at least two destinations,

using different moduli (see 3.2.5.2)). In this case the salt must not necessarily be

random, but differ for each modulus . A good size for the mandatory salt of any Rabin-

encrypted message would be 64 bits.

The size of the message (after the redundancy and the compulsory salt have been

added) should be large enough, in order to make attempts to extract the integer square

root of impossible, that is:

⇒

The size of the message may be increased through extra salting, for it to reach the

required length.


73

Even if speed might be regarded as a second-rate concern to the Rabin cryptosystem (as

public-key cryptography is much slower than symmetric-key cryptography, anyway),

efficient polynomial-time algorithms ought to be used for all the operations involved in

the process:

key generation - the Miller-Rabin primality test (to check if a randomly

generated number is prime) (see 2.4.2)

decryption - the algorithm for solving a modular squaring equation,

depending on the decomposition of the modulus into its proper factors

(see 2.3.5)

3.3 Applications of the RSA and the Rabin cryptosystems

It is widely known that public-key cryptography came into play to address the two most

significant flaws of symmetric-key cryptography:

key distribution issue - Prior to being able to communicate securely over insecure

channels (by using data encryption), the participants were forced to rely on the exchange

of the encryption-decryption keys using secure channels, other than the ones used for the

actual communication.

authentication problem - Symmetric-key cryptography did not provide any means of

authenticating the parties involved in the communication, neither did it offer any insight

as to the data integrity of the transmitted message.

However, since the public-key cryptosystems are several orders of magnitude (hundreds of times,

to be computationally precise) slower than symmetric-key cryptosystems, public-key

cryptosystems cannot actually supersede the symmetric-key ones. As such, the role of public-key

cryptography is restricted to providing auxiliary support to existing symmetric-key

cryptosystems. Consequently, the real-life applications of public-key cryptography might be

resumed as follows:


74

encryption of small amounts of data - The large disparity in terms of speed between the

public-key cryptography and its symmetric-key counterpart becomes non-essential when

small amounts of data are to be encrypted and decrypted. If such data is subjected to

transmission over an unsecured connection, then public-key cryptography (like RSA or

Rabin) becomes the only reasonable choice. Such situations mainly involve banking

transactions over the Internet, when the user provides the transactions front-end (the

website) with his/her confidential banking account (or credit card) credentials.

exchange of keys of symmetric-key cryptosystems - A central authority of a computer

network, be it either a LAN (local area network) or a virtual network (built of computers

connected over the Internet), might deem necessary to distribute a common symmetric-

key cryptosystem key (like an AES key) to all of its subjects. Such a key would then be

used for securing (by encrypting) any future communication between the parties in that

network. Although in its later stages, such a scenario’s success would only depend on the

security of the symmetric-key cryptosystem involved, until the symmetric-key reaches

each of its desired destinations, the scenario’s security depends heavily on the public-key

cryptosystem used. The steps required for such an undertaking are:

The central authority generates a symmetric-key cryptography key to be used

for any secure data exchange between the parties of the network.

Each protagonist (party) , in the network (other than the central

authority itself) generates its own public-key cryptography key (containing a

public-key and a private key), using a previously agreed-upon cryptosystem.

Every participant , then sends its public-key to the central authority over the

unsecured channel.

The central authority encrypts the same plaintext (the symmetric-key

cryptosystem key) using every available public key received from the parties,

obtaining the distinct ciphertexts , .


75

The central authority then sends each ciphertext to its corresponding

destination, again over the unsecured channel.

Each participant , having received its ciphertext , decrypts it using its own

distinct private key, obtaining the message (the symmetric-key cryptosystem

key sent).

At this point all the parties involved are in possession of the symmetric-key

cryptosystem key (whose security remains intact, due to the use of public-key

cryptography for its transmission) and are able to rely on it to secure each future

data exchange over the network.

digital signatures - Signatures are used for two purposes: the authentication beyond any

doubt of the parties involved in the communication (also the non-repudiation of any

messages sent) and the integrity check of the corresponding messages.

3.3.1 Digital signatures explained

A signature is a 5-tuple (P, A, K, S, W), having the following properties: [Sti95]

P is a finite set of possible messages

A is a finite set of possible signatures

K is a finite set of possible keys (the keyspace)

S is a finite set of possible signing functions

W is a finite set of possible verification functions

K, there are:

a signing function : P → A, S

a verification function : (P A) → , W

a fundamental constraint:

, P, A


76

Due to the time constraints involved in message encryption and decryption as well as bandwidth

limitations, the signing function is not applied to the whole message that is to be

transmitted, but to the hash of the message , that is .

3.3.1.1 Hash functions

A hash function is a transformation that takes a variable-size input and returns a fixed-size

output string, namely the hash value .

Properties of the hash functions: [Cri06]

the input message can be of any length

the output hash is of fixed, predetermined length

is a one-way function, without any possible trapdoors (see 2.1)

must be collision-free:

weak collision-free - given a message , it is computationally infeasible to find a

message , , such that

strong collision-free - it is computationally infeasible to find any two messages

and , such that

Hash functions, of which the most used today are MD5 and SHA-1, are employed to ensure

message integrity in areas such as cryptography, web downloads integrity and peer-to-peer

networking.

3.3.1.2 Digital signing template

Suppose two entities identified, for the sake of simplicity, as Alice and Bob desire to

communicate and their only means of communication involves an unsecured channel (like a

telephone line, the Internet, e-mail, etc.). Let us assume that Alice desires to send an encrypted

message to Bob and, as such, beyond the actual message decryption, Bob is faced with two

additional challenges:


77

authentication - ensuring that the received message came indeed from Alice and not

from an intruder

integrity - certifying that the message has neither been damaged, nor forged, during its

transmission over the channel

Let us assume that the message had already been sent by Alice and received by Bob and whose

secure transmission was achieved using a cryptosystem of the protagonists’ choice (public-key or

symmetric-key). The following template chronologically details the steps required for a

successful digital signing and signature verification of the message involved in the

aforementioned transmission:

1) Alice generates her public-key cryptosystem key to be used for the message signing.

2) Alice sends the public key part of the generated key to Bob.

3) Alice uses a hash function (like MD5), whose implementation is also available to Bob,

to create the constant-sized hash of the message that she is willing to send

to Bob.

4) Alice encrypts the hash using the private-key part of her message signing key,

effectively obtaining the digital signature of the message .

5) Alice sends the digital signature to Bob.

6) Bob decrypts the digital signature provided by Alice, using the public-key part of Alice’s

message signing key, obtaining Alice’s hash of the message .

7) Bob applies the same hash function as Alice on the message , obtaining his own hash

.

8) Bob compares the hash (that he computed) with Alice’s hash (that he previously

decrypted). If there is a match, than Bob becomes certain that the message came

indeed from Alice and that it has not been damaged or forged. If not, then either the

message did not come from Alice, but from an opponent, or the message came from

Alice, but was damaged or forged during the transmission, or a mixture of these

situations. Either way, if there has been no match, Bob clearly knows that the message he

obtained is not reliable.


78

3.3.1.3 The RSA signature scheme

We assume that entity A (Alice) signs the message and that entity B (Bob) verifies the signature.

Key generation [Men96]

Summary: Entity generates the keys required for the digital signing and signature verification

processes.


2) Compute:

, , where represents Euler’s totient

function.

3) Select a random number , , such that .

4) Determine , , such that , that is

.

5) The keys are:

the public key:

the private key:

Digital signing

Summary: Entity digitally signs the message , using its own private key .

1) Compute , , where is an integer representing the hash of the

message , obtained by applying a hash function (like MD5 or SHA-1) agreed upon with

entity .

2) Compute the signature , .

3) Send the digital signature to .

Signature verification

Summary: Entity verifies the digital signature received from , using the public key

received from entity .


79

1) Receive the digital signature from entity .

2) Obtain ’s hash , by decrypting the digital signature.

3) Compute its own hash of the message , using the same hash

function as entity .

4) Verify if , otherwise dismiss the signature as fraudulent and deem the

message unreliable.

3.3.1.4 The Rabin signature scheme

As in the case of the RSA signature scheme, we assume that entity A (Alice) signs the message

and that entity B (Bob) verifies the signature.

Key generation [Men96]

Summary: Entity generates the keys required for the digital signing and signature verification

processes.


2) Compute

3) The keys are:

the public key:

the private key:

Digital signing

Summary: Entity digitally signs the message , using its own private key .

1) Compute , , where is an integer representing the hash of the

message , obtained by applying a hash function (like MD5 or SHA-1) agreed upon with

entity .

2) Compute the signature , where , (see 2.3.5.4).

3) Send the digital signature to .


80

Signature verification

Summary: Entity verifies the digital signature received from , using the public key

received from entity .

1) Receive the digital signature from entity .

2) Obtain ’s hash as , by decrypting the digital signature.

3) Compute its own hash of the message , using the same hash

function as entity .

4) Verify if , otherwise dismiss the signature as fraudulent and deem the

message unreliable.

Note:

1) When trying to compute the signature , one might apparently reach a dead end, if is

not a quadratic residue modulo (see 2.3.5.1). Such an issue can easily be solved by

adding a small number of random bits to the hash , until becomes a quadratic

residue modulo and, as such, its signature can be computed.

2) After obtaining the four modular square roots of the hash , one might choose any of

these to become the signature .

Chapter 4 – Implementing the RSA and the Rabin Cryptosystems

81

CHAPTER 4 - IMPLEMENTING THE RSA AND THE RABIN

CRYPTOSYSTEMS

The two desktop applications, named RSA Cryptosystem Application and Rabin Cryptosystem

Application, respectively, allow the user to fully understand, appreciate and successfully use

state-of-the art public-key cryptography -bit encryption of data, employing the RSA and the

Rabin cryptosystems, respectively. Both software products have been developed in the C#

programming language and utilize the .NET Framework 2.0.

In terms of the graphical user interface, both applications are made out of four sections (GUI

tabs), each section expressing a part of the fundamental functionality of a public-key

cryptosystem. The sections (tabs) and their functionalities are:

Primes Generation – the random prime generation component, using a powerful true

random generator implementation.

Key Generation – the public and private key generation component, using the primes

obtained in the Primes Generation section.

Encryption – the content encryption section, which encrypts the data (any file) chosen by

the user, according to a public key obtained in the Key Generation section, corresponding

to a public-key cryptosystem (RSA or Rabin).

Decryption – the content decryption section, whose purpose is to decrypt the data (any

file encrypted in the Encryption section), with respect to its corresponding private key,

received from the Key Generation section and corresponding to one of the public-key

cryptosystems (RSA or Rabin).

This software artifact has been overhauled (revisioned) up to the version (for the RSA

cryptosystem) and (for the Rabin cryptosystem) as well as extensively tested, ensuring that

the software is (virtually) bug-free while, at the same time, favoring only the most efficient and

fast algorithms of the day, in order to distinguish it from other public-key cryptography solutions.

These two programs (the implementation of the RSA and Rabin cryptosystems, respectively)

present all the qualities expected in a software product, perhaps not quite up to the standards of


82

commercial software, but surely up to the demands of free and open-source solutions. Those

features could be succinctly summarized as:

General purpose software (security being a widespread concern)

Simple and intuitive GUI (able to present a variable amount of information, depending on

the user’s level of knowledge and interest in the matter, while, at the same time, hiding

any obscure and insignificant details)

Support for the serializing of data (primes and keys), to be able to successfully reuse it.

True randomness for the generated primes, as well as state-of-the-art -bit encryption,

rendering the system as secure as possible (even for less-resourceful governmental

agencies), an average PC of today being capable of breaking the security of the system

through brute-force attacks in a matter of tens of years.

Well chosen data structures (for representing large integers) and powerful polynomial-

time algorithms (for large integer manipulation and underlying operations required by the

cryptosystem involved), resulting in the best possible application execution speed.

Taking into account the disparity in terms of speed between public-key and private-key

cryptography (see 3.3), the utility of the application can be expressed as follows:

Encryption of small amounts of data (any file up to KB in size)

Exchange of keys employed in symmetric-key cryptosystems, that require to be securely

transmitted to their destinations over unsecured communication channels

Both applications are identical in terms of architecture, design and graphical user interface,

the differences residing in the specific key generation, encryption and decryption algorithms

and their implementations, as defined by the cryptosystem each application is built upon.

Documenting the analysis and design of the application is done in conformity with the UML 2.1

standard and extra emphasis is being put on the implementation choices made.


83

4.1 Use cases

<<include>>

<<extend>>

<<extend>> Generate a random

prime number

Request two random

strings from the user

Use atmospheric

noise sensors

<<include>>

Generate a key

Select two distinct

prime numbers

<<include>>

Encrypt data

Select any public key

Select any file

<<include>>

<<extend>>

Decrypt data

Select the

corresponding private

key

Select an encrypted

file

Cryptosystem Application

Framework

User


84

4.2 Subsystem model

The desktop applications reflecting the implementations of the RSA and the Rabin cryptosystems,

respectively, are built on a software architecture involving three layers, each new layer

depending on the layer(s) below.

UI (User Interface) Layer

Graphical User Interface (GUI) 3

rd Layer

Random Prime Number Generation

2nd

Layer

Encryption and Decryption

Key Generation

Data Model & Technical

Layer

Large Integer Manipulation

1st Layer

Business Layer


85

Notes:

This architecture uses a relaxed layer interaction model, allowing the upper layer (UI) to

access the Data Model & Technical Layer for some of the operations.

Method calls from one subsystem (layer) to another can only be made by higher order

layers to lower order layers.

4.3 Package diagram

For the RSA Cryptosystem Application:

<<import>>

<<import>>

<<import>>

<<import>>

<<import>>

<<application>>

RSA_Cryptosystem_Application

RSAEncryptionDecryptionImple

mentation

PrimesGeneratorImplementation

<<technical>>

BigIntegerImplementation


86

For the Rabin Cryptosystem Application:

<<import>>

<<import>>

<<import>>

<<import>>

<<import>>

<<application>>

Rabin_Cryptosystem_Application

RabinEncryptionDecryptionImple

mentation

PrimesGeneratorImplementation

<<technical>>



87

4.4 Class diagram

For the RSA Cryptosystem Application:

Package RSA_Cryptosystem_Application:


88


89


90

Package PrimesGeneratorImplementation:


91

Package RSAEncryptionDecryptionImplementation:

Package BigIntegerImplementation:


92


93

For the Rabin Cryptosystem Application:

Package Rabin_Cryptosystem_Application:


94


95


96


→ identical to the package having the same name from the RSA Cryptosystem

Application


97

Package RabinEncryptionDecryptionImplementation:


98


→ identical to the package having the same name from the RSA Cryptosystem

Application

4.5 Sequence diagram

Response : a public and a

private key

Response : a prime

BigInteger

If the BigInteger is

composite, increase it by 1

Response : the BigInteger

is prime or composite

Test the BigInteger for

primality

Response : a random

BigInteger

Generate a random

BigInteger

Generate a

random prime

number

: RSA (Rabin)

Encryption

Decryption

: RSA (Rabin)

Cryptosystem

Application

: Primes

Generator

Select two

primes

User


99

Response: the decrypted

file

Response: the encrypted

file

If the end-of-file has

not been reached,

continue

Response: the BigInteger

representation of the data

Read a fixed amount

of data from the file

Select a file and a

public key

Response: the encrypted

BigInteger

Encrypt the

BigInteger

If the end-of-file has

not been reached,

continue

Response: the BigInteger

representation of the data

Read a fixed amount

of data from the file

Select an encrypted file

(and its corresponding

private key)

Response: the decrypted

BigInteger

Decrypt the

BigInteger


100

4.6 Explaining the implementation

Package RSA_Cryptosystem_Application (Rabin_Cryptosystem_Application):

Every operation whose output is not obtained instantly is implemented as a thread, to

prevent the graphical user interface from freezing while the operation is being performed.

During the execution of a thread, most menus of the GUI are disabled, in order to

preserve the processor power for the executing task. At its completion, every threaded

operation displays the total amount of consumed time. The threaded tasks are:

Primes Generation

Encryption

Decryption

For the generation of random primes, the GUI provides two methods:

Random strings input, for which the user is required to type two random

strings of his/her choice, each having a length of at least 50 characters.

Real-time atmospheric noise, for which the application connects to the

website http://www.random.org and retrieves the random content.

Each random prime found can be saved as a binary file (*.RSAPrime or *.RabinPrime).

With respect to the key generation, the user must select two different primes (two

*.RSAPrime or *.RabinPrime files) to compute the public and the private keys. The

public and the private keys can then be saved as binary files, *.RSAPublicKey or

*.RabinPublicKey – for public keys and *.RSAPrivateKey or *.RabinPrivateKey – for

private keys. For the RSA cryptosystem, the public exponent is chosen to be

, unless , in which case is increased, until

(see 3.1.1).

For the encryption of data, the user should select a public key (*.RSAPublicKey or

*.RabinPublicKey), the file to be encrypted (having any format and length of less than or

equal to KB) and the target encrypted file (*.RSA or *.Rabin).

http://www.random.org/


101

Regarding the decryption of data, the user can choose an encrypted file (*.RSA or

*.Rabin) and the corresponding private key file (*.RSAPrivateKey or *.RabinPrivateKey).

To avoid selecting the wrong private key file, the application allows the option to

automatically determine the suitable private key file, as long as such a file exists in the

default private key folder.

All of the large integers and their inherent mathematical operations are handled by the

BigInteger class, from the package BigIntegerImplementation. As the class BigInteger

may work with large numbers of virtually any size as well as any numeration bases

, the following decisions have been made, regarding the representation of the

BigIntegers:

The numeration base is set to , so that each digit of a BigInteger

uses bytes of memory. By using a large numeration base (radix), the number of

digits assigned to a BigInteger becomes small, resulting in fast execution speed for

the algorithms employing BigIntegers. This arrangement benefits the application

in terms of effectiveness, since each digit of a BigInteger occupies half of a -bit

( byte) processor registry, the extra half being used for efficiently controlling

some of the overflow resulting from mathematical operations (such as addition,

subtraction, multiplication, division). For the visual representation of BigIntegers

(GUI logs), they are converted to the numeration base .

Both of the cryptosystems utilize moduli of size -bit ( -byte), which is

rather ahead of today’s standard of -bit ( -byte). Considering the choice

of the base , this would amount for moduli of digits and

primes composing the moduli of digits. As such, the maximum size of a

BigInteger to be encrypted or decrypted would be of digits and the maximum

BigInteger representation would be of overflow digit, to

accommodate for squaring and for repeated squaring modular exponentiation (see

2.3.4) of a BigInteger.


102

Every possible inconsistency or error in the user input or accessed data is flagged as

such, the user being presented with an appropriate warning or error message and the task

execution being terminated.


The two methods for generating a random prime, selectable at the GUI-level, are:

Random strings input, for which the random content taken into account of the

input is:

- the characters of the strings

- the position of each character in the string

- the total amount of time needed by the user to type each string

- the current system time

By applying standard arithmetical operations (addition, multiplication, power)

and controlled data type overflow (in fact, a modular operation) on the random

content, the application computes:

- an array of random seeds, equal in length to the size of the prime to be

generated, which determines the digits of the random number

(corresponding to the 1st input string).

- an array of random seeds, equal in length to the size of the prime to be

generated, which determines the rearranging (reordering) of the digits

of the previously obtained random number (corresponding to the 2nd

input string).

Real-time atmospheric noise, which needs an active Internet connection, in order

to be able to access the website http://www.random.org and get the random

content. The application requests an array of random seeds from the



103

aforementioned website, of length equal to the size of the prime to be built, which

determines the digits of the random number.

After a random number has been found, using any of the two methods, the process of

primality testing commences. If the number is deemed to be prime, the algorithm

terminates, otherwise the current number is increased by 1, and the primality test is

repeated for the new numerical value. The primality test is two-phased, employing the

following steps:

- Phase 1 – Trial division by the primes less than 1000.

- Phase 2 – If the candidate prime has passed the trial division test, it is subjected

to the most efficient primality test of today, namely the probabilistic Miller-Rabin

primality test.

In the case of the Rabin cryptosystem, prime numbers of the form

should be disregarded, since they involve very slow decryption computations (see 2.3.5.2

– the Tonelli-Shanks algorithm).

Package RSAEncryptionDecryption (RabinEncryptionDecryption):

For both cryptosystems, the Encryption class reads blocks of fixed size from the file to

be encrypted, converts the read data to BigInteger representation, encrypts the BigInteger

to another BigInteger and serializes the obtained BigInteger along with some information

regarding the binary block to a binary form in the output (encrypted) file. The encryption

must take into account special cases, such as reading a full block of data containing only

the (null) byte, as well as salting the read BigInteger to reach its desired length, if the

block of read data is of a smaller size than the standard (fixed) size. The latter special case

may only occur when the last block of the file to be encrypted has been reached.

For both cryptosystems, the Decryption class reads each information regarding the

blocks of data of the plain (non-encrypted) file and deserializes (reads) each of the


104

BigInteger numbers from the encrypted file. Each BigInteger is then decrypted to another

BigInteger, whose binary form is then written to a file, taking into account the

representation constraints provided by the information block in the encrypted file.

The Encryption class for the RSA cryptosystem encrypts blocks of size of bytes

(equivalent to a -digit BigInteger) to blocks having the same length, while the

Decryption reverses the process, by decrypting every BigInteger.

The Encryption class for the Rabin cryptosystem encrypts blocks of size of bytes

also, but those correspond to an -digit BigInteger, whose last digits are replicated,

after which the BigInteger is extended further with 5 digits of salt, to render small

encryption exponent attacks useless (see 3.2.5.2)). Like in the case of RSA, the obtained

BigInteger has 95 digits. The Decryption reverses the process by decrypting each

BigInteger, removing the salt digits and then deleting the replication digits from the

decrypted number.


The BigInteger class of the package is intended to store large integers and execute any

usual mathematical operation on them. The BigInteger class represents the numbers digit-

by-digit, in a numeration basis of choice . The traditional integer operators

(+, – , *, /, %, <, >, , , ==, !=, =) have been overloaded, so that any subsystem that

uses the BigInteger class is offered the typical and natural way of manipulating the

arithmetical operations on BigIntegers. The following specific arithmetic, abstract

algebra and computational operations have also been loaded into the BigInteger class, in

order to enhance its usefulness:

- The power operation (through fast binary exponentiation)

- The greatest common divisor (gcd), using the standard Euclidean algorithm and

the extended Euclidean algorithm (see 2.2)

- The modular multiplicative inverse algorithm (see 2.3.1)


105

- The modular exponentiation method, using the repeated squaring algorithm (see

2.3.4)

- The serializing and deserializing of a BigInteger

- Adding and removing the salt digits of a BigInteger

- Adding, checking and removing of the replication digits of a BigInteger

Great care has been taken to define the best data structures for storing large integers as

well as for every algorithm utilized in the BigInteger class to employ the best polynomial-

time algorithms to date, without containing any inefficient exponential-time algorithms.


106

4.7 Revealing the applications’ functionality

In the next subsections, all the available functionalities of the applications (RSA Cryptosystem

Application and Rabin Cryptosystem Application) are uncovered and presented.

4.7.1 Exposing the RSA Cryptosystem Application

1) Prime Generation testing:

Using real-time atmospheric noise:


107

Using random strings input:


108

2) Key generation testing

Note: For the key generation, we will be using the two primes obtained previously.


109

Key-generation log:

Starting the key generation ...

The 1st prime is

432361550592177703687471340057299480609804330045972900719681017485397749

218057789202916709695238064181347126985611764816820277262110536032783317

143480673147891773363907872121031266217828395530191606690020305668533621

654910835419383

The 2nd prime is

590328199805706857880622939787202003261487220453491227812877670672360709

417768942906244893803625222504695646844790265974661181123293137718315180

814198071320827004781831251233716697646436758990811387755381526963682557

963789862123343

The public key modulus (as the product of the two primes) is

255235215826284313701798101197088601458103469857854153667313200621769019

034221179709130622772504141821993539384892128946799478964241416396175847

597984907761060421239911340101318473177772123618496745232599210571711148

220961035361794751559129467619043682206576507534384302934926283990822636

597719086248249285300093913414479817916338231367095648791450152194912786

908023115305787650130268343387129312098496936132254802175302234645565437

521635844989264520868278957369

The public encryption exponent is e = 65537

The private decryption exponent is d =

174591371675424962742444861325136670939572738357379826798688539052350658

762289019734811264154467868194759759687271528154859402199779402429781089

275030340341003382580606762237241667341494488637215757339783978667467396


110

657547388731086452922994090303139191230209796050550473023979376845624558

403188374875220330742798872158573712302185037107120361298162411169021481

292094267320945373035107119663429555638657821588686737972624959985908075

998760669982107758429172449433

3) Encryption testing:

Note: For the encryption, we will be using the public key component of the key obtained

at the key generation testing and the file boot.ini as the file to be encrypted.


111

Encryption log:

Starting the encryption process ...

Writing the public-key to the encrypted file ...

255235215826284313701798101197088601458103469857854153667313200621769019

034221179709130622772504141821993539384892128946799478964241416396175847

597984907761060421239911340101318473177772123618496745232599210571711148

220961035361794751559129467619043682206576507534384302934926283990822636

597719086248249285300093913414479817916338231367095648791450152194912786

908023115305787650130268343387129312098496936132254802175302234645565437

521635844989264520868278957369

Plain number

141305629585215394297284896929800272417991205552816284875666447182661453

161116985349854143892016671389226678962179699568173336712184569076541493

348705053655859218493311673363755297217494528883951763210257924204930637

969070640194269254646737821267753519234533509574974028891148482127579281

610019182454203267334357957803765284573920613164905992474595171988770077

734062542559983430075786146837987066201123294957708853863888513943428394

02256579078158691755979893


112

Encrypted to number

180132248109472323179898199642301275053105278397677036155540903754731980

119744362566580985137346035916935951462542467301366456664714289600630823

147253592852261578321038960682890501958159035885179122391428962767452607

206227219463530557518116951211440075489308988828207915711942844994763163

272292027495314997973095208213137571129032247163076657321897220550777844

616983284744408804499362556759834210603383252264020940475275826456339431

870765833322420691890943460501

Plain number

882054190690688674192782416964482838912803791157796974758732467409211876

762669059660819403360239436951761334305710080268298109517276634338359028

629418378160961163408673545032119968673186121353501347854820327822144108

449051602056484494815225159865450685580339715227449142728997363170535801

924713159873398211075294032790310450907045584987250222253191206130195551

004924555860039011696944456005994386224565838136615514222386244013038154

6642249730146152812118016

Encrypted to number

206239766399106536113864063571159966113147547936046020546142808222160976

781259636935036131604251248139513789871232587211352041768453030730741037

648070349381353778748165493584122644317436741439547473818522409167285839

451148406815747274246269335397902752096765213215258757719073891929799798

676675460841039694090166743012384692764348342465381884320797550502479470

266186656065097843768323718238581992271124361945688692453199415189641856

551491941320568383709359340351

The encryption process required 0.344608 seconds.


113

4) Decryption testing:

Note: For the decryption, we will be using the private key component of the key obtained

at the key generation testing and the file boot.ini.RSA as the file to be decrypted.


114

Decryption log:

Starting the decryption process ...

Encrypted number

180132248109472323179898199642301275053105278397677036155540903754731980

119744362566580985137346035916935951462542467301366456664714289600630823

147253592852261578321038960682890501958159035885179122391428962767452607

206227219463530557518116951211440075489308988828207915711942844994763163

272292027495314997973095208213137571129032247163076657321897220550777844

616983284744408804499362556759834210603383252264020940475275826456339431

870765833322420691890943460501

Decrypted to number

141305629585215394297284896929800272417991205552816284875666447182661453

161116985349854143892016671389226678962179699568173336712184569076541493

348705053655859218493311673363755297217494528883951763210257924204930637

969070640194269254646737821267753519234533509574974028891148482127579281

610019182454203267334357957803765284573920613164905992474595171988770077

734062542559983430075786146837987066201123294957708853863888513943428394

02256579078158691755979893

Encrypted number

206239766399106536113864063571159966113147547936046020546142808222160976

781259636935036131604251248139513789871232587211352041768453030730741037

648070349381353778748165493584122644317436741439547473818522409167285839

451148406815747274246269335397902752096765213215258757719073891929799798

676675460841039694090166743012384692764348342465381884320797550502479470


115

266186656065097843768323718238581992271124361945688692453199415189641856

551491941320568383709359340351

Decrypted to number

882054190690688674192782416964482838912803791157796974758732467409211876

762669059660819403360239436951761334305710080268298109517276634338359028

629418378160961163408673545032119968673186121353501347854820327822144108

449051602056484494815225159865450685580339715227449142728997363170535801

924713159873398211075294032790310450907045584987250222253191206130195551

004924555860039011696944456005994386224565838136615514222386244013038154

6642249730146152812118016

The decryption process required 18.436528 seconds.


116

The RSA Cryptosystem Application testing allowed us to reach the following conclusions:

Each of the underlying parts of the application (Primes generation, Key

generation, Encryption and Decryption) is functioning properly and effectively

both as an independent subsystem and in connection with the rest of the

subsystems.

The whole process, starting from the prime generation, continuing with the key

generation, the encryption of data and, finally, the data decryption, is reliable,

since the file boot.ini was encrypted and then successfully decrypted to an

identical file.


117

4.7.2 Exposing the Rabin Cryptosystem Application

1) Prime Generation testing:

Using real-time atmospheric noise:


118

Using random strings input:


119

2) Key generation testing

Note: For the key generation, we will be using the two primes obtained previously.


120

Key-generation log:

Starting the key generation ...

The 1st prime is

603409157964657679988448825227008627352632691661553875156273183575885055

302192273445483717263765580524583483926382638249458505510096457157239047

653415238880921411021957953183888697090469876167979308640130331555881937

793695929781837

The 2nd prime is

128357815916338451984666730798516208816591292090318253794256736090691627

823014690236048166930141703728267678248836419624101841800359742276109433

471480484141682042541682382794805646205260462437029662800480731675383491

708414239446407

The public key (as the product of the two primes) is

774522816202603207489921705782695273011824308637579455787026382868675985

154076051705313295129157808231221923149474761000152155458765965224465751

939017457122548563609461604583102777798864920357800000875409449379457305

806420348776983068804504056655446684356212065698613025888446116727759064

440511085412497542800501359951746408257525594753216529931877167167462151

240677474059101882970150940699658244851625451764164907965824005656271969

86227970751434913303163509659

3) Encryption testing:

Note: For the encryption, we will be using the public key component of the key obtained

at the key generation testing and the file encode.exe as the file to be encrypted.


121


122

Encryption log:

Starting the encryption process ...

Writing the public-key to the encrypted file ...

774522816202603207489921705782695273011824308637579455787026382868675985

154076051705313295129157808231221923149474761000152155458765965224465751

939017457122548563609461604583102777798864920357800000875409449379457305

806420348776983068804504056655446684356212065698613025888446116727759064

440511085412497542800501359951746408257525594753216529931877167167462151

240677474059101882970150940699658244851625451764164907965824005656271969

86227970751434913303163509659

Plain number

887658009923512448177096566588506019064245397302061357464554980517301230

501083117573284658643528768282678498107503927824127235870288471841368372

986121431983864472492008051894603767851531545041588192953142083489182898

906609595065623853475733434531683587007456901263341675445407795301195760

547458590866704498577243175204207700633870438957261246233626251814238897

5289682983965164931988763214155776334805988278272

Encrypted to number

483007008228219873829899902238964584096637539588939663034491964352581738

875779088776622083769657924381436022803847978975528424704029935631922654

248139130654725166182334586363829001586042213279161485934445145285576744

162475259037850601680212460132458134713859373176992884028677105551503082

481802914809884884173156786398698723006316477556873999451631208818927218

490832883528850149848749954112280150791538108532109062521013573284790204

52315223284000005621467822995


123

Plain number 0, not encrypting it.

Plain number 0, not encrypting it.

Plain number

230390953837795621315864343260983594345582788881673324457087403921245597

235810833293187178601804887311499926973162860281984111832428818227346073

140140336080188486235311967474345041855361639416655870061769439345740570

998171783013895075709415641092744334893537931356778231644369465625584911

936676213101431486706995380701995926797698863243512208755080604819862260

31906194843650665794185518543470704657430740992

Encrypted to number

533382393346692702758090740845315513464857018030991256133778712670547680

795516065716717989716619858015085064055102356008386301416258181898487994

099858668541786050694377794809210444068923856984512521786895432912077905

635319900801224904189238210870692206259230175682729180119044149998649770

053620003240030500563308537136288782703673067860731858568411773373994337

513308442514190985397453958319502706326566372644885192028137263588487876

29073061744736467271053340490

Plain number

698447937459492709496472146340593186526839584508897574948364862873968365

657588004375751039266457251771335887618443797557812416080561222116560752

843125738339389863131759698423295210708305875658480804067053331225581395

719985164789948207111982798902740033156889891191749355209812435806923046

381647288854748933130880402595010254432273065406032320507922143156865023

5132982777853313830253155438209705500906768650253


124

Encrypted to number

341858195308298897885932766092714144216681897348725524119544788544167048

244632056906099366629396552615431308927776248404865669690764747366697759

825559846461358498096078552651753523157634390818217877578630463990882977

449697273312440912703768463371541632791207746148727092710315203894956103

197092313052140613636871632814349429595725772035010242850201437591288465

386956546772124147996253581962911369414455941013635146439124908754850387

10789748610318163140636259807

Plain number

109552614542685840451852158253083577554052712894843129168598074645684106

636256151152338774689517723521703706336634661582764331707894644937005936

354926523974447473277279448614237031917010197277476103403324247038280408

517110742936331013562879433908389324969495920190155998428106322139126651

623888667148349395813630596920257048585385392591867976742020030442117103

17320606889253405956766828167688341494419738017716

Encrypted to number

399631374475041066810052133866542700536592745312399777654835088822049805

917984256474461757402884263309408624677749494115860120651794437619098634

971730085576182606743815886134890378899068473403393493359928396055250919

438031428223041256338359393041440364527172103605707078013978586657525600

805749843854722228418785554162425462508276147542370614994802415775088643

889379916183938376156686843973335625250144744137872055005458531172305340

39427478216552637359540850272

Plain number

300237884000300490070773100969335466675007838027364735247876320195086972

875714300531415998413068073458567456623426341475873989613618121430258660


125

912967507670673972106571728149082080326313496595670779672734162679511272

007775171541526010323932477289464733594222101524985960062168250650411979

351619670302071981716340134614369895226224641039231124420252808271799079

0747710872732357619471186914755302870252861259776

Encrypted to number

215898514742984573715272132863436335925968218793635803622397638814182429

519799553689782684321187235597664801813217722041074934725111580987773931

352215908391473339644754719759303754656437308761861927668058322578102999

605340471871933460450179110633144681372147482461792341685253500355574870

505801512889524022995253211366825570295323717179411808150941195228005216

195081752219113018269063660737458027197944661923576479553881646234724560

66729052163378758297286290201

The encryption process required 0.4519882 seconds.


126

4) Decryption testing:

Note: For the decryption, we will be using the private key component of the key obtained

at the key generation testing and the file encode.exe.Rabin as the file to be decrypted.


127

Decryption log:

Starting the decryption process ...

Encrypted number

483007008228219873829899902238964584096637539588939663034491964352581738

875779088776622083769657924381436022803847978975528424704029935631922654

248139130654725166182334586363829001586042213279161485934445145285576744

162475259037850601680212460132458134713859373176992884028677105551503082

481802914809884884173156786398698723006316477556873999451631208818927218

490832883528850149848749954112280150791538108532109062521013573284790204

52315223284000005621467822995

Decrypted to number

887658009923512448177096566588506019064245397302061357464554980517301230

501083117573284658643528768282678498107503927824127235870288471841368372

986121431983864472492008051894603767851531545041588192953142083489182898

906609595065623853475733434531683587007456901263341675445407795301195760

547458590866704498577243175204207700633870438957261246233626251814238897

5289682983965164931988763214155776334805988278272

Plain number 0, obtained without decryption.

Plain number 0, obtained without decryption.

Encrypted number

533382393346692702758090740845315513464857018030991256133778712670547680


128

795516065716717989716619858015085064055102356008386301416258181898487994

099858668541786050694377794809210444068923856984512521786895432912077905

635319900801224904189238210870692206259230175682729180119044149998649770

053620003240030500563308537136288782703673067860731858568411773373994337

513308442514190985397453958319502706326566372644885192028137263588487876

29073061744736467271053340490

Decrypted to number

230390953837795621315864343260983594345582788881673324457087403921245597

235810833293187178601804887311499926973162860281984111832428818227346073

140140336080188486235311967474345041855361639416655870061769439345740570

998171783013895075709415641092744334893537931356778231644369465625584911

936676213101431486706995380701995926797698863243512208755080604819862260

31906194843650665794185518543470704657430740992

Encrypted number

341858195308298897885932766092714144216681897348725524119544788544167048

244632056906099366629396552615431308927776248404865669690764747366697759

825559846461358498096078552651753523157634390818217877578630463990882977

449697273312440912703768463371541632791207746148727092710315203894956103

197092313052140613636871632814349429595725772035010242850201437591288465

386956546772124147996253581962911369414455941013635146439124908754850387

10789748610318163140636259807

Decrypted to number

698447937459492709496472146340593186526839584508897574948364862873968365

657588004375751039266457251771335887618443797557812416080561222116560752

843125738339389863131759698423295210708305875658480804067053331225581395

719985164789948207111982798902740033156889891191749355209812435806923046


129

381647288854748933130880402595010254432273065406032320507922143156865023

5132982777853313830253155438209705500906768650253

Encrypted number

399631374475041066810052133866542700536592745312399777654835088822049805

917984256474461757402884263309408624677749494115860120651794437619098634

971730085576182606743815886134890378899068473403393493359928396055250919

438031428223041256338359393041440364527172103605707078013978586657525600

805749843854722228418785554162425462508276147542370614994802415775088643

889379916183938376156686843973335625250144744137872055005458531172305340

39427478216552637359540850272

Decrypted to number

109552614542685840451852158253083577554052712894843129168598074645684106

636256151152338774689517723521703706336634661582764331707894644937005936

354926523974447473277279448614237031917010197277476103403324247038280408

517110742936331013562879433908389324969495920190155998428106322139126651

623888667148349395813630596920257048585385392591867976742020030442117103

17320606889253405956766828167688341494419738017716

Encrypted number

215898514742984573715272132863436335925968218793635803622397638814182429

519799553689782684321187235597664801813217722041074934725111580987773931

352215908391473339644754719759303754656437308761861927668058322578102999

605340471871933460450179110633144681372147482461792341685253500355574870

505801512889524022995253211366825570295323717179411808150941195228005216

195081752219113018269063660737458027197944661923576479553881646234724560

66729052163378758297286290201


130

Decrypted to number

300237884000300490070773100969335466675007838027364735247876320195086972

875714300531415998413068073458567456623426341475873989613618121430258660

912967507670673972106571728149082080326313496595670779672734162679511272

007775171541526010323932477289464733594222101524985960062168250650411979

351619670302071981716340134614369895226224641039231124420252808271799079

0747710872732357619471186914755302870252861259776

The decryption process required 25.8880138 seconds.


131

The Rabin Cryptosystem Application testing allowed us to reach the following

conclusions:

Each of the underlying parts of the application (Primes generation, Key

generation, Encryption and Decryption) is functioning properly and effectively

both as an independent subsystem and in connection with the rest of the

subsystems.

The whole process, starting from the prime generation, continuing with the key

generation, the encryption of data and, finally, the data decryption, is reliable,

since the file encode.exe was encrypted and then successfully decrypted to an

identical file.

Chapter 5 – Processor Core Benchmarking

132

CHAPTER 5 – PROCESSOR CORE BENCHMARKING

5.1 The concept of benchmarking

In the field of computer science, a benchmark can be understood as the process of executing a

software application or a set of applications, in order to rigorously assess the relative

performance of a computational entity (either hardware or software). [wiki] In reality, the term

of benchmark covers a much broader spectrum, involving not only performance testing, but also

execution integrity, scalability, reliability and security evaluations of hardware and software

(sub)systems. [Pan99]

The diverse needs in quantifying computer behavior have led to the appearance of many types of

benchmarks, each measuring a particular quality or set of qualities of a system.

5.1.1 Types of benchmarks

Based on the target whose quality (most likely performance) is being measured, benchmarks can

be grouped as:

hardware benchmarks, which target the computer’s electronic devices

software benchmarks, which are aimed at assessing the behavior of software

applications

Based on the generality of the properties they quantify, benchmarks are split into [Hen07]:

component-level benchmarks, which measure the quality of certain hardware or

software components taken in particular, such as:

- hardware components: central processing unit (PIFast, QuickPI), single

processor core (SuperPI), arithmetic integer unit (Dhrystone), arithmetic

floating-point unit (Whetstone), graphics processing unit (Futuremark

3DMark), sound card, network adapter, display, hard disc, notebook battery

life (BAPCo MobileMark)


133

- software components: operating system, database management system (TPC-

C), compiler, virtual machine

system-level benchmarks (BAPCo SYSmark, Microsoft WinSAT), whose purpose is

to assess the overall behavior (performance, usually) of computer systems running

real applications. Such benchmarks may also specify the contribution of each

subsystem to the global result.

Regarding their composition, benchmarks are divided in [Hen07]:

synthetic benchmarks (Whetstone, Dhrystone, POV-Ray), which are created by

combining lower-level functions targeting computer hardware components, in a

proportion that is believed to be appropriate for efficiently evaluating the capabilities

of the desired subsystem. By this, the developers try to match an average execution

profile of the component.

application benchmarks (BAPCo SYSmark), which employ a set of popular

applications that are deemed typical for a certain industry segment or class of

products. These applications are executed either as a batch or simultaneously, in an

attempt to simulate the way users would run applications on their systems. Such

benchmarks often are system-level benchmarks.

5.2 Benchmark development fundamentals

5.2.1 Justification

While not a goal all by itself, the development of a benchmark based on the computational profile

of public-key cryptography can be envisioned as a collateral benefit to implementing an

asymmetric-key cryptosystem.

Such a benchmark would be a processor core integer benchmark, belonging to the class of

hardware component-level synthetic benchmarks due to the following reasons:


134

Public-key cryptography involves very computationally-intensive calculations in all of its

underlying operations (primes generation, key generation, encryption, decryption). Some

of these operations (primes generation, encryption, decryption) require a significant

amount of time to complete (up to seconds). This means that a benchmark using one (or

more) of these operations is able to provide a computational challenge even to the most

modern and capable of processors.

Three out of the four operations (key generation, encryption and decryption) are fully

deterministic, therefore they require the same amount of computations for a given test

data, regardless of any external factors.

The implementation of a public-key cryptosystem is heavily reliant on the eight -bit

integer processor registers, ignores the eight double floating point registers and has a very

small (under 1 MB) memory footprint (not counting the GUI and the managed

environment). As the data required can be loaded from the disc prior to the test’s

inception, the benchmark has no interference with the hard disc, nor with any devices

whose access to is controlled by the OS kernel. As such, the benchmark isolates the

desired processor core for a reliable testing experience.

Being by far the most demanding in terms of resource usage of the cryptographic operations,

while also belonging to the class of fully deterministic algorithms, the decryption protocol is the

operation of choice to be used by the benchmark, since, due to its lengthy execution, it

emphasizes the potential differences between processor cores’ speed, while, at the same time,

nullifying the possible inconsistencies caused by application overhead.

5.2.2 Development platform and programming paradigm

The platform of choice for developing the RSA and the Rabin cryptosystem applications has

been the .NET Framework 2.0 running on Microsoft Windows operating systems, thus, naturally,

the benchmark will be developed using C#.NET and executed on any Microsoft Windows-

running machine that supports the .NET Framework. This ensures a great deal of generality to


135

the benchmark, as most of the contemporary PC’s are having a Microsoft Windows OS installed

and are capable of executing the .NET Framework 2.0.

Although the .NET Framework has been unofficially ported to some extent to other platforms

(the Mono Project on Linux), these conversions are not 100% compatible with the original

version, mostly because they are running on completely different operating system kernels.

Therefore, such platforms are not targeted by the application, since, in order to ensure a

consistent testing experience, a benchmark cannot hope to test a processor core speed in itself,

but, more likely, a processor core speed when running on a certain operating system architecture.

Benchmarking applications have traditionally been considered heavy-duty applications that need

to run as closely to the machine-level as possible. According to the aforementioned ideology, it

would seem rather strange to choose an intermediate language programming paradigm (.NET)

over native code-generating languages in a domain as demanding and needing extreme accuracy

as benchmarking. However, as it will be pointed out in the subsequent section, the .NET

Framework is not only a good choice, but the best choice for this purpose on the MS Windows

platform.

5.2.3 Native code vs. intermediate code

The .NET paradigm may compile an application to MSIL (Microsoft Intermediate Language)

code, but, when an application is first run in a Windows session on a computer, it is compiled

further to machine code, taking into account all the possible optimizations for the underlying

platform. Those optimizations mostly target the processor and the version of Windows that is

running on the computer.

Aiming at the CPU ensures the best optimization (machine code generated specifically) for the

architecture the processor is based on, while addressing the Windows version ensures a smooth,

consistent experience of the application when running on different versions of the OS. This is

something that a native-code compiled application cannot hope to achieve.


136

As an example to illustrating the previously-stated theoretical point, the case of the GNU family

of native-code compilers (GCC, G++, GCJ, etc.) is exposed below, which is one of the most

remarkable portable compilers to date.

5.2.3.1 GNU compiler family processor optimizations

The GNU compiler family has two processor optimization options available: [GCC]

-mtune=CPU_TYPE, which tunes to CPU-TYPE everything applicable about the

generated code, except for the application binary interface and the set of available

instructions.

-march=CPU_TYPE, which generates instructions for the machine type CPU-TYPE.

The choices for CPU-TYPE are the same as for -mtune. Moreover, specifying

march=CPU-TYPE implies -mtune=CPU-TYPE.

The available processors of the x86-32 and x86-64 platforms, excluding the old legacy CPU’s

are: [GCC]

i686, pentiumpro - Intel PentiumPro CPU

pentium2 - Intel Pentium2 CPU based on PentiumPro core with MMX instruction set

support.

pentium3, pentium3m - Intel Pentium3 CPU based on PentiumPro core with MMX and

SSE instruction set support.

pentium-m - Low power version of Intel Pentium3 CPU with MMX, SSE and SSE2

instruction set support. Used by Centrino notebooks.

pentium4, pentium4m - Intel Pentium4 CPU with MMX, SSE and SSE2 instruction set

support

prescott - Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2 and SSE3

instruction set support.

nocona - Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE,

SSE2 and SSE3 instruction set support.

k6-2, k6-3 - Improved versions of AMD K6 CPU with MMX and 3dNOW! instruction

set support.


137

athlon, athlon-tbird - AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and

SSE prefetch instructions support.

athlon-4, athlon-xp, athlon-mp - Improved AMD Athlon CPU with MMX, 3dNOW!,

enhanced 3dNOW! and full SSE instruction set support.

k8, opteron, athlon64, athlon-fx - AMD K8 core based CPUs with x86-64 instruction set

support. (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and 64-bit

instruction set extensions.)

Observing these optimizations options, one can easily notice the broad range of processor

families supported. One the other hand, the developer of the applications targeting the GCC

compiler cannot know in advance which type of processor the user would possess. It has, thusly,

three choices in distributing his application, none of which are fully satisfactory, at least

compared to the .NET solution of on-the-spot fully-optimized compilation of intermediate code:

1) use the least common denominator of the optimizations (that is use the i686 processor

with the -march flag) and optimize for no CPU in particular. This way no processor gets

an advantage over the other, but, on the other hand, no processor executes at its full

potential. This solution seems equitable to all CPU architectures, but, in fact, it is limiting

to all.

2) use the i686 platform, but perform tuning settings for a particular processor family (such

as –mtune=pentium4) that is expected to be prevalent among the users. This would allow

the Intel Pentium 4 architecture to obtain an unfair advantage over other CPU’s, since, not

only would these run unoptimized, but would also have to overcome an improper

optimization.

3) supply the application in source code format and let the user compile it for its specific

configuration. While this is an acceptable solution for the Linux world, it is inadequate to

be used with the Microsoft Windows OS, where users expect binaries and may not even

have a compiler installed.


138

5.2.4 Understanding processes and threads

A running benchmark is, from the operating system’s point of view, nothing more than a thread

(or a set of threads) running (simultaneously) inside a process. In our case, in order for the

benchmark to target a certain processor core (core 0), only a single execution thread is defined (of

course, there is still the thread running the GUI of the benchmark).

That is not to say that public-key cryptography (more specifically, the decryption protocol)

cannot be put to good use in testing multi-core processor systems by employing a certain degree

of concurrency (many threads running simultaneously), but reliably testing a single processor

core is a lengthy process (taking up to tens of seconds) and, obviously, accurate parallelization

testing would visibly increase this duration.

Since modern operating system kernels (including the Microsoft Windows NT-based OS’s, the

officially supported hosts for the .NET Framework) are running tens of processes containing

hundreds of threads overall, it becomes clear that true parallel execution is all but impossible on

most of the systems in use nowadays. Thus, systems must employ at least a certain degree of

concurrency, regardless of the amount of processors (or processor cores) existing in their

underlying architectures.

The solution that most OS’s have chosen to implement is the priority-based and Round-Robin

preemptive scheduling, which utilizes both external and internal means of establishing and

adjusting process and thread priorities. The granularity of this operation is at thread level, rather

than at process level, but process priority does contribute at defining the priority of its contained

threads.

As the benchmark is created for the Microsoft Windows platform it behooves us to expose the

process and thread scheduling mechanisms of MS Windows, although many concepts are

implemented similarly in the other contemporary operating systems of today, such as Linux, Sun

Solaris and Apple MacOS.


139

5.2.5 Process and thread execution priority

While not being able to overcome all the multi-threading related issues (dead-locks, live-locks,

starvation and races), the operating system must define and implement a series of rules for thread

scheduling and preemption that significantly alleviate live-locks and starvation scenarios.

In the MS Windows OS, each process is given a priority at creation-time, that will influence the

priorities of its threads. These priorities, as made available through the Win32 API, are: [MSDN]

idle – referring to processes whose threads run only when the system is in idle state. The

threads of these processes are preempted by any thread of a process having a higher

priority. An example of such a process would be the screen saver.

normal – for processes with no special requirements in terms of scheduling.

high – designed for processes that perform time-critical tasks and must be executed

without delay. The threads of these processes preempt the threads of other processes

belonging to a normal or idle priority class. Extra attention must be paid when assigning a

process high priority, because a high-priority class application can use almost all of the

available CPU time, leading to the starvation of other processes. A user desiring to run a

process with the high priority must possess administrative rights. A typical high-priority

process is the Windows Task Manager, which must allow for a quick response time,

irrespective of the overall load of the system.

real-time – designated for processes that need the highest possible priority. The threads of

these processes preempt the threads of all other processes, including also system services.

Real-time processes must be used only as a last resort solution, because, when run for

more than a few milliseconds, they cause the whole system to become unresponsive. A

user wanting to run a process with the real-time priority must have administrative rights.


140

We need our benchmark application to run at the highest possible priority to ensure very reliable

results, without interfering with system services and other essential processes. As such, the

priority of the choice for the benchmark is the high process priority. A small drawback to this

decision is that the user of the application must be granted administrative privileges on the

system.

MS Windows lets the user define a priority value for any thread, through the Win32 API. This

value, together with the priority class of the thread's process, determines the thread's base

priority level. The operating system scheduler (dispatcher) may alter the thread priority within a

certain range of the base priority level. The priority values for threads are listed below: [Sol00]

idle - No CPU time slices will be assigned to this thread, unless all the other threads of the

process are in an idle state (waiting or blocked).

lowest – significantly diminished priority

below normal – reduced priority

normal – Unless specific priority values are specified, any thread is given this priority

value at creation-time.

above normal – slightly elevated priority

highest – Such a thread receives the highest priority allowed, considering the priority

class of its containing process.

time-critical – A thread belonging to this category monopolizes the processor time-slices

assigned to its parent process. This priority value is not made available through the .NET

Framework.

Considering that we require our benchmarking thread to run virtually uninterrupted (without

being subject to the Windows dispatcher), we must assign it the highest priority value. In

conjunction with the high process priority class, this should amount for minimal thread

preemption and, therefore, a reliable and consistent testing experience. However, since the .NET

Framework involves a managed execution environment, one must not make any assumptions as

to the bijective binding of managed threads to operating system threads. This correspondence

must be enforced explicitly.


141

5.3 Implementing the benchmark

5.3.1 Benchmark solution components

The benchmarking solution is composed out of two applications, as revealed below:

1) the benchmarking application itself, relying on the decryption algorithm of the RSA

cryptosystem, is developed in C# 2.0 and the .NET Framework 2.0. This component will

be distributed to each system whose processor core performance is to be determined.

2) a web application consisting of:

a dynamic web page, able to display all the benchmark results stored on the server

a module designed to receive the test result from each client benchmark

application and store it on the server inside an external file

This component is implemented as a CGI dynamic web page written in the C language

(using GNU C) and deployed on the faculty’s Red Hat Linux students’ server

(http://www.scs.ubbcluj.ro/~rm20366/cgi-bin/ProcessorCoreBenchmarkResults.cgi).

5.3.2 Use cases

Benchmark System

Web

application

User

Start the benchmark

Submit the result of the

benchmark

<<include>>

View all the

benchmark results

Request all the benchmark

results

<<include>>

http://www.scs.ubbcluj.ro/~rm20366/cgi-bin/ProcessorCoreBenchmarkResults.cgi


142

5.3.3 Subsystem model

The processor benchmark desktop application is built on a software architecture involving three

layers (the same architecture as that of the RSA and Rabin cryptosystem applications), each new

layer depending on the layer(s) below.

Business Layer

UI (User Interface) Layer

Graphical User Interface (GUI) 3

rd Layer

2nd

Layer

Benchmark Results Handler

System Information Manager

Data Model & Technical

Layer

Large Integer Manipulation

1st Layer


143

Notes:

This architecture uses a relaxed layer interaction model, allowing the upper layer (UI) to

access the Data Model & Technical Layer for some of the operations.

Method calls from one subsystem (layer) to another can only be made by higher order

layers to lower order layers.

5.3.4 Package diagram

This is the package diagram for the processor benchmark desktop application.

<<import>>

<<import>>

<<import>>

<<application>>

ProcessorBenchmark

SystemInformation

ResultsHandler

<<technical>>



144

5.3.5 Class diagram

Package ProcessorBenchmark:


145

Package ResultsHandler:

Package SystemInformation:


146


→ identical to the package having the same name from the RSA (Rabin) Cryptosystem

Application

5.3.6 Sequence diagram

: System

Information

Decrypt data

Response : the system

information string

Submit the processor

score

Generate system

information

Start

benchmark

Get system

information

Set the processor score

Submit test data to the

web server Submit POST request to the web server

Get test results string Get system information

string

Response : the test results

string

Show test results

: Processor

Benchmark

GUI

User

: Results

Manager


147

5.3.7 Deployment diagram

Show the web page of all the benchmark test results

<<HTTP>>

Response : the web page

containing all the benchmark

results

View all

benchmark results

Response : the web page

containing all the benchmark

results

Submit GET request to

the web server

View all benchmark results

from the web server

<<device>>

Desktop PC

<<desktop application>>

ProcessorBenchmark.exe

<<device>>

Apache Web Server

<<web application>>

ProcessorCoreBenchmarkR

esults.cgi

<<text file>>

ProcessorCoreBenchmarkR

esults.txt


148

5.3.8 Exposing the application’s functionality

1) Desktop application

The desktop application allows its users to either:

start the processor core benchmark, which will test the performance of the first

CPU core, submit the result (using a POST request) to the web application and

also display the benchmark result inside the desktop application’s GUI

view the overall benchmark results provided by the web application, while also

highlighting the current test result inside the web page (using a GET request), if

such a test has been performed during the application’s execution


149

2) Web application


150

The web application provides the following functionality:

simply accessing the web page displays the results of all the benchmarks to date

sending a GET request to the web application, containing a particular test result

information, will signal the web application to render all the benchmarks’ results,

while highlighting the supplied result

sending a POST request to the web application, containing a new test result, will

trigger the web application to add it to its external benchmark results file

Conclusions

151

CONCLUSIONS

In the past 10 years, computer data security has become an ever-increasing concern to

governments, as well as companies and even end-users, since almost any information nowadays

is processed and stored in its electronic form, rather than using classical (traditional) means such

as pen & paper, dossiers, file cabinets, typewriters, etc. Even if sometimes information is

presented on traditional support (paper), it is still developed and maintained using electronic

devices.

In this context, it is the duty of cryptography not only to secure data for (indefinite) safekeeping,

but also to safely transmit important (sensitive) digital content over unsecured communication

channels. In an era of computer networks (physical or virtual) and the Internet, symmetric-key

cryptography cannot cope all-by-itself with the demands of secure digital systems. Therefore, in

modern-day data security systems, symmetric-key cryptosystems are coupled with public-key

cryptosystems, in an effort to solve the issues of safe symmetric-key exchange and for devising

of authentication (and non-repudiation) protocols.

The two computer applications (RSA Cryptosystem Application and Rabin Cryptosystem

Application) present a successful approach to securing limited amounts of data, as well as

providing a safe container for symmetric-key cryptosystem keys, that are about to be distributed

over unsecured communication channels. The power of the application resides in the strength of

its algorithms, the efficiency of its implementation and its large key size of 1536 bits, while its

accessibility is enhanced by the use of intuitive graphical user interface, suitable for users having

different levels of knowledge (or even no knowledge) of cryptography and its inherent protocols.

The processor core benchmark, which provides both the desktop benchmarking application

actually fulfilling the performance evaluation and the web application storing and revealing the

cumulated results of individual tests, has proven to be very reliable, allowing only minimal

fluctuations between the results of successive tests involving the same computer processor, as

well as establishing a processor core speed hierarchy that is in concordance with that of

prestigious computer hardware magazines.

References

153

REFERENCES

[Agr04] M. Agrawal, N. Kayal, N. Saxena, PRIMES is in P, Annals of Mathematics 160, 781-

793, 2004

[Bis03] D. Bishop, Cryptography with Java Applets, Jones and Bartlett Publishers Inc., 2003

[Cri06] S. Crivei, Computational Algebra: Lecture Notes, unpublished, 2006

[Elk07] R. El-Khalil, A. D. Keromytis, Hydan: Hiding Information in Program Binaries, The 9th

International Conference on Information and Communications Security (ICICS 2007),

Zhengzhou, China, 2007

[Han94] P. B. Hansen, Multiple-length Division Revisited: a Tour of the Minefield, Software -

Practice and Experience, vol. 24(6), 579–601, 1994

[Hen07] J. L. Hennesy, D. A. Patterson, Computer Architecture: A Quantitative Approach,

Morgan Kaufmann Publishers, 2007

[Kob94] N. Koblitz, A Course in Number Theory and Cryptography – Second Edition, Springer-

Verlag, 1994

[Men96] A. Menezes, P. van Oorschot, S. Vanstone, Handbook of Applied Cryptography, CRC

Press, 1996

[Pan99] J. Pan, Software Testing, 18-849b Dependable Embedded Systems, Spring 1999

[Sch96] B. Schneier, Applied Cryptography, Second Edition: Protocols, Algorthms, and Source

Code in C, John Wiley & Sons, Inc., 1996

[Sol00] D. A. Solomon, M. E. Russinovich, Inside Microsoft Windows 2000, Microsoft Press,

2000

[Sta05] W. Stallings, Cryptography and Network Security Principles and Practices, Fourth

Edition, Prentice Hall, 2005

[Sti95] D. Stinson, Cryptography: Theory and Practice, CRC Press, 1995

[wiki] Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/wiki/Main_Page

[GCC] The GNU C Compiler Info Page, GNU C Compiler 4.2.2, Knoppix 5.3.1 Distribution

[MSDN] Microsoft Developer Network, http://msdn.microsoft.com/en-us/default.aspx

http://en.wikipedia.org/wiki/Main_Page

http://msdn.microsoft.com/en-us/default.aspx

References

154

[net01] The Story of Alice and Bob, http://www.conceptlabs.co.uk/alicebob.html

[net02] The Primes Page, http://primes.utm.edu

[net03] RANDOM.ORG – True Random Number Service, http://www.random.org

http://www.conceptlabs.co.uk/alicebob.html

http://primes.utm.edu/


public-key cryptography - the rsa and the rabin cryptosystems

Documents

greatest common divisor

represents eulers totient

eulers totient theorem

english alphabet enriched

integer square root

chinese remainder theorem

eulers totient function

character space to 0