Copyright © 2004 Michael X. Lyons. All rights reserved. Page 1 of 1 ECE 746 Secure Telecommunication Systems Mike Lyons Spring 2004 Project Specification version 2.0 March 10, 2004 Type of project: Software I propose to develop an educational application to support research into and teaching of cryptography. The application will allow modeling of cryptographic systems using modular components and inspection of processing within such models. For the purpose of this course, the project deliverables would include:  a design for the application;  a partial implementation, sufficient to demonstrate the educational utility of the application;  user documentation for the functions implemented. 1. Primary implementation: Language: Java Platform: Any platform supporting Java Compiler: Java 2 Platform, Standard Edition version 1.4.2 (or later) SDK Portability: See http://java.sun.com/j2se/1.4.2/system-configurations.html. Java is selected to provide as much platform-independence as possible. The application will be distributed as a signed Java archive. 2. Additional software required: For development: Public-domain Java implementations of cryptographic algorithms. See http://java.sun.com/products/jce/jce14_providers.html for a list of providers and http://www.bouncycastle.org/documentation.html for a specific example. For deployment: None. 3. Input/output: Inputs:  user interaction via a graphical user interface (GUI);  user-specified data files (e.g. plaintext, ciphertext, and keys);  user-specified model files (from previous sessions);  configuration data files (e.g. containing user preferences, GUI settings, etc).Copyright © 2004 Michael X. Lyons. All rights reserved. Page 2 of 2 Outputs:  graphical display of model content, showing algorithm and input/output modules and links between them;  graphical display of data (in user-selected form, e.g. binary, octal, hexadecimal, or Extended ASCII for bytes; binary or decimal for integers) input to and output from application modules;  user-specified data files (e.g. plaintext, ciphertext, and keys);  user-specified model files (to save modeling sessions for later re-instantiation); 4. Program functions: The application is intended to allow users to investigate the operation of cryptographic systems by modeling them as assemblies of functional components and observing the action of components as they process data. The primary purpose is not to encourage design of new algorithms (although nothing in the design would preclude that) but to promote understanding of the use of well-defined algorithms mechanisms for provision of confidentiality, authentication, key management and similar information security services. The application will present the user with a number of modules to be used as "building blocks" in creating models of cryptographic systems. These modules will include:  implementations of standard algorithms (e.g. DES, AES, IDEA, RSA);  basic functions for manipulating data (e.g. XOR, shift operators, shift registers, table lookups);  data input sources and output destinations, including GUI (keyboard input and screen text) and user-specified files;  data management functions (e.g. to create fixed-size blocks from a data file, with padding as required). (It may be possible to allow users to "plug in" custom-developed modules created in compliance with the interface defined for the application.) The user will design links between application modules to model the flow of data within systems. A link can connect a defined input for a component to any data source (including intermediate data within a system) or defined output from a component (including the same component, e.g. when modeling a linear feedback shift register (LSFR)) provided the data type is compatible (e.g. the block sizes match). A defined output may be connected to many inputs, but each input must have exactly one connection in a valid system. Control functions will be provided manage the operation of the system. These will include the ability to step through a process one step or cycle at a time, and the ability to examine and modify data (to investigate the impact on the operation and the output data produced) as it moves through the system. Assemblies of modules may be combined in a hierarchy to model complex systems (e.g. an assembly of Triple-DES-E-D-E could be a component in a higher-level model of a hybrid asymmetric/symmetric system). An example of an exercise using the application is provided in Appendix A.Copyright © 2004 Michael X. Lyons. All rights reserved. Page 3 of 3 To increase the educational value, certain metrics will be generated by the application. These may be used for comparing different implementations of a given algorithm (e.g. the "reference" and "optimized" implementations) or different algorithms performing the same function. A modeling session may be captured to a data file. This will allow continuation of the development process at a later date. It will also allow models to be exchanged between users (e.g. student could submit a model to an instructor). 5. Test procedures: Functionality: The function of the application will be tested according to the plan of experiments (below) and in accordance with the features designed and implemented, as documented. Performance: Since the primary purpose of the application is to demonstrate functionality, performance of the application itself is not important provided it is not unacceptably slow (in the opinion of the user). Acceptable performance will be evaluated in the survey. However, performance of the modeled algorithms will certainly be of interest to some users. The application will include functionality to allow the user to insert metrics in algorithm components and observe the totals through the component hierarchy. A simple metric could be the number of instructions in an iterative loop multiplied by the number iterations through the loop. These metrics will not necessarily represent accurate measurements of actual efficient implementations, but will allow some primitive analysis to be performed. 6. Plan of experiments: a. Develop GUI-based application with functions to select components, make connections and execute models. b. Obtain public-domain Java implementations of selected cryptographic algorithms, including DES. Wrap Java code to conform to the application component interface.