Real-Time RSA Encryption/Decryption Hardware
Evaluation
Project Plan
May04-26
Client: Akhilesh Tyagi
Faculty Advisor: Akhilesh Tyagi
Team Members:
Ryan Babiarz
Christopher Gray
Kyle Robertson
Kristofer Ruhland
September 23, 2003
Table of Contents
1.1 ABSTRACT ........................................................................................................................................... 1
1.2 ACKNOWLEDGEMENTS ....................................................................................................................... 1
1.3 PROBLEM STATEMENT ........................................................................................................................ 1
1.4 OPERATING ENVIRONMENT ................................................................................................................ 2
1.5 INTENDED USERS AND USES ................................................................................................................. 2
1.5 ASSUMPTIONS ...................................................................................................................................... 2
1.6 LIMITATIONS ....................................................................................................................................... 2
1.7 EXPECTED END PRODUCT ................................................................................................................... 2
2. PROPOSED APPROACH AND STATEMENT OF WORK ............................................................... 4
2.1 FUNCTIONAL REQUIREMENTS............................................................................................................. 4
2.2 CONSTRAINT CONSIDERATIONS .......................................................................................................... 4
2.3 TECHNOLOGIES CONSIDERATIONS ..................................................................................................... 5
2.4 TECHNICAL APPROACH ....................................................................................................................... 5
2.6 SECURITY CONSIDERATIONS ............................................................................................................... 7
2.7 SAFETY CONSIDERATIONS................................................................................................................... 7
2.8 INTELLECTUAL PROPERTY.................................................................................................................. 7
2.9 COMMERCIALIZATION ........................................................................................................................ 7
2.9 RISKS AND MANAGEMENT ................................................................................................................... 7
2.10 MILESTONES AND EVALUATION........................................................................................................ 8
2.10.1 Milestones: ................................................................................................................................ 8
2.10.2 Evaluation ................................................................................................................................. 8
2.11 PROJECT TRACKING .......................................................................................................................... 8
2.12 STATEMENT OF WORK....................................................................................................................... 9
3. RESOURCES...........................................................................................................................................12
3.1 PERSONNEL ........................................................................................................................................12
3.2 OTHER RESOURCES ............................................................................................................................12
3.3 FINANCIAL REQUIREMENTS ...............................................................................................................12
3.4 SCHEDULES.........................................................................................................................................13
4. CLOSURE MATERIALS .......................................................................................................................15
4.1 PROJECT TEAM INFORMATION ..........................................................................................................15
4.2 CLOSING SUMMARY ...........................................................................................................................15
4.3 REFERENCES ......................................................................................................................................16
4.4 APPENDICES .......................................................................................................................................16
Appendix A: RSA example.................................................................................................................16
ii
List of Figures
Figure 2-1 DES encryption process .................................................................................... 6
Figure 2-2 Function f in DES standard ............................................................................... 6
Figure 3-1 Project deliverables schedule .......................................................................... 13
Figure 3-2 Project tasks schedule ..................................................................................... 14
Figure 4-1 RSA example .................................................................................................. 16
iii
List of Tables
Table 2-1 Personal time commitment ............................................................................... 12
Table 2-1 Financial requirements ..................................................................................... 13
iv
List of Definitions
Attack window: Time duration in which a running program is vulnerable to an on-line
attack.
Bit: A computational quantity that can take one of two values: 0 or 1.
Brute force: A systematic, non-intelligent method of breaking an encryption algorithm
by simply trying all possible solutions.
Decryption: Process of using a secret key to convert an encrypted message into its
original format.
DES3: A multi-private key system used to encrypt information.
Encryption: Process of altering some information in a manner such that it is un-readable
to some third party unless they know a secret key.
Jump and link: Hardware instruction used for procedure calls, the instruction will store a
memory address to return to, and then jump to another location.
Link: Hardware instruction use to retrieve the return address and then resume execution
of a procedure from the location provided.
Memory space: The area where a processor stores the information it is using.
One-way encryption function: A function whose inverse is very hard to find, making the
reverse function as difficult to find intelligently as through brute force.
On-line attack: An attempt to compromise a system in real-time while the program is
running with its current key.
Pop: An operation where the topmost value is removed from the stack.
Processor cycle: The time it takes a processor to perform one add, subtract, or shift
instruction.
Push: An operation where a value is placed on the top of the stack.
Real-time: Done while the system is running, in parallel if possible, meaning that the
system cannot halt for a significant amount of time or lose performance to perform an
operation.
Reverse engineer: Any procedure that tries to obtain a private key or non-encrypted text
from an encrypted file.
v
RSA: Encryption method based on a public and private key obtained through prime
factors.
Runtime: The length of time that it takes a program to run from beginning to completion.
Simulated timing models: Generated by the VHDL compiler showing a circuits response
to specific inputs and the delays between reactions.
Stack: A section of memory and its associated registers used for temporary storage of
information in which the item most recently stored is the first to be retrieved.
VHDL: Programming language used to implement model hardware layouts in software
so that analysis may be performed.
32-bit architecture: A processor in which every value can be up to 32 bits in length.
vi
1. Introductory materials
1.1 Abstract
Today information security requires protecting data inside a system that was previously
inaccessible. One especially problematic attack is buffer-overflow. This is dangerous
because it takes advantage of flaws in many programs by overwriting a return address on
the stack to redirect control to a rogue program of the hacker’s choice. This type of
attack comprises 90% of all reported information security break-ins.
One solution is to implement an inline encryption scheme that prevents an attacker from
successfully overwriting the information hidden within the system. This project will
investigate the encryption strength necessary to protect data during a program’s brief
runtime. The project will also determine if hardware can be constructed to implement
this solution without a significant performance loss in the system. The results of these
studies will allow system designers to have a better understanding of the options
available to protect runtime data and increase information security.
1.2 Acknowledgements
Special thanks are in order to Dr. Akhilesh Tyagi for taking the time to explain in a clear
and patient manner all of the intricate details involved in the encryption scheme and for
dedicating his time to helping this project become a success.
1.3 Problem statement
The system must be able to encrypt and decrypt values in less than 40 processor cycles.
The encryption method shall be chosen based on how well it balances the needs for
performance and security. The keys must be of sufficient length to make it infeasible for
attackers to compromise them during the life of the program. The design of the system
must prevent programs from having access to these keys, and the system shall be able to
store multiple keys at once. The system must be able to simultaneously keep track of the
keys for all the programs executing at any given time. If analysis shows that the project
requirements are feasible, then a test model shall be built of the system.
The system will be kept within the required speed by choosing the correct combination of
key length and encryption method. The encryption method and key length shall be
determined by analysis of the available encryption schemes and the expected level of
security for a given key length. The memory space that the keys are stored in will be
protected from access by any running program by the processor itself. The keys shall be
associated in memory with the program they are protecting. The final working model will
be built in VHDL.
1
1.4 Operating environment
This encryption system will be operating in a computer system that needs to be secured
from buffer-overflow vulnerabilities. This type of security is needed in all forms of
computing. In the future, this process can be employed in standard personal computer
architecture or even integrated into existing platforms such as the Intel X86 architecture.
1.5 Intended users and uses
The encryption system being developed and evaluated can be utilized by nearly anyone
who uses a personal computer or business workstation. The home user can employ this
system to provide a greater level of security without needing to understand technical
security practices. The corporate environment can use this system to provide greater
stability and reduce the required overhead of maintaining business computers.
This system is intended to provide increased security to business and government users
so that their critical data is safe from intrusion. It is also intended to help both home
users and the global internet by slowing and preventing the spread of malicious worms
and viruses.
1.5 Assumptions
The design team assumes the following:
 Encryption method used will be RSA or DES.
 Programs run on this system will have a max runtime of 10 minutes.
 The system will be designed for 32-bit architecture.
 Necessary research material will be available.
 The required encryption speed is theoretically possible.
