Contents

• Introduction
• The Members of the Group
• The Long-Term Plan
• Completed Programs and Current Developments
• Operation of Group
• Learning Process of Pascal and Programming
• Current Situation and Assessment
• Conclusion
• Appendix:
  • Cryptographer's "Toolkit" Index
  • List of all resources available for download
  • Bibliography

Introduction

With the assigned task of Classical Cryptography, this group has designed and will continue to design programs able to decode ciphertext. While each program will not necessarily decode an encrypted file immediately, it is the combination of these "tools" which provide a working cryptanalysis program. This "tool box" can be implemented to decode classically encrypted text, making available documents and information which can be accessed by the entire public, rather than a select few!

This report contains the direction and progress of our group during the completion of this task. Included is a reflection of initial goals compared to the final "Long-Term plan", an assessment of the progress made, operation as a group, and the processes of learning how to program in the Pascal Language. Accompanying the report is a comprehensive Appendix of the "Cryptographer's ToolKit Index" outlining the completed programs and portfolios that constitute the "Tool Kit" (also enclosed) and a bibliography of material accessed .......

Group Members

Brett Avery
Stuart Prescott
Michael Shuter
Jack Dermondy
David Grogan
Christopher Boshuizen

The Long-Term Plan

The assigned task was:

"Develop a menu-driven program that can be used as a tool to assist the process of cryptanalysis."

Our aim was thus to develop a comprehensive "Tool Box" of programs to decode ciphertext. The object was not to write one single program, nor programs that can instantly decode files (although some programs can achieve this on simple encryption techniques), the aim is to develop several program "tools" which would aid in the decoding of ciphertext. These programs are designed to work together to solve a problem, using each tool as it is needed. Hence, it is the combination of these tools which allow the breaking of any ciphertext.

Accompanying the list of "tools", is a manual describing the process needed to make an analysis and solve an encryption.(more info on how final program will work and how it is comprised) The group of programs can thus seen as a single "tool", a program driven from a list of commands from the manual. Being made in this modular fashion, the different tools required for the final program have been accomplished by individuals in the group. Working as individuals, but as a group, the process has concluded with the completion of the Ciphertext project.

• Reflection of Initial Analysis

In considering the original definition of the task, our group's Long-Term Plan had merit that remained throughout the development of the "tool box". However, the sheer expanse of the task of designing a system to decode any ciphertext encoded through classical means, did not present itself initially. Following is an appraisal of the initial plan and justification of the adaptations made.

As the variety of techniques used to classically encrypt code become apparent, more diverse and individually particular programs had to be developed. Because of the individual characteristics of some encryption methods, our original foundation of decryption programs became too general, and specific decryption programs for exclusive methods had to be developed.

The wide expanse of Classical Encryption techniques presented themselves in polyalphabetic encoding. Unlike the monoalphabetic methods, where the decoding process of a Caesar cipher or letter substitution could be easily adapted for different ciphertext, polyalphabetic ciphertext is very particular. Consequently, the diversion from general to exact decoding methods had to be created.

While our initial analysis perceived the task to involve a variety of programs that could be used in combination to decode ciphertext, this perception was much too general. Consequently, as the task has evolved, the "tool box" has also evolved to incorporate specific, individual pieces which can be used to solve unique problems.

Although the subsequent short-sightedness of the size of classical cryptography methods, our original plan showed merit in it's modular construction. With each member concentrating on separate "tools" there has been steady progress toward the completion of the "tool box". While we have been working on programs individually, broadening our knowledge of programming, we have essentially been working on solving a large problem as a group. This structure proved itself once consciousness of the expanse of the task was seen. Our Long-term plan now takes into account our discovered faults.

By allocating specific problems to individuals in the group, six unique cryptography techniques can be addressed at once, narrowing the expanse of diverse encoding methods. While there is a necessity to work as individuals, consistent conferencing as a group on each members progress and problems keeps the overall task a group challenge. The advantage of this segregated solution has been shown in individual progress, and the completion of the design of the "tool box".

While our initial analysis perceived the project to involve a variety of programs that could be used in combination to decode ciphertext, the expanse of the variety was not apparent. Inevitably, the "Long-Term plan" broadened to include these individual encryption methods. But because of the original formulation of the completion process, such an expansion as viable, even in Week ? when polyalphabetic encoding presented itself. Consequently, as the task has evolved, the "tool box" has also evolved to incorporate specific individual pieces which can be used to solve unique problems.

Assessment of Achievement

A list of programs that each member has created is shown in the Appendix. Here, this group has addressed a the broad types of cryptography, without extending outside the classical methods. This is were we have been determined, only concentrating on classical ciphers, which is the directive of the project. Unlike some groups who are investigating bit manipulation of characters, (ie playing around with the binary representation of letters), our group have not, and will not devote our time to obvious non-classical cryptography. The task had been defined, and we will not go beyond the boundaries to waste time! Considering the amount of code that is present in the Appendix, shows the achievement this group has made in the completion of the Classical Cryptography assignment.

