INTRODUCTIONCryptographic SymbologyConceptual ModelArchitectureExecutionOutput-only processesRegister processesGraphical User InterfaceProcess ImplementationTest ModelsA simple LFSREffect of noise on stream ciphersFurther DevelopmentConclusionScreen capture images from the second model testECE-746-04B-001-PR-LYONS 1A Cryptographic Application Modeling Environment for Research and Analysis Michael X. Lyons, George Mason University Abstract—An interactive graphical environment is presented as an educational tool for teaching applications of cryptographic algorithms and other software systems. A design concept is shown, based on research into the efficacy of experiential learning in graphical environments. The implementation of the design allows for many different types of software components to be integrated with the system without rebuilding the system. The results of two test exercises are shown, validating the usefulness of the developed system as an educational aid. Index Terms—Cryptography, algorithms, models, education. I. INTRODUCTION EACHING cryptography, particularly at the undergraduate level, is difficult if (as is typical) the students have little or no experience with cryptographic technology. Examining algorithms in theory, using abstract representations, is much less effective than allowing students to experiment themselves, but cryptographic software is usually embedded in specific applications and amenable to low-level inspection. Numerous studies (especially [1]) have indicated that experiential learning is much more effective than reviewing abstract concepts or theoretical implementations. Unfortunately, it is difficult to provide an appropriate educational experience when teaching cryptography: the algorithms themselves tend to be overwhelmingly complex in implementation, and in practice they are typically embedded deeply in specific applications. For example, the application known as PGP (from its origins as Pretty Good Privacy) includes five symmetric encryption algorithms, three hash algorithms and three public-key algorithms, but it is designed to be integrated with other applications (e.g. email clients) [5]. It is not possible to access individual algorithms in isolation for analytical or experimental purposes. Existing cryptographic analysis tools typically focus on performance of specific algorithms, which are usually embedded in the tools. An example is the KRYPTOS package [6], which includes nine symmetric encryption algorithms, the RSA asymmetric encryption algorithm and several signature, hash and Message Authentication Code (MAC) algorithms, but is specifically designed to provide timing analysis of operation performed on data obtained from files. Manuscript received May 9, 2004. This work was produced as a requirement of ECE 746 Secure Telecommunication Systems, Spring 2004 semester, George Mason University (Instructor: Kris Gaj). M. X. Lyons is an Instructor of Information Technology in the School of Information Technology and Engineering at George Mason University, Fairfax, VA 22030 USA (email: [email protected]). The author presents a novel solution to the problem, in the form of software package named CAMERA (for "A Cryptographic Application Modeling Environment for Research and Analysis"). The package is intended to allow users to experiment with software components, specifically (but not limited to) cryptographic algorithms and related components. The scope of application of the package is broad, from low-level primitive operators (such as 1-bit registers and exclusive OR (XOR) functions, as used in linear feedback shift registers (LFSRs) [7], to complex systems incorporating multiple algorithms (see §VI.B below for an example). In contrast to existing applications which embed specific algorithms into the software, CAMERA uses sophisticated software techniques to allow run-time discovery of compatible software modules, which can be incorporated into system models created and edited by the user. The package includes a number of basic modules and samples of cryptographic algorithms encapsulated in the modular format, but the primary advantage of the design is the ability of the user to easily add any software component that meets the modular requirements. The design also allows for detailed examination of a modeled system as it is executed. The state of individual modular components can be inspected between model execution cycles, and even changed (e.g. to simulate the effect of noise or tampering). To enhance the learning experience and ease of use, the system uses a graphical user interface (GUI). The user is able to manipulate icons representing software modules and create links between them to model data flows. The GUI uses a platform-independent graphical implementation which is mapped to the native "look and feel" of the platform on which it is executed. II. CRYPTOGRAPHIC SYMBOLOGY Certain domains in the information processing field have well defined formal symbologies or notation schemes for representing data, hardware, software and related entities. For example, the symbols used for data processing flowcharts have been standardized for more than three decades [9], [10]. TECE-746-04B-001-PR-LYONS 2Unfortunately, a survey of available literature revealed no such standardization for symbols used in cryptographic diagrams. Significant differences are observed between sources (e.g. [11] and [14]) and even for different diagrams within a single source (e.g. [12] and [13]; [14], [15] and [16]). The author of the textbook used for this course confirmed in [18] that no formal symbology has been defined for cryptography. To accommodate existing variations in symbols used in potential user communities, CAMERA supports the use of custom icons for each component module. In modularizing a component for use with CAMERA, one of the required elements is the name of an image file in Graphics Interchange Format (GIF), Joint Photographic Experts Group (JPEG) or Portable Network Graphics (PNG) format (see [19] for a comparison of these three formats). As a reference for the initial implementation, and for users who do not have or want to use a pre-existing convention, the components packaged with CAMERA use icons developed in conjunction with the package. See Appendix Error! Reference source not found. for examples of these icons. III. CONCEPTUAL MODEL A. Architecture The high-level view of a CAMERA model is a finite state machine [20],