1.6 Limitations
The design team’s limitations:
 The encryption/decryption must be accomplished in under 40 processor
cycles.
 The encrypted values must fit in a 32-bit register.
 The final product must be completed in 8 months.
 The project poster shall be completed in 3 months.
 The cost of the project must stay below $150.
1.7 Expected end product
This project has several deliverables, ranging from hardware simulations to design
optimization decisions. The expected end product of the project will consist of an
analysis of encryption and decryption key size selection given an upper bound on the online attack time on the key, as well as a VHDL model of a hardware implementation of
both encryption and decryption steps with simulated timing models. All of these in
2
combination will lead to the final decision of whether or not a real-time encryption
scheme is feasible for buffer-overflow protection.
The first deliverable is formulated by performing an analysis of attack times and security
restrictions of encryption strength in order to find the minimal key size that ensures data
protection for a given time window. Once an appropriate key size has been determined,
construction can begin on the VHDL model.
The next deliverable will be a VHDL hardware implementation of an encryption and
decryption scheme based off of the given key size and some one-way encryption
function. This model will allow timing and efficiency analysis to determine whether or
not the model will be feasible for implementation in modern systems.
Finally, as a combination of the two deliverables, a final determination will be made in
regards to the feasibility for a real-time encryption scheme for protecting buffer-overflow
attacks.
3
2. Proposed approach and statement of work
2.1 Functional requirements
The following are the functions that the end product will perform.
Generate encryption key
The hardware will randomly generate an encryption/decryption key for each process as it
is executed on the computer system. This must be an efficient process to facilitate overall
success of the project. The key size will be restricted to a length so that encryption can
be performed in a timely fashion, while still maintaining a guarantee of security.
Store generated key securely
The key that has been generated for each process must be stored securely so that it is not
possible to break this system by attacking the key directly. Additionally, the key must be
easily accessed by the hardware to facilitate quick encryption and decryption of values.
A possible location would be in a hidden register inside the processor which was only
read-accessible by the encryption function.
Encrypt memory addresses from jump and link instructions
Upon execution of a jump and link instruction, the hardware will encrypt the return
address. The encrypted address will then be pushed to the stack just as a memory address
would be in a traditional operating environment. This encryption process shall not take
more than a few CPU cycles in order to maintain system performance.
Decrypt memory address upon link instruction
Upon execution of a link instruction, the hardware will decrypt the return address before
popping it from the stack. This decryption process shall not take more than a few CPU
cycles in order to maintain system performance.
2.2 Constraint considerations
Due to the nature of this project as a functional evaluation, there are no physical design
constraints. However, there will be functional constraints.
The encryption/decryption process shall be efficient
The encryption process shall take a period of time short enough so as not to make the
implementation of this system undesirable. The exact metrics for defining efficiency will
be determined by the project itself.
4
Key length shall be of appropriate size
The length of the encryption/decryption keys shall be of a length such that the above
constraint is obeyed, and the data will be secure from intrusion for an appropriate length
of time. The length of time deemed appropriate will be determined by the project itself,
but will be equivalent to the average running time of a process on a typical computer
system.
Hardware shall not require significant area
The area requirement of a hardware implementation of this encryption system shall not
be of significant size. The area shall be small enough such that the overall cost of
production of a microprocessor is increased by only a marginal amount.
2.3 Technologies considerations
The simulations designed for this project will take into consideration all technologies
under the scope of the simulator software. At present this is limited to 32 bit
architectures. There are multiple software options to consider for VHDL simulation.
Max+Plus II is the only readily available VHDL simulator at Iowa State University,
although other software packages will be investigated.
2.4 Technical approach
Initially, a determination on the encryption methodology must be made. The foremost
candidates and industry standards are RSA (see 4.4.1) and DES3 (see figures 2-1,2-2).
These encryption schemes will be analyzed, and once a decision has been reached, key
size analysis can begin.
5
Figure 2- 2 Function f in DES standard
Figure 2- 1 DES encryption process
To determine an appropriate key size for data security, programs that would be likely to
be attacked via a buffer-overflow vulnerability will be run in order to determine an
average time estimate for an on-line attack. Once an attack window has been established,
investigation can begin into the ability to reverse engineer the key.
At this point, an analytical model must be developed in order to determine the time
necessary to attain the encryption key through a brute-force attack. The details of this
attack, including the timing and likeliness of success must be carefully studied in order to
determine that the key size selection is sufficient to provide the desired protection. At
this point, it is possible to determine if the key size selection is adequate.
Finally, hardware samples of the encryption and decryption scheme will be implemented
in VHDL in order to provide detailed timing analysis to ensure that encryption and
decryption operations can be done in real-time without a significant performance hit to
the system.
6
2.5 Testing requirements
Testing will be done at various stages throughout the development; in fact, it is this
testing that will prove or disprove the feasibility of the encryption scheme. Initial tests
will be performed to analyze the key size requirements and the online-attack time that a
potential hacker would have. Multiple tests will then be run on the brute-force key
acquisition model, in order to get a mean time for breaking the encryption. Finally,
extensive testing must be run on the VHDL implementation to ensure that all encryption
and decryption works correctly, in addition to the timing requirements of operating in less
than the average time required for 40 instruction executions.
2.6 Security considerations
Security concerns have created the need to delve into the issues that this project
addresses. This project is only an evaluation of possible hardware cryptology schemes to
encrypt and decrypt return addresses on allocated stacks. There are no known detriments
to the project if a third party were to obtain knowledge of the project.
Security of the cryptology system is also essential. If the security of the encryption keys
is not adequate, the encryption hardware will not be useful. Security of the encryption
keys are beyond the scope of this project.
2.7 Safety considerations
This project will be simulation based and the end product is not physical. Since there
will be no interaction between the project team and any hardware there are no safety
concerns associated with this project.
2.8 Intellectual property
There are no known intellectual property concerns. All possible encryption algorithms
are public knowledge, and no use of patented or copyrighted data or processes will be
used in the development of this project.
2.9 Commercialization
The deliverables for this project are intended directly as a feasibility study. The
deliverables, although potentially marketable once refined at a later time, have no
immediate commercial value.
2.9 Risks and management
This project is designed to delve into the possibility of efficient and secure operations on
return addresses on the stack. The project is a risk in itself because there may not exist a
feasible method with acceptable overhead to encrypt the return addresses. All possible
7
methods will need to be considered and tested thoroughly to ensure the success of the
project. Also, the loss of team members due to unforeseeable reasons is possible. This
risk cannot be avoided and the team may need a replacement in the future. The
replacement would need to have a good understanding of encryption and would need to
quickly become familiar with the project and its progress. Inexperience with VHDL is
also a potential risk to the project timing. Though VHDL is not completely foreign to the
group there may be a certain learning curve before all members can effectively and
efficiently contribute time coding the project.
2.10 Milestones and evaluation
2.10.1 Milestones:
Design report: A document that will show the overall design and plan for the project.
Feasibility study: Research that will show if the project is possible. If it is possible, then
the best method to create it.
Final report: A document that will show the entire project and describe the end product.
Project plan: A document that gives the overall design of the project and the methods that
will be used to create the desired product.
Project poster: A poster that will act as a method for showing the intended project and
getting others interested.
VHDL model: A working model of the end product that implements the required
encryption.
2.10.2 Evaluation
After each milestone has been completed, the group will analyze how close it has come to
the desired outcome. If the groups meets or exceeds expectations, then it is on track for
the next part of the project. If the group has failed to complete a milestone for any reason,
the group’s methods and timelines will be re-evaluated so that it will not continue to
make the same mistakes.
2.11 Project tracking
A timeline has been developed that shows the schedules and deadlines for each part of
the project. Throughout the project development process the timeline will be used to track
actual progress versus expected progress. This will allow the group to better manage time
and resources in order to successfully complete the project in the allotted time.
8
2.12 Statement of work
Task Number 1 – Problem definition
Task Objective: An overall definition of the RSA encryption project
Task Approach:
- Discuss project with advisor to get an overall view of what is expected.
Task Expected Results: A thorough definition of the goals of the project.
Subtask Number 1A – Define problem
Subtask Objective: An overall definition of the RSA encryption project
Subtask Approach:
- Discuss project with advisor to get an overall view of what is expected.
Subtask Expected Results: A thorough definition of the goals of the project.
Subtask Number 1B - Identify constraints
Subtask Objective: To identify the constraints of the project.
Subtask Approach:
- Discuss required project constraints with advisor.
Subtask Expected Results: For the group to understand the design constraints.
Task Number 2 – Project research
Task Objective: To give the team an understanding of the resources and methods that
will be required to successfully complete the project.
Task Approach:
- Research the various encryption methods that are available through publications
and web sites.
- Discover and review any research that has already been done on the subject.
- Research the best key length based on speed and security for a given encryption
method.
Task Expected Results: To determine a method of encryption and an appropriate key
length that will give the required results for the project.
Subtask Number 2A – Research encryption methods
Subtask Objective: To learn about the available encryption methods
Subtask Approach:
- Research the various available encryption methods to discover which
would best fit the project constraints.
Subtask Expected Results: To discover the best method of encryption for the
project.
Subtask Number 2B – Research key lengths
Subtask Objective: To learn about key lengths and expected encryption speed.
Subtask Approach:
9
- Research how long the encryption process takes for the various possible
key lengths.
Subtask Expected Results: To discover the best key length for the encryption
project.
Subtask Number 2C – Research project feasibility
Subtask Objective: To discover if the RSA encryption project is feasible
Subtask Approach:
- Combine results from subtasks 2a and 2b to discover if any encryption
methods and key lengths meet the project constraints.
Subtask Expected Results: The group knowing if the encryption project is
feasible.
Task Number 3 – Project design / VHDL model
Task Objective: To create a working model of the encryption hardware.
Task Approach:
- Use VHDL to implement the results of the conducted research.
Task Expected Results: A working VHDL model of the encryption hardware.
Task Number 4 – Project reporting
Task Objective: To keep others informed on the status of the project.
Task Approach:
- Use a project plan, poster, design report, weekly emails, industrial review, and
final report.
Task Expected Results: Documents that give descriptions, the status, and the results of
the project.
Subtask Number 4A – Project plan
Subtask Objective: An overall plan of the RSA encryption project
Subtask Approach:
- Discuss project with advisor to get an overall view of what is expected.
- Create a timeline that will give an overall schedule for the project.
- Research the basic principles required for the project.
- Compile all information to create a plan for conducting the project.
Subtask Expected Results: A thorough project plan that can be used as a guide
for the project.
Subtask Number 4B – Web site design
Subtask Objective: Design a web site that will contain up to date information on
the project.
Subtask Approach:
- Create a basic layout for the site.
- Keep the website updated with the most current material.
Subtask Expected Results: An informative web site that is easily navigated.
Subtask Number 4C – Project poster
10
Subtask Objective: To create a visual aid that will inform others of the project
that will be created.
Subtask Approach:
- Develop a layout for the poster.
- Develop the poster content.
- Print the poster.
- Revise the poster and re-print if needed.
Subtask Expected Results: An informative visual aid that will create interest in
the project.
Subtask Number 4D – Design report
Subtask Objective: To create a report that gives the design of the encryption
system.
Subtask Approach:
- Add results from research to the original project plan.
Subtask Expected Results: A document that will give all of the information for
the design of the project.
Subtask Number 4E – Final report
Subtask Objective: Create a report that gives the final status of the project.
Subtask Approach:
- Include the research results.
- Include project results.
- Compile together all information learned throughout the project.
Subtask Expected Results: A report that will describe the results of the entire
encryption project.
Subtask Number 4F – Weekly emails
Subtask Objective: Keep the professor informed of the group progress.
Subtask Approach:
- Put all accomplished and in progress tasks into an email.
Subtask Expected Results: An informative email for the professor.
Subtask Number 4G – Industrial review panel / class presentation
Subtask Objective: Create a presentation that will inform others of the results of
the project.
Subtask Approach:
- Compile together all of the project information.
- Create an informative presentation.
Subtask Expected Results: An informative presentation that will show others the
results of the project.
11
3. Resources
3.1 Personnel
Professor Lamont has assigned four Iowa State University Computer Engineering
undergraduate students to complete the RSA encryption project within the next two
semesters (by May 2004). Ryan Babiarz, Chris Gray, Kyle Robertson and Kris Ruhland
are the four students that are to complete this project. Kyle Robertson will only work on
the project team for the first semester because he is enrolling in a study abroad program
for the spring semester. Ge Zhu is a graduate student already working on the project (or a
very similar one). It has not been determined yet how much of an impact Ge Zhu will
have on the team and the project. Professor Tyagi is the group’s advisor. He will be an
informational asset to the team. He will provide continual feedback and advice as the
student’s progress through the project steps. The following table provides the expected
time commitment by each of the members involved.
Table 2- 1 Personal time commitment (hours)
Name
Ryan Babiarz
Christopher Gray
Kyle Robertson
Kristofer Ruhland
Total
Task 1
14
10
11
10
45
Task 2
55
60
50
55
220
Task 3
7
7
8
8
30
Task 4
8
8
9
10
35
Task 5
40
50
45
55
190
Total
124
135
123
138
520
3.2 Other resources
Other resources that the RSA project group will require include the Iowa State University
ECPE Department labs. The software required for the project must compile VHDL code.
Max+Plus II is useful for VHDL modeling and is readily available in the ECPE
Department labs. Max+Plus II is also available online for student use. This will enable
the students to utilize their personal computers extensively throughout the project.
3.3 Financial requirements
The poster is the primary cost for this project. All of the remaining necessary resources
are readily available to the student team and the advisor.
12
Table 2 – 1 Financial requirements
Material
Poster
Labor at $10.50 per hour:
Ryan Babiarz
Christopher Gray
Kyle Robertson
Kristofer Ruhland
Expected Cost
$50
Actual Cost
N/A
Total w/o Labor
$50
Hours
124
135
123
138
Cost
$1,302
$1,418
$1,292
$1,449
Total Cost
$5,511
3.4 Schedules
3.4.1 Deliverables schedule
The following figure is a timeline of when deliverable items for this project are due, and
time frame that each will be worked on and completed.
Figure 3- 1 Project deliverables schedule
13
3.4.2 Project tasks schedule
The following figure is a timeline of when tasks for this project will be completed, and a
timeframe for continuing progress.
Figure 3- 2 Project tasks schedule
14
4. Closure materials
4.1 Project team information
The following is a listing of contact information for each team member, and faculty
advisor.
Client/faculty advisor:
 Dr. Akhilesh Tyagi
 391B Durham