Operation of Group

With developing a "tool box" to decode classical ciphertext being constructed in a modular fashion, incorporating this design into a group situation has had obvious success. Defined, updating and monitoring the progression of the "Long-term plan" was completed as a group, while individuals contributed programs to finish the task. Formulation and construction of the "tool box" has been the combination of each individual's efforts, though ultimately, these single achievements have been the product of our group.

• Strengths

Obviously, working as a group has decisive advantages, as each person has come to see. The group environment allows the support of the other members during the completion of personal tasks, the knowledge of many outweighing the knowledge of an individual. Consequently, we have found that by working together to solve a problem, the most effective (ie the best from a combination of ideas) approach is discovered.

Being in a group environment also encourages stimulating environment for learning spurred on by the your peers, the rate at which knowledge is learnt increases. Interest is always motivated by other team member's designs and thoughts, stimulating interest into the programming of the Pascal language, and being being able to solve problems. The group situation provides many motivational strengths, as well as support for the learning of Pascal and programming, especially in the PBL style of learning.

• Failings

The group advantages have performed well, however the group operation was not been optimally effective. Working on the allocation of individual activities progressed smoothly, but communication breaks down during the week's activities. With no formal "gatherings", except during the three hour prac time, the only indication of what each member is completing was supplied in the weekly allocating task list that is "emailed" to each member. No progress reports, or personal problems are formally made to the group as a whole, and verbal communication between some members was limited. Ensuring that each group member understands their task and was making positive progress was difficult.

Accompanying the failed means of communication, individuals showed a focus toward the completion of their own tasks, rather than looking at the completion of the whole task, ie the "tool box". The segregation of the solution to designing a decoding "tool kit" was a necessary measure to ensure an in depth construction. However, the modular construction had broken down too much, where the individual tasks no longer become small components, but small distinct parts that do not quite fit back into the initial project design. Our group sees this as the "borrowing effect":

small components of a large element are given to people to take home, but when they are returned, they are never exactly the way they were lent.

Subsequently, our large task is no longer coherent as it was planned originally. This is a problem that simple manipulation and regulation should be able to fix!

• Implementation of Improvements

During the project's progression, the group's failings were identified, and measures were implemented to try to combat these problems. Originally, there was a group submission containing the tasks that each member was completing within a week. Being made as a hard copy on paper, there was only a single sheet which could not be distributed to all group members. This method of submission stilled continued for the tutor's benefits, though the task list were also created as a soft copy on the network. Each person within our group now received a duplicate of the task list, indicating their own and other member's assignments. With such a record within the network, no doubling up of outgoing programs occurred. Reference to the previous task lists allowed information of what had been addressed, and what was remaining.

In respect to the lack of communication of individual progress, group deadlines were attempted. These group submission dates tried to ensure that individual tasks are completed, allowing group access to modify them so they could "fit" into the overall plan. Grouping these together also guaranteed immediate location of everyone's programs, rather than requiring individual searching. Consequently, a single directory was suggested, and finally implemented, which can be viewed in the Appendix. While in theory the idea appealed, but putting it into practice did not have the desired result. The time that tasks were completed often varied form their due date. In a group situation, made of piers, was hard to enforce such deadlines. Obviously, as the end drew near, programs were finally completed, making little time to prepare everything.

With the deadline restrictions in place, it was hoped that the lack of communication would be subsidised. The measures did eventually have a positive impact on the "borrowing effect", though not until a few weeks before the end of the project, when the "tool kit" began to be constructed. Thus, simple things, like the consistency of shell scripts finally occurred. Optimisation of group operation did subsequently follow the implementation of improvement measures.

Learning Process of Pascal and Programming

The task of this project required the development of a "tool to assist the process of cryptanalysis". While the immediate purpose was obvious - allow the viewing of encoded documents, the actual purpose of the exercise was to learn how to use a programming language, and to develop the basic concepts of programming. ie designing a solution to a problem. These fundamental elements of Computer Science have been learnt through the completion of the task.

• Learning Pascal

For the members in our group that had little or no experience in the Pascal language, initial weeks were spent learning the basics. This was combined with designing simple, but beneficial programs, which could be included in the "tool kit". As the level of Pascal knowledge grew, so did the difficulty and complexity of the weekly tasks. Progressive learning has been the objective, with all individual assignments requiring the search for new knowledge of how to solve the problem through Pascal.(Diary of tasks each week)

• Learning to Program