Ames, IA 50011-2252
 Office Telephone: (515) 294-4396
 Fax Telephone: (515) 294-8432
 tyagi@iastate.edu
Student team members:
 Ryan M. Babiarz
 Computer Engineering
 4912 Mortensen Rd. #213
Ames, IA 50014
 Telephone: (443) 414-6818
 rbabiarz@iastate.edu













Christopher M. Gray
Computer Engineering
421 13th St.
Ames, IA 50010
Telephone: (515) 233-2777
cmgray@iastate.edu


Kyle R. Robertson
Computer Engineering / Economics
125 N Hyland Ave.
Ames, IA 50014
Telephone: (515) 292-2410
kr@iastate.edu
Kristofer M. Ruhland
Computer Engineering
307 S. Second St.
Ames, IA 50010
Telephone: (515) 233-9633
kruhland@iastate.edu
4.2 Closing summary
With the ever increasing necessity of computer security, it is time that industry starts
looking for ways to ensure data integrity from within. Due to creative exploits, even
internal system information may be compromised, which can result in an unauthorized
user taking control of an entire system. This plays a prominent role in today’s world
where things such as the power grid, air traffic control and nuclear reactors could be
abused to affect millions of people worldwide by a simple vulnerability such as a bufferoverflow.
One answer to this growing threat is an RSA based internal encryption scheme for return
addresses on the stack. If it is found feasible to implement, this solution would ensure
that over 90% of the modern computer infiltrations are stopped. This one project will
have profound consequences for security systems worldwide, and will allow system
administrators to have another means of protection in their network implementation.
15
The results of this project will provide a base-level analysis of the usefulness of an RSA
based encryption approach. Even if RSA is not found to be sufficiently fast, researchers
will at least have the ability to know that a different method should be implemented.
4.3 References