Because of the limited amount of information available concerning decoding in Pascal, the fundamentals of the Pascal language had to be adapted to create our own decryption "tools". During these creations, thought went onto how to design a solution, breaking the developmental process into a series of smaller problems. This method of solving a task reflects the process of programming.

The most important learning process has been consistent practice, caused by the allocation of consistent weekly tasks!

Learning how to program was achieved through group discussion on how to solve a problem (which is what programming tries to do). By identifying the elements that need to be addressed, a problem could then be seen as a combination of little parts. These parts could then be solved singularly quite easily. Recombining these parts created the completed task. This method became the basis of how to program.

To complement our group's ideas of how to program, reference to manuals like Oh! Pascal showed how to go about designing a program, without writing the program at the same time. The use of Pseudo code has found to be a simplistic way to map how to construct a program to complete a task. Expanding each time on the pseudo code, the final result is basically the completed program without the specific key commands that relate to Pascal. So, while developing programs in Pascal, we have also learnt the concepts of programming.

• Solving Problems

Through learning how to program, an idea of the procedures needed to tackle problems was developed. As noted before, one of the strengths of working as a group is the wealth of knowledge that is available. Thus tackling problems involved breaking them down into manageable segments, where the group would then voice ideas on how to go about solving each segment. The subsequent solution incorporated the most effective ideas, optimising the resultant solution.

This method is also adapted to individual projects, as each member used the group technique and applied it themselves to a single problem. The variety of ideas, in this case, came from the individual's research on the different approaches which could be made to come to a solution. However, working singularly lacks the diverse knowledge off a group.Subsequently, when a terminal problem occurs, the member can refer to the support of the entire group. It has been this such teamwork that was the foundation of this group : working individually, but as a group to complete the specified tasks.

• Creating Test Data

Learning Pascal and how to program has been hard, but there would be no substantial evidence that would support what we have learnt without test data. During the whole development of the "tool kit", test data has been used to check the validity of the various programs. However, further deduction was required just to perfect the testing procedure.

To begin with, known output test were performed to expend our knowledge of how to test programs, learning from successes or failures. Such visual checking has also been complemented with procedural testing, using the Boolean functions. This is an adaption of a Pascal function often reserved for other commands, which now uses a simple True or False test, determining a program's validity. We have observed that if a program "crashes" or does not complete a series of commands, then the Boolean function has found a fault within the program. Such a fault may not have been detected by a visual verification! The Boolean functions ensure that the program is working correctly. Examples of the use of these functions can be found in the code supplied in the appendix.

Once fluent in producing test data on a basic scale, more in depth analysis of the program's design was performed, demonstrated in the Appendix. By increasing the level of testing, and by determining the predicted results, the output from a program can be examined. With each progression of complexity of the testing procedure, knowledge was learnt on how to go about later tests. Again, the learning process has been like learning to program: adaption of initial and additional knowledge and applying the skills to newer, more complex programs.

Overall Assessment

Overall, our project progressed well, with most of the fundamental developmental work being complete. During the last, progress was slow due to the organisation of how to combine the whole project together. The Tool package currently consists of a variety of programs which we consider to be able to break codes of a classical format. More specific programs have now been developed, which are outlined in the Appendix. Though, the broad range of classical encryption available calls for other programs which are also listed. These further developed programs have complemented the fundamentals we have now, creating an in depth tool kit to decode classical ciphertext.

In order to correlate all the programs into a coherent cryptanalysis tool, consistency of shell scripts are were defined, and a manual on how to perform analysis' using our "tool kit" is to be completed. A guide to designing a good cryptanalysis package was planned, but as stated in previous reports, this would only appear if time permitted. Unfortunately, as time did not permit, the guide was not developed. We did, nevertheless, consider this to be an important addition, for there is no "worldly" benefit of the exercise if other people do not learn form our newly acquired knowledge. Our knowledge would hopeful help other people who were thrown into the predicament of designing the cryptanalysis program like we were.

Consequently, the project has not only broadened our knowledge on Pascal programming, but also the fundamentals of programming itself, both a a single and group basis. Designing the program in a modular fashion meant that assigning group tasks was essential, and "breaking" the solution into a series of smaller solutions was the only way for possible completion. Thus each person in our group has acquired the ability to use the Pascal language, with knowledge limits not lower than chapter 13 in Oh! Pascal. The task easily took our knowledge beyond this. Also the fundamentals of actually going about programming and also being able to work as a team to readily complete the task at hand and gasping the concepts of Computer Science.

Conclusion

On considering our progression through this task, and elements that each person has learnt, there is a feeling of satisfaction of the work completed. The general consensus from the group is that it has been a learning experience. And it has with happy feeling that we conclude this task.

Appendix

• Cryptographer's "Toolkit" Index
• List of all resources available for download
• Bibliography