http://www.antilles.k12.vi.us/math/cryptotut/text/RSA.doc

http://www.cse.cuhk.edu.hk/~phwl/seminar.html
4.4 Appendices
Appendix A: RSA example
Figure 4- 1 RSA example
Step:
Preparation
a) Choose two primes p and q so
that their product n=p*q is
greater than the used alphabet
length M (i.e. here M=26).
a) Say p=3 and q=11, then n=33
b) Compute (n).
b) (33) = (3-1)*(11-1) = 20
2. Step:
Encryption
uses
the
public
key
(n,e)
a) Choose a public encoding key a) Here, possible values for e are 3,
e that has to be relative prime to 7, 9, 11, 13, 17, 19. Let’s pick e=3.
b) Encrypt as follows:
(n).
3. Step:
Decryption
uses
the
private key
(d,n)
a) The private decoding key d is
chosen as the inverse of e MOD
(n): e * d = 1 MOD (n)
Mathematically, find integers d
and k that fulfill: e * d = 1 + k *
(n) via the Extended Euclidean
Algorithm.
b) Now encrypt each plain letter S =18: 183 = 24 MOD 33
A = 0: 03 = 0 MOD 33
P by computing
F = 5: 53 = 26 MOD 33
E = 4: 43 = 31 MOD 33
C=Pe MOD n.
b) Decrypt by computing P=Cd
MOD n
16
a) d=7 since 3*7 = 1 MOD 20.
b)
247 = 18 MOD 33, 18=S.
07 = 0 MOD 33, 0=A.
267 = 5 MOD 33, 5=F.
317 = 4 MOD 33, 4=E.