Next Generation Usability of Cryptography

Combining FlexiProvider and JCrypTool

Diplomarbeit von

Tobias Kern

zur Erlangung des akademischen Grades

Diplom Wirtschaftsinformatiker

Juli 2008

Technische Universität DarmstadtFachbereich Informatik

Fachgebiet Kryptographie und Computer Algebra

Betreuer: Dipl.-Math. Martin DöringGutachter: Prof. Dr. Johannes Buchmann

Eidesstattliche Erklärung

Hiermit versichere ich, die vorliegende Diplomarbeit ohne HilfeDritter und nur mit den angegebenen Quellen und Hilfsmittelnangefertigt zu haben. Alle Stellen, die aus den Quellen entnom-men wurden, sind als solche kenntlich gemacht worden. DieseArbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungs-behörde vorgelegen.

Darmstadt, 10. Juli 2008 Tobias Kern

Abstract

This work introduces the integration of the FlexiProvider cryptographic li-brary in the JCrypTool e-learning application. This presents the softwarearchitecture of the implementation part, as well as the interface used to ac-cess the novel interface of the FlexiProvider library, called FlexiAPI. Duringthe description of the implementation part, this work presents the novel fea-tures which have been realized during this project.This integration project makes JCrypTool the �rst application to utilize thenew FlexiAPI, which is an alternative and superior to the Java Cryptogra-phy Architecture.JCrypTool is the only cryptographic application which enables the user toutilize all algorithms of a cryptographic library without requiring the appli-cation to be modi�ed when new algorithms are added to the library. Addi-tionally, all of these algorithms can be fully parameterized by the user.

Acknowledgements

I would like to thank everybody who supported me during this project.

My supervisor Dipl.-Math. Martin Döring, who worked in close co-operation with me throughout this entire project. Without his e�orts andenergy to make FlexiProvider what it is today, this work would not havebeen possible.

My manager at Deutsche Bank, Prof. Bernhard Esslinger, who initialisedthe CrypTool project, always supported me and gave me the necessary free-dom and trust to pursue this project as I have seen �t. Together withProf. Dr. Johannes Buchmann he enabled the cooperation between theJCrypTool project and the chair of Prof. Buchmann at Technische Univer-sität Darmstadt.

My co-workers at Deutsche Bank Henrik Koy, Jörg Schneider and allother colleagues of the Cryptography Competence Center for their ad-vice and support.

My parents, Gertrud and Wolfgang, who supported me throughout myentire life. And last, but de�nitely not least, my beloved girlfriend Kim,who keeps my life in balance and made sure I stayed on track.

I

Contents

List of Figures IV

List of Tables VI

Listings VII

List of Acronyms VIII

1 Introduction 1

1.1 Scope and Motivation . . . . . . . . . . . . . . . . . . . . . . 11.1.1 JCrypTool . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 FlexiProvider . . . . . . . . . . . . . . . . . . . . . . . 31.1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Structure of this Work . . . . . . . . . . . . . . . . . . . . . . 5

2 Software Architecture 6

2.1 Overview of the Architecture . . . . . . . . . . . . . . . . . . 62.1.1 Eclipse Rich Client Platform . . . . . . . . . . . . . . 62.1.2 JCrypTool . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Design of the FlexiProvider Feature . . . . . . . . . . . . . . . 122.2.1 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Extension Points . . . . . . . . . . . . . . . . . . . . . 18

3 Accessing FlexiProvider 20

3.1 Overview of the FlexiAPI . . . . . . . . . . . . . . . . . . . . 203.1.1 Algorithm Types . . . . . . . . . . . . . . . . . . . . . 203.1.2 Supporting Services . . . . . . . . . . . . . . . . . . . 233.1.3 Instantiation with FlexiAPI . . . . . . . . . . . . . . . 24

3.2 Additional Information in an XML Document . . . . . . . . . 253.2.1 Information Retrieval from the FlexiAPI . . . . . . . . 253.2.2 XML Elements . . . . . . . . . . . . . . . . . . . . . . 26

II

4 Realization of the Integration 34

4.1 JCrypTool Keystore . . . . . . . . . . . . . . . . . . . . . . . 344.1.1 org.jcryptool.crypto.keystore . . . . . . . . . . . . . . 344.1.2 org.jcryptool.crypto.�exiprovider.keystore . . . . . . . 37

4.2 FlexiProvider Feature . . . . . . . . . . . . . . . . . . . . . . 394.2.1 org.jcryptool.crypto.�exiprovider . . . . . . . . . . . . 394.2.2 org.jcryptool.crypto.�exiprovider.algorithms . . . . . . 434.2.3 org.jcryptool.crypto.�exiprovider.operations . . . . . . 474.2.4 org.jcryptool.crypto.�exiprovider.engines . . . . . . . . 51

5 Conclusion 53

5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.2 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A About the Project 55

A.1 Overview of Plugin Structures . . . . . . . . . . . . . . . . . . 55A.1.1 FlexiProvider Resource Plugin . . . . . . . . . . . . . 55A.1.2 Algorithms Plugin . . . . . . . . . . . . . . . . . . . . 56A.1.3 Operations Plugin . . . . . . . . . . . . . . . . . . . . 56A.1.4 Engines Plugin . . . . . . . . . . . . . . . . . . . . . . 57A.1.5 Keystore Contribution Plugin . . . . . . . . . . . . . . 57A.1.6 Keystore Plugin . . . . . . . . . . . . . . . . . . . . . . 57

A.2 Con�guration . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.3 Used Tools and Libraries . . . . . . . . . . . . . . . . . . . . . 59

B AdminTool 60

B.1 Information Retrieval from FlexiProvider . . . . . . . . . . . . 60B.2 Existing Package Structure . . . . . . . . . . . . . . . . . . . 61B.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Bibliography 62

List of Figures

1.1 Start Screen of the CrypTool Application . . . . . . . . . . . 21.2 Welcome Page of JCrypTool on Mac . . . . . . . . . . . . . . 3

2.1 Overview of the Plugins Comprising the Eclipse RCP . . . . . 72.2 Look at the Inside of a Plugin . . . . . . . . . . . . . . . . . . 82.3 Extension Point De�nition . . . . . . . . . . . . . . . . . . . . 92.4 Extension De�nition . . . . . . . . . . . . . . . . . . . . . . . 102.5 Default Layout of the FlexiProvider Perspective . . . . . . . . 112.6 Example of a Wizard . . . . . . . . . . . . . . . . . . . . . . . 122.7 JCrypTool Core Feature . . . . . . . . . . . . . . . . . . . . . 132.8 Additional Features of the JCrypTool Core . . . . . . . . . . 132.9 Top-Level Architecture of the FlexiProvider Feature . . . . . 142.10 Plugins of the FlexiProvider Feature . . . . . . . . . . . . . . 142.11 Elements of the newOperation Extension Point . . . . . . . . 182.12 Elements of the performFlexiProviderOperation Extension Point 192.13 Elements of the keyStoreActions Extension Point . . . . . . . 19

3.1 UML Class Diagram of IMetaEntry . . . . . . . . . . . . . . 263.2 UML Class Diagram of IMetaKeyGenerator . . . . . . . . . . 263.3 UML Class Diagram of IMetaAlgorithm . . . . . . . . . . . . 27

4.1 UML Class Diagram of the Keystore's ITreeNode . . . . . . . 354.2 Screenshot of JCrypTool's Keystore . . . . . . . . . . . . . . . 364.3 UML Class Diagram of AlgorithmDescriptor . . . . . . . . 404.4 UML Class Diagram of BlockCipherDescriptor . . . . . . . 404.5 UML Class Diagram of SecureRandomDescriptor . . . . . . 404.6 UML Class Diagram of AlgorithmsXMLManager . . . . . . . . 414.7 UML Class Diagram of MetaOID . . . . . . . . . . . . . . . . 424.8 UML Class Diagram of Reflector . . . . . . . . . . . . . . . 424.9 UML Class Diagram of ITreeNode . . . . . . . . . . . . . . . 434.10 Screenshot of the FlexiProvider Algorithms View . . . . . . . 444.11 UML Sequence Diagram: Initializing a new Algorithm . . . . 454.12 UML Class Diagram of Input Factory . . . . . . . . . . . . 464.13 UML Sequence Diagram for Creating Dynamic User Interfaces 46

IV

4.14 UML Class Diagram of DynamicComposite . . . . . . . . . . 474.15 Screenshot of the FlexiProvider Operations View . . . . . . . 484.16 UML Class Diagram of EntryNode . . . . . . . . . . . . . . . 484.17 UML Sequence Diagram for Performing an Operation . . . . 494.18 UML Class Diagram of FlexiProviderEngine . . . . . . . . 52

A.1 The JCrypTool Product . . . . . . . . . . . . . . . . . . . . . 58A.2 The JCrypTool Product Con�guration . . . . . . . . . . . . . 58

List of Tables

2.1 Overview of Plugin Designators and Convenience Names . . . 15

3.1 Overview of Di�erences between the JCA and FlexiAPI . . . 213.2 Overview of FlexiAPI Algorithm Types supported by JCrypTool 223.3 Overview of FlexiAPI Supporting Services used by JCrypTool 23

4.1 Overview of Entries in a Keystore Alias . . . . . . . . . . . . 37

VI

Listings

2.1 Code-Snippet of the INewOperationListener Interface . . . . . 182.2 The Abstract Class AbstractKeyStoreAction . . . . . . . . . . 193.1 Example for Signature Instantiation . . . . . . . . . . . . . . 243.2 Instantiation of Standard Parameters . . . . . . . . . . . . . . 253.3 Top-Level Elements of the algorithms.xml Document . . . . . 263.4 Example for the XML Structure of Algorithm Types . . . . . 273.5 Example for a Block Cipher XML Element . . . . . . . . . . . 293.6 Scheme for ParameterSpec XML Elements . . . . . . . . . . . 293.7 Example for a ParameterSpec XML Element . . . . . . . . . 303.8 Scheme for KeyGenerator XML Elements . . . . . . . . . . . 313.9 Example for a KeyGenerator XML Element . . . . . . . . . . 323.10 XML Element for CBC Mode . . . . . . . . . . . . . . . . . . 323.11 XML Element for the PKCS #5 Padding Scheme . . . . . . . 324.1 Example of a Persistently Stored Entry in the Operations View 504.2 Example of an Exported Entry of the Operations View . . . . 50

VII

List of Acronyms

API

Application Programming Interface

ASCII

American Standard Code for Information Interchange

ASN

Abstract Syntax Notation

ECC

Elliptic Curve Cryptography

GUI

Graphic User Interface

HMAC

Keyed-Hash Message Authentication Code

IDE

Integrated Development Environment

IV

Initialization Vector

JCA

Java Cryptography Architecture

MAC

Message Authentication Codes

MFC

Microsoft Foundation Classes

VIII

NF

Number Fields

OID

Object Identi�er

OSGi

Open Services Gateway initiative

PQC

Post Quantum Cryptography

PRNG

Pseudo Random Number Generator

RCP

Rich Client Platform

SPI

Service Provider Interface

SWT

Standard Widget Toolkit

XML

Extensible Markup Language

Chapter 1

Introduction

This chapter provides an overview of scope, motivation, objectives and struc-ture of this work.

1.1 Scope and Motivation

The scope of this work is provided by the JCrypTool and FlexiProviderprojects. These projects are introduced in this section, along with the moti-vation of this work.

1.1.1 JCrypTool

In order to provide a proper introduction to JCrypTool the CrypTool project,which spawned JCrypTool, has to be introduced as well.

The CrypTool Project

The CrypTool project [1] has been started in 1998 in the information securityawareness program of an international bank. Its objective is increasing theawareness of information security and cryptography. In the year 2000, theCrypTool application has been published as freeware. Three years later, thesource code of the CrypTool application has been published and the projectbecame open source [2]. For many years CrypTool has been developed incooperation with universities. CrypTool is used at universities to improvethe quality of the education in the area of cryptology and is now mainlydeveloped by students in the scope of practical exercises, bachelor and mastertheses.Hence, the two main pillars of the CrypTool project are in-�rm trainingwith the objective of increasing security awareness, as well as usage anddevelopment by students at universities with the objective of improving theireducation in the area of cryptology.The CrypTool project has won many awards over the years. For instance,

1

Figure 1.1: Start Screen of the CrypTool Application.

in 2004 it has been awarded the TeleTrusT Förderpreis and was a �nalist inRSA Europe's Information Security Award [2]. In 2008, it has been chosenas a selected landmark in the Deutschland - Land der Ideen [1] initiative.

The JCrypTool Project

The JCrypTool project [3] has been started in January 2007. Its objectivehas been set to become the platform independent successor to CrypTool. Be-cause the classic CrypTool application is based on the C++ programminglanguage and Microsoft Foundation Classes (MFC), it is di�cult and tediousto use it on Non-Windows platforms. Java has been selected as the program-ming language for JCrypTool with regard to providing a platform indepen-dent solution. As the foundation for the application itself, the Eclipse RichClient Platform (RCP) [4] has been chosen. Eclipse RCP's modular and�exible plugin architecture allows for a modular and distributed develop-ment, easy extensibility and maintainability. With regard to the distributeddevelopment of CrypTool and JCrypTool, which has become a cornerstoneof both projects, this �exibility is a major bene�t of JCrypTool.Another bene�t of the Eclipse RCP is the fact, that it provides out-of-thebox features, like the UI workbench1, which can be used and do not have tore-invented. This allows developers to concentrate on their own know-how inthe area of cryptology without needing to worry about developing too muchdistracting infrastructure services. Figure 1.2 shows the welcome page ofJCrypTool, which is displayed the �rst time a user starts the JCrypTool ap-

1Some relevant features, like the workbench, are explained later in this work.

2

Figure 1.2: Welcome Page of JCrypTool on Mac [3].

plication. The �rst Milestone version for developers of JCrypTool has beenreleased in August 2007. The results of this work will contribute a majorpart to the second Milestone version for developers, which will be releasedin the summer of 2008.

1.1.2 FlexiProvider

FlexiProvider [5] is an open source cryptographic library developed for theJava 2 Platform [6] by the chair for Cryptography and Computer Algebraat Technische Universität Darmstadt. The FlexiProvider library providesmodern and state of the art cryptographic algorithms. Among these algo-rithms are symmetric ciphers like AES [7], asymmetric ciphers like RSA [8],or algorithms based on elliptic curves, like ECDSA [9].FlexiProvider is based on a modular architecture. The algorithms providedby the FlexiProvider library can be divided into four groups, which coverdi�erent areas of cryptography, namely

• modern standard cryptography,

• Elliptic Curve Cryptography (ECC),

• Post Quantum Cryptography (PQC) and

• and cryptographic algorithms based on Number Fields (NF).

3

Some of the algorithms contained in these providers, e.g. RSA or AES, arein production use.FlexiProvider is fully compliant with the Java Cryptography Architecture(JCA) [10]. Additionally, it features its own Application Programming In-terface (API) called FlexiAPI. FlexiAPI provides an alternative and superiorway of accessing cryptographic than would be possible with the JCA. Thiswill be explained later in this work.

1.1.3 Motivation

JCrypTool is an e-learning platform developed in the Java programming lan-guage and FlexiProvider is a cryptographic library developed for Java. Theintegration of the FlexiProvider library into JCrypTool is bene�cial for bothprojects.On the one hand, FlexiProvider gains more public attention by its integra-tion into JCrypTool. Additionally, due to the highly dynamic nature of thisintegration, JCrypTool becomes a test suite for all services provided by theFlexiProvider cryptographic library and its novel interface, FlexiAPI.On the other hand, JCrypTool gains state of the art cryptographic algo-rithms. Since FlexiProvider is constantly developed and extended by stu-dents during practical exercises, FlexiProvider will feature more algorithmsin the future which will increase the number of algorithms available to JCryp-Tool. As becomes obvious, both projects gain synergy e�ects by this inte-gration.Two bachelor projects at Prof. Buchmann's chair at Technische UniversitätDarmstadt dealt with implementing a dynamic application that utilized theentire FlexiProvider library before [11] [12]. The aptly called Flexible appli-cation which resulted from these two bachelor projects formed the foundationfor this project. Even though it has been decided that a completely new im-plementation is required to ful�l the objectives presented in the next section,the Flexible application can be considered as a predecessor to this project.

1.2 Objectives

The main objective of this work is to integrate the FlexiProvider libraryinto JCrypTool. This integration has to be designed and performed in away which makes changes in JCrypTool's source code unnecessary, when-ever new algorithms are added to a new release of the FlexiProvider library.In order to achieve this objective, FlexiAPI will be used, since the JCA doesnot provide su�cient information to achieve this level of �exibility.2 In ad-dition to FlexiAPI, an Extensible Markup Language (XML) document willbe used as the focal point of information about FlexiProvider. This XML

2As stated earlier, this will be explained in more detail later in this work.

4

document will be automatically generated with information retrieved fromFlexiProvider via FlexiAPI and amended with additional information, whichis required to initialize and instantiate cryptographic services.Since JCrypTool exclusively uses FlexiAPI to access FlexiProvider, JCryp-Tool becomes the �rst application to use this novel API and acts as a demon-stration project for FlexiAPI's advantages over the JCA.Users are able to enter custom parameters for all algorithms provided byFlexiProvider.

1.3 Structure of this Work

The following chapters provide an insight into this work's implementationpart.Chapter 2 provides an overview of the software architecture. In order tolay the foundation for understanding the architecture, an introduction tothe Eclipse RCP is provided prior to the actual software architecture of thisproject.In order to create an understanding how the interface between JCrypTooland FlexiAPI is realized, chapter 3 provides the necessary information onFlexiAPI and the structure and content of the algorithms.xml XML doc-ument, which is used as JCrypTool's focal point of information on Flexi-Provider.Chapter 4 presents details of the actual implementation of this project anddiscusses challenges which have been identi�ed and solved during the imple-mentation phase.The results of this project is summarized and presented in chapter 5. Thiswork concludes with an outlook on further developments.

5

Chapter 2

Software Architecture

This chapter introduces the software architecture of the project. First, theEclipse RCP's and JCrypTool's architectures are described on which thiswork is mainly based.Afterwards, the software architecture of the project itself is introduced andexplained. With regard to establishing a common naming convention andeasier reading of this work, the implementation part of this project will bereferred to as the FlexiProvider feature for the remainder of this work.

2.1 Overview of the Architecture

This section introduces the basics of the Eclipse RCP and JCrypTool onwhich this work is mainly based.

2.1.1 Eclipse Rich Client Platform

Plugins form the basic building blocks of Eclipse. The minimum set of plug-ins which is required to develop rich client applications is called the EclipseRCP.A rich client application consists of this set of plugins and additional plug-ins which provide speci�c services to the rich client application [13]. Suchapplications are installed on the client machine and provide all required func-tionalities and services. Rich clients based on the Eclipse RCP can utilizethe services provided by the Eclipse RCP.Some of the services provided by the Eclipse RCP are responsible for userinteraction, managing plugins and the runtime. Figure 2.1 provides anoverview of the RCP plugins. As can be seen in �gure 2.1, the RCP consistsof several interdependent plugins. These plugins are brie�y described below,as well as the services they provide:

• OSGi: The plugin model of Eclipse is based on an implementation ofthe Open Services Gateway initiative (OSGi) R4.0 speci�cation (See

6

UI Workbench

Runtime JFace

SWTOSGi

Action setsEditorsPerspectivesViewsWorkbench

UI Toolkit

Widgets

ExtensionsApplicationsProducts

Plugins/BundlesServices

Figure 2.1: Overview of the Plugins Comprising the Eclipse RCP. (Based on[13], p. 15.)

[13], p. 18). It provides the framework for handling plugins in Eclipse.In a nutshell, the OSGi framework provides Eclipse with a componentmodel. Additionally, the way in which information is used to uniquelyidentify plugins is inspired by the OSGi framework. In Eclipse, it isusual to use Java package names as identi�ers for the plugins and use[major.minor.service.quali�er] tuples as version numbers.

• Runtime: The runtime plugin hosts some essential services, e.g. theapplication model and the extension registry, which will be explainedin more detail later in this chapter. The application model in Eclipsecan be compared to a main() method in a normal Java program. An-other service which is o�ered by this plugin is the so called products.Eclipse can be executed by specifying an application1, but all brandingcontexts, like icons or a splash screen, are contained in a product �le(See [13], p. 20.).

• SWT: The Standard Widget Toolkit (SWT) provides standard GUIcontrols like menus or fonts. It has been designed to utilize the windowsystem provided by the operation system for which it is implemented.Simply speaking, SWT is a layer on top of existing windowing systemswhich simply exposes these native widgets whenever possible (See[13],p. 22f.).

• JFace: One level above SWT, JFace facilitates a GUI toolkit utilizingSWT widgets. Among the components o�ered by JFace are dialogs,frameworks for wizards or preferences. Together with actions and view-ers, this forms the basis of the Eclipse UI (See [13], p. 22.)

• UI Workbench: Just like JFace sits one layer above SWT, the work-bench is located on top of JFace. It provides a contribution based UI

1An application in Eclipse refers to the main class which launches the program.

7

extensibility and de�nes windows, perspectives, views, editors and ac-tions. Some of these components which are relevant within the scopeof this work will be explained in more detail later in this chapter (See[13], p. 23.).

Plugin Architecture

Figure 2.2: Look at the Inside of a Plugin.

As can be seen in �gure 2.2, a plugin is comprised of multiple elements.The src folder contains the source code of the plugin. Since plugins will bedeployed as a .jar �le, each plugin contains a MANIFEST.MF �le. This �lecontains details about the plugin and its dependencies to other plugins [13].A developer may require extending the services of a plugin. In order toenable other plugins to contribute their services to a particular plugin, thisplugin needs to specify an extension point, which is explained in detail inthe following section. This extension point can then be extended by the con-tributing plugin, and hence add its own services. Information on extensionpoints and extensions is stored in the plugin.xml �le [13].

Extension Points Whenever the services provided by a plugin need tobe extended, a plugin may specify an extension point. An extension pointrequires a schema in order to be correctly registered at runtime. This exten-sion point schema is an XML �le and contains information which is requiredby extensions. This information speci�es optional and mandatory attributes,which have to be supplied by the extending plugin. An extension can onlybe successfully registered with an extension point, if this information is cor-rectly provided. Only then the services of the extending plugin can be addedto the services of the plugin which speci�es the extension point.The Eclipse Integrated Development Environment (IDE) o�ers an easy touse interface which permits the speci�cation of an extension point. This isshown in �gure 2.3. Among the information speci�ed by an extension pointis the number of how many plugins may extend it. This can be seen in the

8

Figure 2.3: Extension Point De�nition.

top left side of �gure 2.3. The displayed extension point speci�es that anunlimited number of extensions may extend this extension point.Additionally, the extension point can specify attributes. This speci�es in-formation which the extending plugin has to supply. This information mayrefer to resources, like icons, or Java interfaces or abstract Java classes, whichhave to be implemented by the extending plugin. This is displayed on theleft side of �gure 2.3.Information supplied by the extending plugin will be used by the declaringplugin in order to perform the speci�ed service when it is required. This isin compliance with the lazy-loading policy of Eclipse and JCrypTool, whichstates, that a service should only be loaded into memory when it is required.This way, the initial memory footprint of the application is minimized.

Extension Extension points declare what information has to be providedby the extension. Figure 2.4 displays the corresponding extension to theextension point de�nition displayed in �gure 2.3. This particular extensionspeci�es the location of the Java class, which implements the Java interfacespeci�ed by the extension point in �gure 2.3. This Java class will be in-stantiated by the extension registry at runtime. For this instantiation, theno-arguments constructor is used. After this instantiation, the Java classand its services can be accessed by the application.

9

Figure 2.4: Extension De�nition.

Graphic User Interfaces

Graphic user interfaces are another signi�cant part which is provided by theEclipse RCP. In order to provide the user with a familiar look and feel whileusing the rich client application, Eclipse uses SWT [14] and JFace [15] todeliver a native look and feel (See [13], p. 5).

Perspectives and Views A typical user interface in Eclipse consists ofa main window, called the workbench. The layout of this workbench is not�xed and can be customized by users at runtime. Dedicated layouts, calledperspectives, can be de�ned and customized to suit speci�c application re-quirements.Perspectives may contain two di�erent types of elements, editors and views.Figure 2.5 shows a perspective with three open views and an empty editorarea, in which editors can be displayed.There are some fundamental di�erences between editors and views. Editorsare shared between perspectives, e.g. an open editor will be open in all per-spectives. Additionally, editors form the anchor point to which the layout ofperspectives can be adjusted.In contrast to editors, the positions and states of views are bound to spe-ci�c perspectives. The same view can be used by di�erent perspectives andbe located at a di�erent place in the layout. Another di�erence is the wayactions are handled by editors and views. Editors contribute their actionsto the main toolbar and menu of the workbench, while views feature theirown local toolbars and menus which will be �lled with action and menucontributions speci�ed by the view itself (See [13], p. 102).

Wizards Frameworks for other GUI components are provided by the EclipseRCP, as well. An example for a wizard page is displayed in �gure 2.6. Thecustomizable information area in the top of each wizard page can be usedto provide the user with information on what information he is required toenter on the current page.The middle component can be customized to satisfy the requirements of an

10

Figure 2.5: Default Layout of the FlexiProvider Perspective.

application. The buttons in the bottom part of the wizard page can be usedto �ip through the di�erent wizard pages, which lead the user through aninput work�ow.This central area is of particular interest, because the contents of this areahave to be created at runtime in order to facilitate the graphic user interfacecorresponding to the requirements of speci�c algorithms.

2.1.2 JCrypTool

JCrypTool is a rich client application which utilizes the Eclipse RCP. Oneof the policies of JCrypTool is to remain as compliant to Eclipse standardsand conventions as possible. Componentization and enabling developers tofocus on their knowledge in the area of cryptology, rather than focusingon developing the infrastructure, are the �rst and foremost themes of theEclipse community (See [13], Chapter 1). These themes are strictly followedby the JCrypTool community. Because JCrypTool's main developer poolis comprised of students developing plugins as part of practical exercises ortheses, it is a bene�t that they are able to concentrate on implementing theirknowledge in the area of cryptology and are able to utilize the infrastructureprovided by the Eclipse RCP and JCrypTool. Figure 2.7 shows the core fea-ture of JCrypTool, which constitutes the JCrypTool RCP. The JCrypToolcore consists of multiple features. This feature is accompanied by other fea-tures, which provide additional core services. In addition to the JCrypTool

11

Figure 2.6: Example of a Wizard.

RCP, the core feature contains all cryptographic providers, currently Flexi-Provider, the default provider and JCrypTool's partner project of choice,as well as the Bouncy Castle provider. Additionally, the CoDec library [16],which provides Abstract Syntax Notation (ASN)[17] encoding and decoding,is part of this feature, since FlexiProvider depends on this library.Another feature contains all editors which are used by JCrypTool. Currently,this feature contains JCrypTool' standard text editor and a hexadecimal ed-itor.For every release of JCrypTool, these core features are augmented by otherfeatures containing plugins which provide classic and modern cryptographicservices. However, since the FlexiProvider feature will become part of theJCrypTool core, these cryptographic plugins and features are not explainedhere, since they are considered out of scope for this work. They can bereviewed and downloaded on the JCrypTool Plugins website [18].

2.2 Design of the FlexiProvider Feature

The design of the FlexiProvider feature has been driven by usability. On theone hand users should be able to enter custom parameters for algorithms.On the other hand users shall be able to manually specify any appropriatekey in the keystore for usage with parameterized algorithms. Additionally,once parameterized algorithms should be available for future use, so as notto burden the user with having to enter the same custom parameters everytime an algorithm is required.Following the themes of the Eclipse RCP and JCrypTool, the FlexiProviderfeature has been designed as a collection of plugins. Figure 2.9 provides anoverview of the architecture of the FlexiProvider feature. If �gures 2.8 and2.10 are compared to each other, it will be noticed, that both contain anorg.jcryptool.crypto.keystore plugin in the org.jcryptool.crypto feature.

12

Figure 2.7: JCrypTool Core Feature.

Figure 2.8: Additional Features of the JCrypTool Core.

Because JCrypTool's current keystore is rudimentary at best, it is part ofthis work to implement a user friendly keystore, as well.The actual FlexiProvider feature consists of �ve plugins. Each of these plug-ins contributes one speci�c service. One of the major design principles of theFlexiProvider feature is minimizing dependencies between plugins. In orderto achieve this, extension points are used whenever applicable. This way, thearchitecture remains �exible. With regard to respecting the declared exten-sion points, the architecture even permits the exchange of plugins, withouta�ecting other plugins or the services contributed by the FlexiProvider fea-ture as a whole.

13

Figure 2.9: Top-Level Architecture of the FlexiProvider Feature.

2.2.1 Plugins

This section introduces the individual plugins of the FlexiProvider feature.An overview of these plugins is shown in �gure 2.10. Each of these plugins,

Figure 2.10: Plugins of the FlexiProvider Feature.

with the addition of the new org.jcryptool.crypto.keystore plugin andthe de.flexiprovider library plugin, will be explained in detail with regardto the services they provide. Because plugin identi�ers are based on Javapackage names, they are somewhat tedious to handle. For the remainder ofthis work, the plugins will be referred to by a convenience name. Table 2.1

14

presents an overview of all plugins and their respective convenience namesfor easier reading of this work.

Actual Plugin Designator Convenience Name

de.flexiprovider FlexiProvider library plugin

org.jcryptool.crypto.

keystore

Keystore plugin

org.jcryptool.crypto.

flexiprovider.keystore

Keystore contribution plugin

org.jcryptool.crypto.

flexiprovider

FlexiProvider resource plugin

org.jcryptool.crypto.

flexiprovider.algorithmms

Algorithms plugin

org.jcryptool.crypto.

flexiprovider.engines

Engines plugin

org.jcryptool.crypto.

flexiprovider.operations

Operations plugin

Table 2.1: Overview of Plugin Designators and Convenience Names (in Al-phabetic Order).

de.�exiprovider

The FlexiProvider library plugin contains the FlexiProvider library. Despitethis plugin already being a part of the JCrypTool core, it has been extendedto meet the requirements of the FlexiProvider feature. The managementclasses of this plugin will be extended in order to making the algorithms.xml�le accessible to other plugins.

org.jcryptool.crypto.�exiprovider.keystore

JCrypTool's current keystore contains one default RSA key pair for per-forming the proof-of-concept algorithms contained in the Milestone 1 releaseversion. However, no functions for adding or removing keys are included inthe current keystore.This project includes the development of a new keystore which provides allrequired functionalities. The keystore itself must be independent of any cryp-tographic library which may be included in JCrypTool in order to remaingenerally accessible. This implicitly restricts the actual keystore to use theJCA with regard to keys that can be added to the keystore.With regard to the security of the stored keys, all keys are protected by pass-words. Whenever a private or secret key is accessed, the user is promptedfor a key protection password. This key protection password is a mandatory

15

requirement whenever new entries are added to the keystore.In order to enable a user-friendly handling of the keys, the contents of thekeystore are displayed to the user in a View. With regard to a clear and com-prehensible presentation, a structure for storing the has been implemented.This structure is based on Contacts which may possess all available keytypes, i.e. secret keys, key pairs and public keys.Additionally, drag and drop support has been implemented to enable theuser to drag keys from the keystore to other parts of JCrypTool user inter-face components. Since this drag and drop requires accessing the contentsof the View, a layer has been introduced between the View and the actualcontents of the keystore which prevents constantly prompting the user toenter key protection passwords.In order to incorporate speci�c actions to the keystore, the keyStoreActionsextension point has been implemented. By keeping actions for importingand generating keys out of the actual Keystore plugin it's independence fromcryptographic service providers is maintained. However, functions with re-gard to exporting secret keys, key pairs and certi�cates can be included in thekeystore, since these elements are independent of cryptographic providers.

org.jcryptool.crypto.keystore

The keystore which has been implemented as part of this project providesstoring and loading of secret keys, key pairs and public keys. Public keysare stored in the form of X.509 [19] certi�cates.These services are added as part of the Keystore contribution plugin, whichenables FlexiProvider speci�c secret keys and key pairs to be generated andimported into JCrypTool's keystore. This is achieved by extending the key-StoreActions extension point which is declared by the Keystore plugin.

org.jcryptool.crypto.�exiprovider

This plugin has been designed a as a shared resource container which pro-vides Java classes, e.g. interfaces and abstract classes required by extensionpoints, as well as services required by other plugins. This way redundantimplementations in the other plugins and interdependencies between the plu-gins are avoided.The most important service o�ered by this plugin is the parsing of the al-gorithms.xml �le and hosting of descriptor classes, which are a common re-source for multiple plugins. The algorithms.xml �le will be retrieved from theFlexiProvider library plugin and translated into an object structure whichcan be accessed by other plugins of the FlexiProvider feature. This processis performed only once during the start-up of the FlexiProvider feature.

16

org.jcryptool.crypto.�exiprovider.algorithms

All algorithms which are speci�ed in the algorithms.xml �le are o�ered inJCrypTool. In order to provide the user with the ability to select any algo-rithm a View has been implemented. The algorithms are arranged in a treestructure and sorted alphabetically by algorithm types.Additionally, the user can parameterize algorithms. Default values are used,if the user does not enter custom parameters manually.This is achieved by implementing a dynamic wizard architecture which leadsthe user through the distinct steps of the parameterization. This includesdevising a system, which takes information on how the content of the wiz-ard pages are initialized with information retrieved from the algorithms.xml�le. The contents and the layout of the wizard pages are not hard-codedlike usual GUI masks. They are initialized at runtime with the retrievedinformation.The resulting algorithm parameters are handed over to the Operations plu-gin. The extension point newOperations (See Chapter 2.2.2) has been estab-lished and implemented for this exchange.

org.jcryptool.crypto.�exiprovider.operations

Parameterized algorithms are persistently stored so that they can be used atany time after their initialization. In order to o�er parameterized algorithmsto the user, and not force him to immediately execute the algorithm rightafter the parameterization, they will be displayed in a View which is part ofthis plugin. This View enables the user to select from di�erent previously pa-rameterized algorithms, choose input and output destinations, specify keysand select the mode of operation of the algorithm.The resulting fully parameterized operation are handed over the Enginesplugin, which will handle the actual operations. The extension point perfor-mOperations (See Chapter 2.2.2) has been established for this purpose.

org.jcryptool.crypto.�exiprovider.engines

This plugin provides engine classes for all algorithm types. These enginesare subclasses of a super class called FlexiProviderEngine, which containsall shared methods which are required by all engine classes. By means of theperformOperations extension point, the respective engine classes are instanti-ated and initialized to perform the corresponding operation. For the purposeof handling size of arbitrary size, cipher streams have to be implemented ineach engine class.

17

2.2.2 Extension Points

This section introduces all three extension points which are used by theplugins to communicate amongst each other.

newOperations

This extension point is responsible for notifying all extending plugins about anew operation which has been parameterized and created. Figure 2.11 showsthe details of this extension point which is declared by the Algorithms plugin.All extending plugins are required to implement the INewOperationListener

Figure 2.11: Elements of the newOperation Extension Point.

interface. This interface contains an abstract method, which leaves the de-tails of the implementation to the extending plugins. Listing 2.1 displays thisinterface, which is speci�ed in the listenerClass attribute of this extensionpoint.

public interface INewOperat ionListener {public void newOperation ( Algor i thmDescr iptor

d e s c r i p t o r ) ;}

Listing 2.1: Code-Snippet of the INewOperationListener Interface.

performFlexiProviderOperation

Figure 2.12 displays the elements of this extension point, which is declaredby the Operations plugin. This extension point is very similar to the newOp-erations extension point. Its listenerClass attribute requires the extendingplugin to implement the INewOperationListener interface, as well.

keyStoreAction

This extension point is declared by the Keystore plugin. It is used to addactions to the keystore. Figure 2.13 displays the elements of this exten-sion point. The keyStoreActions extension point demands all information

18

Figure 2.12: Elements of the performFlexiProviderOperation ExtensionPoint.

Figure 2.13: Elements of the keyStoreActions Extension Point.

which is required to include and display the action. This includes a name forthe action, the type of the action which can either be: newSymmetricKey,newKeyPair and import. Extending plugins have to implement the emptyabstract class AbstractKeyStoreAction, which provides type safety and re-quired abstract methods of the super class.

public abstract class AbstractKeyStoreAction extends

Action {}

Listing 2.2: The Abstract Class AbstractKeyStoreAction.

Additionally, an icon, a text which will be displayed and a tooltip text haveto be speci�ed. These attributes increase the level of accessibility of theactions which are integration into the menus of the Keystore View. Theicons and texts speci�ed by the extension are used to display the action tothe user.

19

Chapter 3

Accessing FlexiProvider

JCrypTool accesses information from the FlexiProvider library in di�erentways. FlexiProvider's own API, called FlexiAPI, is used to retrieve infor-mation directly from the library. Additionally, information which cannot beretrieved from the library directly is delivered in form of the algorithms.xml�le.

3.1 Overview of the FlexiAPI

FlexiAPI extends the interfaces and Service Provider Interface (SPI) classesprovided by the JCA. The interfaces are extended to establish a 'top-layer'within FlexiProvider, and the SPI classes are implemented in a di�erentway than the JCA. For instance, in the FlexiAPI four distinct cipher typeshave been implemented with regard to enforcing a separation between sym-metric and asymmetric ciphers. With the JCA, all ciphers, symmetric andasymmetric, are addressed over the same Cipher class instance. Table 3.1provides an overview of the di�erences between the JCA and FlexiAPI.

3.1.1 Algorithm Types

Table 3.2 provides an overview of the FlexiAPI algorithm types which aresupported by JCrypTool. These algorithm types are brie�y introduced in thischapter in order to establish a common understanding and to demonstratethe diversity of these algorithms types. The names of these algorithm typesare derived from the naming conventions of the FlexiProvider library.

Asymmetric Block Ciphers

These algorithms are asymmetric ciphers which encrypt plaintexts of a lim-ited size. This size depends on the size of the public key which is used forencryption. The size of the resulting cipher text is �xed and depends on the

20

Description JCA FlexiAPI

Architecture Provider based Registry based

Cipher engines One engine class for allcipher types

Dedicated engine classesfor di�erent cipher types

Algorithm instantia-tion

Engine based Registry based

Algorithm registra-tion

Provider based Registry based

Registration of sup-porting services

N/A Registry based

Standard parameters N/A Available for certain al-gorithms

Support for Java ME N/A Yes

Table 3.1: Overview of Di�erences between the JCA and FlexiAPI.

public key, as well. One of the most famous examples for such an asymmetricblock cipher is RSA [8].

Asymmetric Hybrid Ciphers

These asymmetric ciphers encrypt plaintexts of arbitrary size. Usually, theyinternally use a symmetric cipher for encrypting. ECIES [20] is an examplefor this algorithm type.

Block Ciphers

These algorithms encrypt plaintexts of arbitrary size by splitting the plain-text into blocks, which are encrypted separately (see [21], Chapter 7). Aso called mode is used to specify dependencies between the blocks. Someof these modes (e.g. Cipherblock Chaining (CBC)) require an initializationvector (IV) and other modes, like Cipher Feedback (CFB), require addi-tional parameters. In case the size of the plaintext is not a multiple of thecorresponding block size, a padding scheme is used to extend the plaintextto the required size. Perhaps the most famous example of a block cipher isRijndael, or AES [7].

Ciphers

These algorithms are ciphers which do not �t into one of the above cate-gories. One example is password-based encryption (PBE) [22], which usesan internal block cipher for its operation.

21

Algorithm Type Description

AsymmetricBlockCipher asymmetric block ciphers (e.g. ElGa-mal, RSA)

AsymmetricHybridCipher asymmetric hybrid ciphers (e.g.ECIES, McEliece)

BlockCipher block ciphers (e.g. TripleDES, Rijn-dael)

Cipher other ciphers (e.g.PBE, PBE2)

Mac message authentication codes (e.g.CBCMac, HMac)

MessageDigest message digests (e.g. MD5, SHA1)

SecureRandom secure randoms (e.g. BBS, ECPRNG)

Signature signatures (e.g. DSA, ECDSA)

Table 3.2: Overview of FlexiAPI Algorithm Types supported by JCrypTool.

Message Authentication Codes

A Message Authentication Codes (MAC) algorithm combines a secret keywith a plaintext of arbitrary size and computes the so called MAC value. Thisvalue is used to verify the integrity and authenticity of the plaintext (see [21],Chapter 9). The Keyed-Hash Message Authentication Code (HMAC) [23] isan example for this algorithm type.

Message Digests

Message digest algorithms compute a �xed-size checksum, the so called hashvalue, of a given plaintext (see [21], Chapter 9). Message digests are used toperform message integrity checks. SHA-1 [24] is perhaps the most prominentexample.

Secure Randoms

Random values are a basic necessity in many cryptographic algorithms (see[21], Chapter 5). Secure Randoms, or Pseudo Random Number Generator(PRNG), generate pseudo-random values of a given size. One example isECPRNG [25].

Signatures

Signature algorithms compute a digital signature for a given plaintext. Thissignature can be used to verify the correctness of the plaintext and to au-thenticate the identity of the message's sender (see [21], Chapter 11). One

22

example is the Digital Signature Algorithm (or Digital Signature Standard)(DSA) [26].

3.1.2 Supporting Services

The algorithm types introduced in chapter 3.1.1 are supported by di�erentsupporting services. These services cover storing and generating algorithmparameters, as well as generating secret keys and key pairs. Table 3.3 pro-vides an overview of supporting functions.

Supporting Service Description

AlgorithmParameterSpec Contain algorithm parameters.

AlgorithmParameters Provide encoding and decoding of algo-rithm parameters.

AlgorithmParameterGenerator Generate algorithm parameters.

KeyPairGenerator Generate key pairs.

SecretKeyGenerator Generate secret keys.

Table 3.3: Overview of FlexiAPI Supporting Services used by JCrypTool.

AlgorithmParameterSpec

AlgorithmParameterSpec1 is an empty top level interface used for typesafety and grouping. Sub-classes of AlgorithmParamterSpec provide al-gorithms with container classes which contain appropriate parameters, e.g.RijndaelParameterSpec.

AlgorithmParameters

The parameters contained in AlgorithmParamterSpec classes are only avail-able during the runtime of an application. For storing additional parametersan implementation of the AlgorithmParameters class has to be provided.This FlexiProvider class provides support for encoding and decoding of pa-rameters. Encoded parameter values can then be used to store algorithmparameters persistently.This implicitly requires, that a corresponding AlgorithmParameters classexists for all AlgorithmParameterSpec classes. If no implementation is pro-vided, it won't be possible to store parameters for the algorithm in questionand all parameters entered by the user will be lost after a restart of JCryp-Tool.

1For easier reading, Java package descriptions have been omitted.

23

AlgorithmParameterGenerator

JCrypTool o�ers the possibility to enter parameters manually. Default pa-rameters can be generated by subclasses of AlgorithmParameterGenerator,which exist for certain algorithms.In order to initialize instances of AlgorithmParameterGenerator, dedicatedinstances of AlgorithmParameterSpec are available. These feature defaultvalues, which enable the generation of default parameters without user in-teraction.

KeyPairGenerator and SecretKeyGenerator

Instances of KeyPairGenerator generate key pairs for algorithms whichrequire asymmetric key pairs. Parameters for initializating instances ofKeyPairGenerator classes are provided by according AlgorithmParameter-

Spec classes.Similar to key pair generators, instances of SecretKeyGenerator generatesecret keys for symmetric ciphers.

3.1.3 Instantiation with FlexiAPI

One of the di�erences between FlexiAPI and the JCA is the way in whichalgorithms are registered and instantiated. Whereas the registration in JCAis based on providers, the registration of algorithms and parameters in Flexi-API is based on a central registry class. Since FlexiProvider consists of morethan one provider, this requires the addition of all four providers, if onewants to access the entire FlexiProvider library via the JCA.With FlexiAPI all four providers only need to be registered with the cen-tral registry class. All algorithms and supporting services are registered andavailable through the central Registry class.

Algorithm Instantiation

Factory methods (See [27], chapter 3.) are available for all algorithm types.JCrypTool uses these methods to instantiate the algorithm engine classes.Listing 3.1 shows an example instantiation of the signature engine class withDSA.2

Signature dsa = Reg i s t ry . ge tS ignature ( "DSA" ) ;

Listing 3.1: Example for Signature Instantiation.

2All algorithms have to be registered with the Registry class before they can be ac-

cessed.

24

Parameter Instantiation

In contrast to the JCA, FlexiAPI allows the pre-de�nition of standard pa-rameter sets for algorithms. These can be registered with algorithms andaccessed through FlexiAPI's Registry class. The method signature for ac-cessing standard parameters is displayed in listing 3.2.

Vector getStandardAlgParams ( St r ing algName )

Listing 3.2: Instantiation of Standard Parameters.

Especially for complex parameters, like elliptic curves, this enables the userto choose from these prede�ned parameters. This way, the user does nothave to enter many di�erent parameters manually, if he wishes to use thesestandard parameters.

3.2 Additional Information in an XML Document

Information which is not available through the FlexiAPI's Registry classis taken from an XML document which is bundled together with the Flexi-Provider library for JCrypTool. Additionally, this XML document also con-tains the information available through the Registry class. This informationis included for convenience purposes and serves as JCrypTool's focal pointof information on FlexiProvider and the FlexiAPI.

3.2.1 Information Retrieval from the FlexiAPI

Most information in the XML document is generated automatically and re-trieved from the FlexiAPI. For instance, this includes the relationship be-tween algorithms and the corresponding instantiation of their accompanyingAlgorithmParameterSpec classes. Information retrieval from FlexiProvideris performed in the AlgorithmsRegistry class in the FlexiProvider resourceplugin. For each algorithm, a descriptor class is �lled with all available in-formation. In order for a concise representation of retrieved information, theinterfaces IMetaEntry, IMetaAlgorithm and IMetaKeyGenerator have beendesigned. IMetaEntry is the top-level interface and is displayed in �gure 3.1.It contains methods used by both of its sub interfaces, IMetaAlgorithm andIMetaKeyGenerator, which are displayed in �gures 3.3 and 3.2, respectively.The descriptor classes de�ned by these interfaces are used throughout the

project to access information and serve as a layer between the algorithms.xml�le and JCrypTool.As can be seen in �gure 3.3, the IMetaAlgorithm interface contains a largenumber of methods. During development it has become apparent, that onecentral interface for all algorithm types3 is a better solution than having

3See table 3.2.

25

Figure 3.1: UML Class Diagram of IMetaEntry.

Figure 3.2: UML Class Diagram of IMetaKeyGenerator.

dedicated interfaces for each algorithm type. With regard of enforcing theseparation between algorithms and supporting services the only interface re-quired to accompany IMetaAlgorithm is the interface IMetaKeyGenerator.

3.2.2 XML Elements

Information contained in the descriptor classes is used to create the XMLdocument. The root element and the top-level children of the algorithms.xmldocument is displayed in listing 3.3:

<?xml version=" 1 .0 " encoding="UTF−8" ?><Flex iProv ide r version=" 1 . 6 . 0 ">

<AsymmetricBlockCiphers /><AsymmetricHybridCiphers /><BlockCiphers /><Ciphers /><Macs /><MessageDigests /><Modes /><KeyPairGenerators /><PaddingSchemes /><ParameterSpecs /><SecretKeyGenerators />

26

Figure 3.3: UML Class Diagram of IMetaAlgorithm.

<SecureRandoms /><Signature s />

</Flex iProv ide r>

Listing 3.3: Top-Level Elements of the algorithms.xml Document (inalphabetic order).

Each of these top level elements contains information about di�erent algo-rithms and supporting functions retrieved through FlexiAPI which can bemanually amended with additional information. Since JCrypTool relies onthis XML document to correctly access the FlexiProvider library, it is impor-tant for future developers to comply with the policy set forth in this chapter.As can be seen in listing 3.3, the root element contains an attribute spec-ifying the version of the library. Since every new release of FlexiProvideris accompanied by a dedicated XML document, this attribute is used forverifying matching versions of the XML document and the library.

Algorithms

Listing 3.4 displays the scheme for XML elements which describe algorithmsand their required information.

<ALGORITHM_TYPE c l a s s="<f u l l y q u a l i f i e d c l a s s name>"oid="<oid s t r i ng>">

<Names>Name1 ,Name2</Names><ParameterSpec c l a s s="<f u l l y q u a l i f i e d c l a s s

name>" />

27

<KEY_GENERATOR c l a s s="<f u l l y q u a l i f i e d c l a s s name>" />

<StandardParams>Param1 , Param2</StandardParams><ParameterGenerator c l a s s="<f u l l y q u a l i f i e d

c l a s s name>"><ParameterSpec c l a s s="<f u l l y q u a l i f i e d

c l a s s name>" /></ParameterGenerator>

</ALGORITHM_TYPE>

Listing 3.4: Example for the XML Structure of Algorithm Types.

• ALGORITHM_TYPE : This placeholder can be replaced by any algo-rithm type displayed on the left-hand side of table 3.2. These elementscontain two attributes, class and oid.The class attribute is mandatory and must contain a fully quali�edclass name (e.g. de.flexiprovider.core.rijndael.Rijndael) whichis used as a unique identi�er. JCrypTool relies on this particular at-tribute not only for identi�cation purposes, but also to build the treestructure in the FlexiProvider Algorithms View (See chapter 4.2.2).The oid attribute is optional and only used, when an OID is registeredfor the algorithm. Both attributes are generated automatically.

• Names: The child element Names is mandatory and contains all namesregistered for the algorithm. If more than one name is registered, theentries have to be separated by a comma. The available names aretaken from FlexiAPI.

• ParameterSpec: These elements are added automatically, if the re-spective algorithm has an according AlgorithmParameterSpec classregistered through the class attribute serves as a reference to an entryin the ParameterSpecs top-level element. By using the class names asreferences, redundant de�nitions are prevented.4

• KEY_GENERATOR: Since algorithms in FlexiProvider require keysof a certain format, all algorithms require information about the appro-priate key generator. This is provided by two di�erent XML elements,SecretKeyGenerator for secret keys and KeyPairGenerator for asym-metric key pairs. These values can replace the KEY_GENERATORplaceholder. These child elements contain only one mandatory at-tribute named class. Usually, information on key generators is addedautomatically. However, if a key generator class is available, but notexplicitly registered, it has to be added manually.

4This link structure is pursued to keep the size of the XML document within reasonable

size and not contain redundant speci�cations for the same entity.

28

• StandardParams: This element is optional. If an algorithm has stan-dard parameters registered, this element will be added automatically.

• ParameterGenerator elements di�er in some way from the rest of theelements. Since every ParameterGenerator is speci�c to one algorithm,all information required to initialize ParameterGenerator classes iscontained within this element. This especially refers to the Param-eterSpec child element, which speci�es the AlgorithmParameterSpec

class associated with this ParameterGenerator class.

Depending on the algorithm type, these XML elements may contain addi-tional mandatory child elements. For block ciphers, this is the BlockLengthschild element, which contains information on all supported block length ofthe algorithm. The default value has to be explicitly stated in the defaultattribute. The block lengths values are separated by commas. In case of asingle supported block length, the default attribute shall be used.Listing 3.5 displays an XML example for a block cipher.

<BlockCipher c l a s s="de . f l e x i p r o v i d e r . core . rc5 .RC5"><Names>RC5</Names><ParameterSpec c l a s s="de . f l e x i p r o v i d e r . core . rc5

. RC5ParameterSpec" /><SecretKeyGenerator c l a s s="de . f l e x i p r o v i d e r .

core . rc5 . RC5KeyGenerator" /><BlockLengths default="64">32 ,64 ,128</

BlockLengths></BlockCipher>

Listing 3.5: Example for a Block Cipher XML Element.

AlgorithmParameterSpecs

As described in the previous section, information on AlgorithmParameterSpec

classes is automatically retrieved from FlexiAPI and included in the XMLdocument. Listing 3.6 provides a scheme for the structure of ParameterSpecelements.

<ParameterSpec c l a s s="<ful ly_qual i f i ed_class_name>"><Constructor>

<Parameter name="<parameter name>" type="<parameter type>">parameterd e s c r i p t i o n</Parameter>

</Constructor></ParameterSpec>

Listing 3.6: Scheme for ParameterSpec XML Elements.

29

• ParameterSpec: This element contains a class attribute. This attributeis used as a unique identi�er. This element only contains one childelement, the Constructor element.

• Constructor : This element contains automatically retrieved informa-tion taken from the FlexiProvider source code. The following policiesare in place to ensure that only one constructor is used:

� There are no forbidden parameter types. Forbidden parametertypes refer to parameters, which originate from the java.securityor javax.crypto packages. The Java class java.math.BigIntegeris also forbidden.

� None of the parameters is of the type de.flexiprovider.common.mode.ModeParameterSpec.

� Only supported parameter types are present in the XML �le. Cur-rently int, byte[], String, FlexiBigInt, PBKDF2ParameterSpecand QuadraticIdeal are supported.

� If more than one constructor remains, the constructor with thehighest number of parameters is selected.

After these policies yield a single constructor, the source code is auto-matically analyzed to retrieve information on the constructor's param-eters. This information is then added to the XML element. The infor-mation contained in the Constructor element is later used to dynam-ically create graphic user interfaces, which is explained in great detaillater in this work. This is achieved by using information from this ele-ment to instantiate the corresponding AlgorithmParameterSpec withthis constructor. Listing 3.7 displays an example for a ParameterSpecelement.

<ParameterSpec c l a s s="de . f l e x i p r o v i d e r . core . rc5 .RC5ParameterSpec">

<Constructor><Parameter name="numRounds" type=" in t ">

the number o f rounds ( 8 . . . 1 2 7 )</Parameter>

<Parameter name="wordSize " type=" in t ">the word s i z e (16 , 32 , or 64 b i t s )</Parameter>

</Constructor></ParameterSpec>

Listing 3.7: Example for a ParameterSpec XML Element.

30

KeyGenerators

Key generators are used to supply algorithms with appropriate keys. Thekeys generated by these generators are stored in JCrypTool's key store andcan be used to perform cryptographic operations with FlexiProvider algo-rithms. Listing 3.8 provides a scheme for key generator XML elements.

<KEY_GENERATOR c l a s s="<f u l l y q u a l i f i e d c l a s s name>" oid="<oid>">

<Names>name1 , name2</Names><ParameterSpec c l a s s="<f u l l y q u a l i f i e d c l a s s

name>" /><KeyStrengths default="<de f au l t value>">value1 ,

va lue2</KeyStrengths><ParameterGenerator c l a s s="<f u l l y q u a l i f i e d

c l a s s name>"><ParameterSpec c l a s s="<f u l l y q u a l i f i e d

c l a s s name>" /></ParameterGenerator>

</KEY_GENERATOR>

Listing 3.8: Scheme for KeyGenerator XML Elements.

• The KEY_GENERATOR placeholder can be replaced by SecretKey-Generator or KeyPairGenerator, respectively. Analogous to algorithmXML elements, the class attribute is mandatory and the oid attributeis optional.

• The Names child element is mandatory, automatically retrieved troughFlexiAPI and added to the XML document.

• The ParameterSpec child element is mandatory, as well. Where avail-able, it is automatically added. However, in case an AlgorithmParameter-Spec class available but not registered, it has to be added manually tothe XML �le. For this reason, the AdminTool described in appendix?? has to be developed.

• The KeyStrenghts element is mandatory as well and has to be addedmanually, since information on supported key strengths is not availablewith FlexiAPI.

• The ParameterGenerator elements located in the KEY_GENERATORelements work analogous to their counterparts of the ALGORITHM_TYPE elements.

Listing 3.9 provides an example for a key generator element:

31

<KeyPairGenerator c l a s s="de . f l e x i p r o v i d e r . core . dsa .DSAKeyPairGenerator" o id=" 1 . 3 . 1 4 . 3 . 2 . 1 2 ">

<Names>DSA</Names><ParameterGenerator c l a s s="de . f l e x i p r o v i d e r .

core . dsa . DSAParameterGenerator"><ParameterSpec c l a s s="de . f l e x i p r o v i d e r .

core . dsa . DSAParamGenParameterSpec" />

</ParameterGenerator><KeyStrengths default="1024" />

</KeyPairGenerator>

Listing 3.9: Example for a KeyGenerator XML Element.

Modes and PaddingSchemes

Two special types of XML elements are currently hard coded in the XMLdocument. These types describe details for modes and paddings, which areused by block ciphers. Since modes and padding schemes are not likely to bechanged often, we decided to include them hard coded. Listing 3.10 showsan example for the CBC mode and listing 3.11 displays an example for thePKCS #5 padding scheme.

<Mode c l a s s="de . f l e x i p r o v i d e r . common .mode .CBC" id="CBC"name=" (CBC) Cipherblock Chaining">

<ParameterSpec c l a s s="de . f l e x i p r o v i d e r . common .mode . ModeParameterSpec" />

</Mode>

Listing 3.10: XML Element for CBC Mode.

• The Mode element contains a mandatory class attribute. The id at-tribute contains FlexiProvider's internal ID of the mode which can beused to initialize algorithms. The name attribute contains a humanreadable name of the mode which is displayed to the user.

• ParameterSpec: This element contains a class attribute used to identifythe according AlgorithmParameterSpec class.

<PaddingScheme c l a s s="de . f l e x i p r o v i d e r . common . padding .PKCS5Padding" id="PKCS5Padding" name="PKCS#5 Padding" />

Listing 3.11: XML Element for the PKCS #5 Padding Scheme.

32

The PaddingScheme element contains three attributes. The class attributeis used as a unique identi�er. The id and name attributes serve the samepurpose as their counterparts in the Mode element.

33

Chapter 4

Realization of the Integration

After the architecture of the FlexiProvider feature and the FlexiAPI havebeen presented in the previous section, this section focuses on describing theimplementation of the plugins and challenges which arose during the imple-mentation.This chapter is divided into two parts. The �rst part describes the imple-mentation of a new keystore for JCrypTool and the Keystore contributionplugin of the FlexiProvider feature. Part two introduces the plugins of theFlexiProvider feature.

4.1 JCrypTool Keystore

Keys are required in order to properly execute cryptographic algorithms withFlexiAPI.This section introduces the implementation of the actual Keystore plugin andthe FlexiProvider feature's contribution plugin for JCrypTool's new keystore.

4.1.1 org.jcryptool.crypto.keystore

The actual keystore is a �le on the user's local hard drive. In order to pro-vide su�cient protection the JCEKS keystore implementation of the Sun-JCE [28] provider has been selected. This keystore implementation providesa TripleDES [29] encrypted keystore. However, for the sake of usability, theuser will not be required to enter a keystore password every time the keystoreis accessed. The keystore �le is protected with a platform password providedby JCrypTool. By enforcing a strict key protection password policy all sen-sitive keys are protected. All secret and private keys which are stored in thekeystore are protected by a mandatory key protection password, which mustnot be empty. Public keys are not protected with a key protection password,since they are contained in X.509 [19] certi�cates, which can generally bepublished.

34

The independence of JCrypTool's keystore from any cryptographic serviceprovider has been a major requirement for the implementation. However,this implies that the only possible way to manage input and output is viathe JCA. Hence, input and output methods speci�c to instances of FlexiAPIclasses are not possible.Due to the independence from any cryptographic service provider the key-store cannot o�er any key generation services itself. All of this input man-aging has to be accessed via the keyStoreActions extension point. However,export functions can be centrally provided by the keystore, as long as onlyJCA compliant formats are used. This does not hamper the independenceof the keystore. Whenever applicable, industry standards are used for ex-porting entries of the keystore, e.g. X.509 [19] for certi�cates and PKCS#12[30] for key pairs. However, there is no industry standard for secret keys.Therefore, secret keys are exported as serialized objects.With regard to an optimal key management, each key is assigned to a Con-tact. A contact in the scope of the keystore is an entity, which may possessone or more keys. Certi�cates, key pairs and secret keys can be assigned tocontacts. By assigning keys to these contacts, they can be easily identi�ed.For instance, if a user wishes to encrypt a message to another user, all hehas to do is access the key assigned to this user's contact.The contacts and their keys will be presented in a View. With regard tocontacts and their assigned keys, a tree structure has been deemed as thebest solution in order to present the contents of the keystore to the user.The appearance of the tree is controlled by two provider classes, which spec-ify the underlying tree model and the icons which are used. For the treenodes, a custom tree model has been implemented which is based on theITreeNode interface, which is displayed in �gure 4.1. Figure 4.2 shows a

Figure 4.1: UML Class Diagram of the Keystore's ITreeNode.

screenshot of the keystore View with two contacts, called KeyPairTest andSecretKeyTest.More than one keystore can be used in JCrypTool. However, only one

keystore can be active at a time. New keystores can be speci�ed in the pref-

35

Figure 4.2: Screenshot of JCrypTool's Keystore

erence page which has been implemented for JCrypTool keystore. Di�erentkeystores can be selected by clicking on the Choose Keystore button in theView's menu bar. The name of the currently active keystore is displayed tothe left above the tree composite.In order to enable the user to work with keys, e.g. drag a key from the Key-store View and drop it to an algorithm in the FlexiProvider Operations Viewwithout constantly having to enter the mandatory key protection password,all keys are managed on a meta level. This means, that for the most partonly a reference to the actual key is used in JCrypTool. This way, the userwill only be prompted to enter the key protection password when the key isrequired for the execution of a cryptographic operation.The Java keystore API only permits one identi�er to be stored along thekey. This reference, the alias string, is used to uniquely identify entries inthe keystore. However, this alias cannot be directly used to display informa-tion to the user, since it transforms all entered strings into their lower-caserepresentation. All upper case letters entered as part of an alias are auto-matically changed. To remedy this disadvantage all information stored inthe alias string is encoded. All pieces of information which are stored in thealias are converted to American Standard Code for Information Interchange(ASCII) [31]. Afterwards, the resulting ASCII values are transformed tohexadecimal digits. This way, the correct case of the entered letters can berestored by decoding the alias string.

36

With regard to providing su�cient information in the alias multiple informa-tion are combined. Table 4.1 provides an overview of information containedin an alias. This information is internally represented by the KeyStoreAlias

Entry Description

Contact Name The name of the contact this entry willbe stored for.

Key Type The type of the key. Speci�ed by theKeyType enumeration.

Algorithm Name The name of the algorithm this key isassociated with.

Hash Value A unique identi�er used to identifymatching public and private keys.

Class Name The class name of this key's Java class.

Table 4.1: Overview of Entries in a Keystore Alias.

class. This class provides constructors, as well as getter methods to retrievethe required information. This class is used whenever an alias is stored tothe keystore.In order to enable the keystore to o�er services to the user which are speci�cto a particular cryptographic service provider the keyStoreAction extensionpoint (see Chapter 2.2.2) has been implemented in order to enable otherplugins to contribute actions to the keystore. These actions range from gen-erating secret keys and key pairs to importing all supported key types. Forthis extension point, the abstract class AbstractNewKeyStoreEntryActionhas been implemented. All contributed plugins contain classes which extendthis class and specify additional attributes, like a name for the action, whichtype the action shall be used for, or an icon which will be used to graphicallyrepresent the action in the View.All registered extensions are managed by the KeyStoreActionManager class.This class retrieves all required information from the extension point andmakes them available to the Keystore plugin. When the View is initialized,this class is queried for contributed actions, which will subsequently be addedto the keystore and the corresponding view.

4.1.2 org.jcryptool.crypto.�exiprovider.keystore

This plugin is part of the FlexiProvider feature and this section should hencebe part of the following section. However, for the sake of a stringent docu-mentation it is included in this section, because its main point of referenceis the Keystore plugin.This plugin provides an implementation of this extension point with Flexi-Provider speci�c services. It enables the user to generate new secret keys,

37

new key pairs and import all key types supported by the keystore. Due tothe close cooperation between the JCrypTool team and the FlexiProviderteam, this plugin acts as the default provider for generating and importingnew keys to the JCrypTool keystore.

Generation of Secret Keys and Key Pairs

Wizards have been implemented in order to allow the user to generate newsecret keys and key pairs. The wizard for generating new key pairs is identicalto the wizard for generating new secret keys. Both wizards are activated fromtheir respective action classes, which extend the AbstractNewKeyStore-

EntryAction class.The user has the ability to select an existing contact from a combo box, orspecify the name of a new contact in the same combo box which is locatedat the top of the wizard page. Available key types are displayed in anothercombo box and contain all registered names and OIDs which are availablein the algorithms.xml �le.The lower part of the wizard contains the password area. The user has to en-ter the mandatory key protection password twice, in order to prevent typingerrors. The wizards have been implemented, so that they cannot be com-pleted without a password and hence, no unprotected key can be generatedand added to the keystore.

Import of Certi�cates, Secret Keys and Key Pairs

In addition to the generation of new secret keys and key pairs, anotherservice provided by this plugin is the possibility to import certi�cates, secretkeys and key pairs. Certi�cates can be imported in X.509 format and keypairs in PKCS#12 [30] format. There is no speci�c format for storing andtransmitting secret keys. In order to transmit secret keys, serialized Javaobjects will be imported and exported from JCrypTool's keystore.The wizard implemented for the import of these keys is very similar to thekey generation wizards. This wizard is activated from the respective actionclass which extends the AbstractNewKeyStoreEntryAction class, as well.The user has the ability to select or specify a new contact. In the middlepart of the wizard, he can choose a type which will be imported and select a�le from the �le system. In case a secret key or key pair is imported, a keyprotection password for the protection of the entry in JCrypTool's keystorehas to be entered, as well. After the user clicks on the Finish button, theentry is imported. However, if a key pair is to be imported, the user will beprompted for the key protection password which protects the private key ina PKCS#12 [30] container.

38

4.2 FlexiProvider Feature

Each plugin has been designed to provide one speci�c service to the Flexi-Provider feature. These services range from presenting the algorithms to theuser, enabling the user to specify details on the algorithms to executing thealgorithms. This section introduces the implementation of each of these �veplugins, along with the services they are providing.

4.2.1 org.jcryptool.crypto.�exiprovider

The FlexiProvider resources plugin acts as the central repository for allshared resources of the FlexiProvider feature. Among these resources aretwo enumerations, OperationsType and RegistryType.The purpose of the OperationsType enumeration provides a central pointof reference for all cryptographic operations which can be de�ned by theuser and performed by the engine classes. It contains the values ENCRYPT,DECRYPT, SIGN VERIFY and UNKNOWN.The RegistryType enumeration serves an important purpose with regardto using FlexiAPI. For each algorithm type accessible through FlexiAPI'sRegistry class, a corresponding entry is available in this enumeration. Ifnew algorithm types are added to the FlexiProvider library this enumerationhas to be amended, as well. This enumeration permits an easy analyzationand registration of all available algorithms of di�erent types, simply by usinga for...each statement that iterates over the elements of this enumeration.This plugin provides many di�erent services besides these enumerations.Among these services is providing descriptor classes used by other plugins ofthe FlexiProvider feature, re�ection support used for accessing and instan-tiating FlexiProvider classes and, most importantly, the managing of thealgorithms.xml �le, which is kept in one central location in order to establisha central point of reference for all plugins.

Descriptors

The descriptor classes provided by this plugin can be arranged into threedistinct groups, namely algorithms, meta information and re�ection.The �rst group is comprised of descriptor classes which are used to providenecessary information on algorithms which is used to transfer informationfrom one plugin to another via the newOperation and performOperation ex-tension points. Figure 4.3 shows the UML diagram of the main descriptorclass, called AlgorithmDescriptor. This class is su�cient to provide allrequired information to instantiate the majority of algorithm types of theFlexiAPI. As is displayed in �gure 4.3, this class provides getter-methods forthe algorithm name, the registry type and the corresponding and initializedAlgorithmParameterSpec, if such a class is available for the respective al-gorithm.

39

Figure 4.3: UML Class Diagram of AlgorithmDescriptor.

Only two algorithm types cannot be su�ciently described by the Algorithm-Descriptor class, namely block ciphers and secure randoms. For thesetwo algorithm types, sub-classes of AlgorithmDescriptor have been imple-mented. An UML diagram of the BlockCipherDescriptor class is displayedin �gure 4.4. Being a sub-class of AlgorithmDescriptor, this class inherits

Figure 4.4: UML Class Diagram of BlockCipherDescriptor.

all methods and services of its super class. In addition to these methods, itprovides getter methods which return the ID of the mode and the paddingscheme. Additionally, a getter method for the ModeParameterSpec class,which contains the Initialization Vector (IV) is provided. These methodsenable a complete initialization and instantiation of any block cipher.Figure 4.5 displays the UML diagram of the SecureRandomDescriptor class.However, the AlgorithmDescriptor class does not provide one required pa-

Figure 4.5: UML Class Diagram of SecureRandomDescriptor.

rameter. This parameter is the length of the pseudo random number value inbytes. The SecureRandomDescriptor class provides a getter method for thisvalue. Hence, a complete instantiation and initialization of secure randomsis enabled by information contained in this descriptor.

40

XML Managing

The algorithms.xml �le which is bundled with the FlexiProvider library inthe FlexiProvider library plugin, is managed by this plugin. In order to pro-vide a central reference point for the information contained in the XML �le,the AlgorithmsXMLManager class has been implemented as a singleton (See[27], chapter 3.). The algorithms.xml �le is parsed only once, at the �rsttime the singleton is accessed. This is achieved by including the methodcall for the parsing process in the private singleton constructor. As can be

Figure 4.6: UML Class Diagram of AlgorithmsXMLManager.

seen in Figure 4.6, this singleton class provides getter methods for all infor-mation contained in the algorithms.xml �le. These information are parsedfrom the XML �le, which is retrieved from the FlexiProvider library plugin.The algorithms contained in this XML structure are parsed by three di�er-ent methods. These methods analyze algorithms which do not rely on keys,algorithms which require secret keys and algorithms which require key pairs.This grouping allows a lean code structure without loosing any functionality.During this parsing process, the interfaces shown in �gures 3.1 through 3.3are utilized to establish an object structure which can be accessed by thedi�erent plugins of the FlexiProvider feature.

41

Two or more getter methods are available for some algorithm types. When-ever an algorithm has an OID registered, a getter method is available whichuses an IMetaOID as input parameter. This way, an algorithm can be re-trieved by using a name, or an Object Identi�er (OID). An OID is a uniqueidenti�er based on an ASN.1 structure. One representation of OIDs are inte-gers separated by a'.'. Each number represents one node in the ASN.1 tree.Figure 4.7 shows the UML diagram of the MetaOID class, which implementsthe IMetaOID interface. This interface is used throughout the FlexiProviderfeature whenever an OID is required by any of the plugins.

Figure 4.7: UML Class Diagram of MetaOID.

Re�ection

Re�ection is a speci�c service provided by the Java programming languagewhich enables a running Java application to instantiate classes at runtime[32]. JCrypTool has to rely on re�ection in order to fully utilize the Flexi-Provider library. Since information on supporting services is stored in anXML �le, no actual class instances are available to JCrypTool at runtime.The Reflector class, which is displayed in �gure 4.8, has been implementedto provide a central re�ection service. This class provides methods for in-

Figure 4.8: UML Class Diagram of Reflector.

stantiating AlgorithmParameterSpec classes with default and custom pa-

42

rameters. These custom parameters originate from the Algorithms plu-gin, which enables the user to enter custom parameters. The parame-ters are analyzed for their type are used to instantiate the correspondingAlgorithmParameterSpec classes.

User Interface Resources

Additionally, this plugin contains user interface resources. These are the toplevel tree objects, which are used in the FlexiProvider feature whenever a treestructure has to be presented to the user. Figure 4.9 shows the ITreeNode

interface, which forms the basis for all tree structures.It has to be noted, that �gures 4.1 and 4.9 show two di�erent versions of the

Figure 4.9: UML Class Diagram of ITreeNode.

ITreeNode interface. Even though these interfaces are identical, the Key-store plugin cannot utilize the interface introduced in this section, since theKeystore is not part of the FlexiProvider feature. This may seem tedious,but it is necessary with regard to a clean architecture without interdepen-dencies.Another service provided by this plugin is the implementation and regis-tration of the FlexiProvider perspective. This perspective contains all viewswhich are implemented. The org.eclipse.ui.perspective extension point is usedto register this perspective. The initial position and the layout of the per-spective is speci�ed in the FlexiProviderPerspective class.

4.2.2 org.jcryptool.crypto.�exiprovider.algorithms

All algorithms available through the FlexiAPI are presented to the user ina View. To provide the user with an easy to use interface the FlexiProviderAlgorithms View shows a tree in which the algorithms are grouped by algo-rithm types. The tree nodes are based on the ITreeNode interface shown in�gure 4.9.

43

Tree Structure for Algorithms

Algorithms in FlexiProvider are implemented as sub-classes of the engineclasses of the FlexiAPI (See table 3.2.). However, algorithms may be sub-classes of other algorithms, as well. For instance, AES is implemented asan inner sub-class of Rijndael. With regard to this architecture fully quali-�ed class names, which are used as unique identi�ers throughout the Flexi-Provider feature, are used to discern the logical hierarchy of algorithms. Allalgorithm class names are parsed to create a super-class/sub-class hierarchy.However, some algorithm types, e.g. MACs, possess abstract super classeswhich cannot be instantiated. These abstract classes must not be displayedto the user. In order to arrange such algorithms correctly, their fully quali-�ed class names are checked for a common pre�x. This pre�x is used as thename for a folder, which allows the corresponding algorithms to be arrangedcorrectly. A recursive algorithm has been implemented to create the algo-rithm tree structure.Figure 4.10 displays a screenshot, which shows the FlexiProvider Algorithmsview with some algorithms that have been arranged according to the de-scription above. Since the initialization of a new algorithm is a complex

Figure 4.10: Screenshot of the FlexiProvider Algorithms View.

process a sequence diagram is presented in �gure 4.11 in order to providea better understanding of this process. As can be seen in �gure 4.11, theprocess is started when the user clicks on an algorithm in the View. Thistriggers the algorithmCalled() method of the AlgorithmsManager class.

44

User FlexiProviderAlgorithmsView AlgorithmsManager

algorithmCalled()

NewOperationManagerAlgorithmWizard

performAlgorithmCalled()

openWizard()

fireNewOperation()

Click on Algorithm

Enter Parameters

Notify Extensions

Figure 4.11: UML Sequence Diagram: Initializing a new Algorithm.

This class discerns whether the algorithm requires a parameterization. If aparameterization is required, the appropriate AlgorithmWizard is opened.After the algorithm has been successfully parameterized, the NewOperation-Manager class noti�es all extensions of the newOperation extension point,that a new algorithm has been parameterized and hence, a new operation isavailable.

Dynamic User Interfaces

One of the major challenges of this project has been the design and imple-mentation of dynamic user interfaces which are created at runtime, depend-ing on the requirements of the algorithms. Naturally, creating dedicateduser interfaces for every single algorithm is an unfeasible task. Therefore asystem had to be designed and implemented, which creates appropriate userinterfaces for all algorithms.Wizards have been selected as the framework for these dynamic user inter-faces. Wizards provide a customizable frame and o�er additional featureswhich can be extended and utilized for this purpose. In order to minimizeredundancies, a simple wizard class hierarchy has been established. Similarto the descriptors introduced in chapter 4.2.1, a central AlgorithmWizardclass is su�cient to handle the requirements of most algorithm types. How-ever, three algorithm types require a more speci�c handling, namely blockciphers, signatures and secure randoms. Dedicated wizards, which still uti-lize the same dynamic infrastructure as the AlgorithmWizard class, havebeen developed for these three algorithm types.Block ciphers may require more than just algorithm parameters in orderto function correctly. For instance, RC5 and Rijndael require an initial-ized AlgorithmParameterSpec, as well as an initialized ModeParameterSpec.The ModeParameterSpec contains the initialization vector, which is required

45

to initialize a mode like CBC. For secure randoms, the user is required toenter the length of the random value in bytes to initialize a secure random.The objective of highly dynamic user interfaces has been achieved by creatingdedicated input components for all supported parameter types. These com-posites are �lled with information retrieved from the FlexiProvider sourcecode, which is available through the AlgorithmsXMLManager singleton of theFlexiProvider resource plugin. With regard to identifying the required in-formation, the constructors for all sub-classes of AlgorithmParameterSpechave been parsed. The policies for this parsing process have been explainedin chapter 3.2.2. The dynamic interfaces are combined in the InputFactoryclass, which is displayed in �gure 4.12. This class generates instances of the

Figure 4.12: UML Class Diagram of Input Factory.

DynamicComposite class, which extends the org.eclipse.swt.Compositeclass and provides an empty composite that will be �lled with correspond-ing input components. Figure 4.13 displays the UML sequence diagramwhich depicts the process of how dynamic user interfaces are created. As

AlgorithmParameterWizardPage InputFactory

createParameterComposite()

DynamicComposite

Add Input Areas

Return created Composite

User

Enter custom Parameters

Return customized Parameters

Figure 4.13: UML Sequence Diagram for Creating Dynamic User Interfaces.

can be seen in �gure 4.13, the createParameterComposite() method of

46

the InputFactory class is called during the initialization of an instanceof AlgorithmParameterWizardPage and initializes the creation of dynamiccomposites.The required parameters are handed over to the factory class which in turn�lls a composite with instances of the required DynamicComposite class,which is displayed in �gure 4.14. This newly created composite is returnedto the wizard page. The user may enter custom parameters in the dynam-ically created composite, which is now being displayed in the wizard page.

Figure 4.14: UML Class Diagram of DynamicComposite.

4.2.3 org.jcryptool.crypto.�exiprovider.operations

The Operations plugin provides a view which enables the user to select andcustomize di�erent operations which have been parameterized in the Algo-rithms plugin. Since this plugin extends the newOperation extension pointdeclared by the Algorithms plugin, it is noti�ed every time a new operationhas been created. These new operations are then presented to the user in theFlexiProviderOperations View. As can be seen in �gure 4.15, the operationsare displayed in a tree structure. This tree structure utilizes the same treenode infrastructure which is de�ned in the FlexiProvider resources plugin.Customized label and parameter provider classes specify the icons and treemodels which are used to display the operations in the tree.

47

Figure 4.15: Screenshot of the FlexiProvider Operations View.

Each operation entry represents an instance of EntryNode, which is displayedin �gure 4.16. This class extends a sub-class of the ITreeNode interface whichis speci�ed in the FlexiProvider resource plugin. This class acts as the focal

Figure 4.16: UML Class Diagram of EntryNode.

point for all modi�cations to the operation. Depending on the operationdi�erent attributes can be de�ned by the user, e.g. the input and outputlocations. For this, the user usually has the choice to select either an openeditor within JCrypTool, or select a �le on the �le system.Cryptographic keys can also be speci�ed by the user. This is done with the

48

mouse by dragging a key from the keystore and dropping it on the desiredoperation. Similar to the drag support listener class which had to be imple-mented and registered in the Keystore plugin, a drop support listener classhad to be implemented and registered within this plugin. This drop listenerreacts to any objects that complies with the drag and drop behaviour regis-tered with the drop listener. In order to allow a more �exible drop area, akey can be dropped on any node of the operation in question. The correctoperation to which the key will be added is uniquely identi�ed through thetimestamp, which is associated with each EntryNode and has been takenwhen the operation has been added to the Operations plugin.Figure 4.17 shows the entire process, starting with an operation retrieved

NewOperationListener OperationsManager FlexiProviderOperationsView

addOperation()

Display new Operation

User

Configure Operation

Click on Execute Button

ExecuteOperationAction

run()

PerformOperationManager

firePerformOperation()

Notify Extensions

Figure 4.17: UML Sequence Diagram for Performing an Operation.

from the newOperation extension point to the NewOperationListener class.This class noti�es the OperationsManager class that a new operation hasbeen added. A new instance of EntryNode is �lled with all information aboutthe new operation and is added to the UI tree structure which is displayedto the user.Afterwards, the user is able to enter all required parameters which are re-quired for the execution of the operation. When all these information aresupplied correctly, the user can execute the operation by clicking on the Ex-ecute button in the top right corner of the View. This click will activatethe run() method of the ExecuteOperationAction which in turn noti�esthe class PerformOperationManager that an operation shall be performed.This class manages the performOperation extension point and noti�es allregistered extensions.In order to persistently store the operations displayed in the View, an XML�le is created every time JCrypTool is shut down. This XML �le is parsedwhen the Operations plugin is initialized and the information contained inthis XML �le are available for future use. Similar to the way in which the

49

algorithms.xml �le is parsed, the contents of the EntryNode class have spe-ci�c counterpart classes which establish an XML representation of the entry.Listing 4.1 shows an example of this XML �le.

<?xml version=" 1 .0 " encoding="UTF−8" ?><Operat ionsViewEntr ies version=" 0 . 2 . 0 ">

<Entry name=" ( Ri jndae l ) no name / Created on: Thu May 29 15 : 1 7 : 2 5 CEST 2008" timestamp="1212067045531">

<BlockCipherDescr iptor name="Ri jndae l "type="BLOCK_CIPHER" mode="CBC"padding="PKCS5Padding">

<AlgorithmParameterSpec c l a s s="de . f l e x i p r o v i d e r . core .r i j n d a e l .Ri jndaelParameterSpec "a lgor i thm="Ri jndae l ">MAYCAgCABQA=</AlgorithmParameterSpec>

<ModeParameterSpec>BBCfxVsF9ZQxksSPfqzF3Aub</ModeParameterSpec>

</BlockCipherDescr iptor><InputOutput input="<none>" output="<

none>" /><Operation type="Unknown" />

</Entry></Operat ionsViewEntr ies>

Listing 4.1: Example of a Persistently Stored Entry in the Operations View.

Additionally, the user may export or import operations. This can be doneby clicking on the Import and Export buttons in the top right corner of theView. The exported entries utilize the same XML classes which are used topersistently store the operations. This way, they can be easily imported andexported and can be exchanged between di�erent instances of JCrypTool,e.g. from one system to another. However, not all attributes of an operationare exported. The key as well as the input and output destination and theselected mode of operation are not exported, since they are speci�c to oneinstance of JCrypTool. Listing 4.2 displays an example of such an exportedXML entry, which corresponds to the entry in listing 4.1.

<?xml version=" 1 .0 " encoding="UTF−8" ?><ExportedEntry version=" 0 . 2 . 0 " name=" ( Ri jndae l ) no name

/ Created on: Thu May 29 15 : 1 7 : 2 5 CEST 2008"timestamp="1212067045531">

50

<BlockCipherDescr iptor name="Ri jndae l " type="BLOCK_CIPHER" mode="CBC" padding="PKCS5Padding">

<AlgorithmParameterSpec c l a s s="de . f l e x i p r o v i d e r . core .r i j n d a e l .Ri jndaelParameterSpec "a lgor i thm="Ri jndae l ">MAYCAgCABQA=</AlgorithmParameterSpec>

<ModeParameterSpec>BBCfxVsF9ZQxksSPfqzF3Aub</ModeParameterSpec>

</BlockCipherDescr iptor></ExportedEntry>

Listing 4.2: Example of an Exported Entry of the Operations View.

As can be seen in listing 4.2, only the BlockCipherDescriptor entry, alongwith the name and the timestamp, have been exported. All other entrieshave been omitted for the reasons stated above.

4.2.4 org.jcryptool.crypto.�exiprovider.engines

The Engines plugin contains engine classes for all supported algorithm types.This plugin extends the performOperation extension point, which is declaredby the Operations plugin. This extension point requires the implementationof the IPerformOperationListener interface, which is implemented by thePerformOperationListener class. This class acts as a listener, which istriggered whenever an operation is executed. Within the only method ofthis class, a switch...case statement is used to activate the correspondingengine class.All engines classes extend the abstract super class FlexiProviderEngine,which provides services required by all engine classes, e.g. the opening ofinput and output streams which allow handling �les of arbitrary size. Addi-tionally, this abstract class contains a small bit of user interaction. Since theengines are performing cryptographic operations, this is also the �rst timewhen the actual keys from the keystore have to be accessed.Figure 4.18 displays the UML class diagram of the FlexiProviderEngine

class. The engine classes have to implement the abstract methods init()

and perform(). The former method is used to initialize the FlexiAPI classesof the algorithm types, e.g. BlockCipher or Signature.The second method contains the initialization of the input and output ser-vices and methods which perform the actual cryptographic operations. SinceFlexiAPI does not provide any support for streams, this functionality has to

51

Figure 4.18: UML Class Diagram of FlexiProviderEngine.

be provided by this method. In order to operate on �les of arbitrary size,performing cryptographic operations cannot simply operate on the entire in-put destination at the same time. The input is read piece by piece fromthe input stream and the cryptographic operations are performed on thesepieces, e.g. blocks of a length which is speci�ed by the algorithm. Theseblocks are then written to the output stream.After the cryptographic operations have �nished, the streams are closed inorder to facilitate a clean ending of the stream operations. In case the outputdestination is an editor, the output will open the registered editor for thespeci�c output type, for cryptographic output this refers to JCrypTool's HexEditor.

52

Chapter 5

Conclusion

This work concludes with a summary of the central point and an outlook onfuture developments.

5.1 Summary

This work has presented the integration of the FlexiProvider cryptographiclibrary in the JCrypTool e-learning platform.Both projects have been introduced, along with the motivation for the inte-gration of the FlexiProvider library into JCrypTool. Both projects are ableto gain synergy e�ects and bene�ts from the cooperation. JCrypTool onthe one hand gains modern and state-of-the-art cryptographic algorithms.On the other hand, the FlexiProvider project gains more attention by itsintegration into JCrypTool. Additionally, JCrypTool acts as a cutting-edgeproject for the new FlexiAPI.Since this project has been centred around software architecture as well ason implementing this architecture, this work focused on the software archi-tecture. The decisions for speci�c architectural choices have been presented.In order to integrate the FlexiProvider library in JCrypTool, an intermediatelayer has been introduced in the form of an XML �le. This �le contains allinformation retrieved from FlexiProvider through FlexiAPI. Additionally, itcontains information not available through FlexiAPI. This XML �le servesas JCrypTool's central point of information with regard to accessing Flexi-Provider Additionally, the functionality achieved by using of FlexiAPI hasbeen explained.After the software architecture and the intermediate XML layer have beenpresented, this work introduced details on the implementation part of thisproject. Based on the software architecture, the di�erent implementationsteps have been presented and detailed information on challenges has beenprovided.

53

5.2 Outlook

This project has laid the foundation for a hopefully long and bene�cial part-nership between the JCrypTool and FlexiProvider projects. Future devel-opers are able to resort to a clearly structured feature which can be furtherextended by additional plugins and features. The entire scope of future de-velopments cannot be foreseen. Many additional features can be imaginedand only time will tell how strongly this powerful feature for JCrypTool willbe further improved.Among the features which can be envisioned is a further information re-trieval from the FlexiProvider source code. For instance, the FlexiProviderAlgorithms View may be extended by including tool tips for all algorithmswhich provide background information on the algorithms. Alternatively, thisinformation might be included in the online help of the JCrypTool applica-tion in order to strengthen the e-learning aspect of the FlexiProvider feature.

54

Appendix A

About the Project

Section A.1 presents an overview of the packages containing the source codesof the plugins. Section A.2 introduces the necessary con�guration to includethe FlexiProvider feature in JCrypTool. Finally, in section A.3 the toolsused for and during the implementation are introduced.

A.1 Overview of Plugin Structures

In order to provide an overview of the inner structure of the plugins com-prising the FlexiProvider feature, their package structures are displayed inthis section.

A.1.1 FlexiProvider Resource Plugin

org.jcryptool.crypto.flexiprovider

descriptors........Descriptor classes for the FlexiProvider featurealgorithms Descriptor classes which are used by extension pointsmeta.................................Descriptors for algorithms

interfaces ....................Declaring top-level interfacesreflect....Descriptors for entries retrieved from the source code

interfaces ....................Declaring top-level interfacesexception.................Exceptions for the FlexiProvider featurereflect.....................Utilities for using re�ection at runtimetypes....Convenience enumerations for registry and operation typesui............................Supporting classes for user interfaces

nodes....Top-level de�nition of node classes for the use in Viewsperspective.....................The FlexiProvider perspective

xml............................Managing of the algorithms.xml �le

55

A.1.2 Algorithms Plugin

org.jcryptool.crypto.flexiprovider.algorithms

listeners........Management of the newOperation extension pointui............................User interface and supporting classes

dynamic .....................Dynamic user interface compositescomposites..........Composites for speci�c parameter types

views...................The actual View and supporting classesnodes.........................Node classes used in the Viewproviders..........Label and content providers for the View

wizards...Wizards and wizard pages for instantiating algorithmsblockcipher.....Custom wizards and wizard pages for blockciphers

securerandom ...Custom wizards and wizard pages for securerandoms

signature...Custom wizards and wizard pages for signatures

A.1.3 Operations Plugin

org.jcryptool.crypto.flexiprovider.operations

engines......Management of the performOperation extension pointui............................User interface and supporting classes

actions...........................Actions for the user interfacecontext.................Actions for the View's context menu

io ............Actions which change the input and outputops ..........Actions which change the mode of operation

menu......Actions which will be displayed in the View's menulisteners...................................Listener interfacesviews...................The actual View and supporting classes

nodes.........................Node classes used in the Viewalgorithms.............Node classes regarding algorithmsio......................Node classes for input and outputkeys................................Node classes for keysops................Node classes for the mode of operation

providers..........Label and content providers for the Viewxml...................................Management of XML entries

algorithms.......................XML elements for algorithmsparamspec XML element for AlgorithmParameterSpec entries

io..........................XML elements for input and outputkeys....................................XML elements for keysops....................XML elements for the mode of operation

56

A.1.4 Engines Plugin

org.jcryptool.crypto.flexiprovider.engines

cipher ...............................Engine classes for all cipherslistener.. Implementation of the performOperation extension pointmac...........................................Engine class for Macmessagedigest....................Engine class for MessageDigestsecurerandom.......................Engine class for SecureRandomsignature .............................Engine class for Signature

A.1.5 Keystore Contribution Plugin

org.jcryptool.crypto.flexiprovider.keystore

actions............Contributed actions for the JCrypTool keystorewizards...Contributed wizards and wizard pages for the JCrypToolkeystore

A.1.6 Keystore Plugin

org.jcryptool.crypto.keystore

backend.................The actual keystore and supporting classesdescriptors....................................Descriptor classes

interfaces..................Interfaces for the descriptor classesexceptions...................................Keystore exceptionsui............................User interface and supporting classes

actions.......Abstract and speci�c actions used in the keystoredel...........................................Delete actionsex............................................Export action

preferences..............................The preferences pageviews...................The actual View and supporting classes

interfaces...............................Listener interfacesnodes.........................Node classes used in the View

containers.....Node classes for key group containers, e.g.secret keys

keys..........................Node classes for key entriesproviders..........Label and content providers for the View

wizards.............All wizards and wizard pages of this plugin

A.2 Con�guration

It is possible to launch JCrypTool with the FlexiProvider feature by clickingon the Launch an Eclipse application link on theOverview tab of JCrypTool'sproduct con�guration, as can be seen in �gure A.1. During the developmentof the FlexiProvider feature, two particular con�gurations had to be per-

57

Figure A.1: The JCrypTool Product.

formed. First, since the FlexiProvider feature has not yet been an o�cialpart of a JCrypTool core release during development, the FlexiProvider fea-ture had to be manually added to JCrypTool's product con�guration. Thisis shown in �gure A.2, with a highlighted entry for the FlexiProvider feature.

Figure A.2: The JCrypTool Product Con�guration.

Even though the FlexiProvider feature has been developed against the coreof JCrypTool, i.e. no plugins from the JCrypTool Plugins project have beenrequired in the development workspace, the product con�guration in A.2features all currently existing features of JCrypTool. Empty features areignored by the product con�guration.

58

FlexiProvider has been constantly developed to match the requirements ofJCrypTool. Since building a new release of the FlexiProvider library .jar �lefor every minor change has been unfeasible an alternative had to be found.This alternative has been to include the current source code of FlexiProviderin the FlexiProvider Library plugin. The FlexiProvider source code has beenregularly updated with SVN, a version control system.

A.3 Used Tools and Libraries

Many di�erent tools have been used to implement and document this project:

• Version 1.5 of the Java programming language has been used for thisproject. This has been dictated by the fact that JCrypTool and Eclipserely on this release of the Java 2 Platform [6].

• Eclipse has been a natural, and mandatory, choice for the developmentof the FlexiProvider feature. Since JCrypTool is based on Eclipse 3.3,this is the version of the Eclipse Plugin Development Environment(PDE) [33] which has been used to implement the FlexiProvider fea-ture. The actual implementation has been performed on computersrunning the Microsoft Windows XP and Debian GNU/Linux operat-ing systems.

• Subversive [34], an SVN plugin for Eclipse, has been used to realizea version control of the source code during the development phase.The source code itself has been stored on an SVN server providedby the Chair for Cryptography and Computer Algebra at TechnischeUniversität Darmstadt.

• Icons from the Nuvola [35] icon set have been integrated in the Flexi-Provider feature. This icon set has been published under an opensource license and can be freely used.

• Omondo [36] has been used to generate UML diagrams of Java classesof the FlexiProvider feature.

• Additional UML diagrams have been created withMicrosoft Visio 2007[37].

• Diagrams of the software architecture and the JCrypTool core andFlexiProvider features have been created with yEd [38], e.g. �gure 2.7.

• The JDOM [39] Java library for XML support has been included inthe JCrypTool core for the requirements of the FlexiProvider feature.

• QDox [40] has been used to extract information from the FlexiProvidersource code.

59

Appendix B

AdminTool

This appendix introduces the AdminTool, which is used to manually addinformation to the algorithms.xml �le which is not available through theFlexiAPI. Even though the implementation of this tool has not been partof this project, certain parts of the tool had to be implemented in order tocreate an initial algorithms.xml �le. In order to enable developers of theAdminTool to use and extend the existing source code, the requirements areexplained in this appending. The existing elements of the AdminTool arelocated in the de.�exiprovider.admintool plugin.

B.1 Information Retrieval from FlexiProvider

The majority of the algorithms.xml �le is automatically retrieved from theFlexiProvider library. This is performed in the AlgorithmsRegistry class.This class registers all four sub-providers of FlexiProvider with FlexiAPI'sRegistry class. See chapter 3 for an in-depth look at how the FlexiProviderlibrary is accessed.Afterwards, all supported algorithm types are initialized. This initializationretrieves all available information on names, OIDs and classes from Flexi-API. This information is used to initialize descriptor classes, which havebeen introduced in chapter 3.2.1. For every algorithm a dedicated descriptorclass is initialized and serves as a container for all automatically retrievableinformation from the FlexiProvider library.After all information related to names and designations have been retrievedand added to the descriptor classes, this information is used to collect furtherinformation from FlexiAPI. If available, all standard parameters associatedwith the algorithms are identi�ed and added to the respective descriptorclasses. The same is accomplished for AlgorithmParameterSpec classes, pa-rameter generators and key generators.An XML document is created based on the information contained in the de-scriptor classes. This task is performed by the AdminTool class which utilizes

60

a static factory class called AlgorithmsXMLHelper. This helper class pro-vides factory methods which translate the contents of the descriptor classesinto corresponding XML elements. The policy set forth in chapter 3.2.2 isstrictly followed during the creation of the XML document.The same principle which has been implemented for the translation fromXML elements to descriptor classes in the FlexiProvider Resource plugin,which has been presented in chapter4.2.1, is used here.

B.2 Existing Package Structure

This section provides an overview of the plugins package structure and pro-vides some information on the functionalities located in each package.

de.flexiprovider.admintool

ui.........................................AdminTool perspectiveutil.........................Utility class for accessing source codevisible..............Exposed to other plugins during developmentxml .............................Collection of XML element classes

algorithms.................XML element classes for algorithmsmisc...Misc. XML elements, e.g for modes and padding schemesreflection..XML elements for entries retrieved from the sourcecode

B.3 Future Work

The most important task is the development of a Graphic User Interface(GUI) for the AdminTool. This GUI should enable the user to easily iden-tify missing pieces of information. Every algorithm should be displayed inthis view, along with information on what pieces of information are missing.Depending on the algorithm type, di�erent pieces of information can bemissing or has to be adjusted. For instance, FlexiAPI does not provide in-formation on the supported block lengths of block ciphers. The AdminToolneeds to feature a functionality which enables the user to add this infor-mation to the algorithms. Since many block ciphers share the same blocklengths, selecting multiple block ciphers and assigning the necessary blocklengths once saves a lot of time. The same is true for key generators and therespective key lengths.This process will be required once for the entire library, namely the �rst timethe algorithms.xml �le is created. Afterwards, only algorithms which havebeen added in a new release of FlexiProvider will have to be completed bythe user of the AdminTool. In order to achieve this objective, the AdminToolrequires an option which enables it to perform a comparison between tworeleases of FlexiProvider, identify the new elements and present these resultsto the user.

61

The GUI could be implemented as a rich client application or as a featurefor JCrypTool itself. This way, the same architectural patterns described inthis work can be utilized. For instance, the algorithms could be displayed ina View similar to the FlexiProvider Algorithms View. Another View couldbe used to display information about missing information to the user. Thiscould be used by utilizing out-of-the-box Eclipse features like the ProblemsView, which among other things displays warnings and errors to the userin the Eclipse IDE. Another View could contain information on unassignedpieces of information in the FlexiProvider library or contain various optionswhich can be used to perform the admin tasks.By including drag and drop support in the AdminTool information could eas-ily be copied or pasted from one algorithm to another. Similarly, unassignedinformation could easily be dragged to the View containing the algorithms.

62

Bibliography

[1] Deutsche Bank / Contributors. The CrypTool Project. http://www.

cryptool.org.

[2] Bernhard Esslinger and CrypTool Team. Cryptology withCrypTool. Available at: http://www.cryptool.org/download/

CrypToolPresentation_1_4_10_en.pdf.

[3] JCrypTool Team. The JCrypTool Project. https://sourceforge.net/projects/jcryptool.

[4] Eclipse Foundation. Eclipse Rich Client Platform. http://wiki.

eclipse.org/index.php/Rich_Client_Platform.

[5] The FlexiProvider Group. The FlexiProvider Project. http://www.

flexiprovider.de.

[6] SUN Microsystems. Java 2 Platform. http://java.sun.com/javase/

index.jsp.

[7] National Institute of Standards and Technology (NIST). Announc-ing the Advanced Encryption Standard (AES). Available at: http://

csrc.nist.gov/publications/fips/fips197/fips-197.pdf, Novem-ber 2001.

[8] RSA Laboratories. PKCS #1: RSA Cryptography Standard (version2.1). Available at: http://rsa.com/rsalabs/node.asp?id=2125, June2002.

[9] D. Johnson and A. Menezes. The Elliptic Curve Digital Signature Algo-rithm (ecdsa). http://citeseer.ist.psu.edu/johnson99elliptic.

html, 1999.

[10] SUN Microsystems. Java Cryptography Architecture - JCAReference Guide. Available at http://java.sun.com/javase/

6/docs/technotes/guides/security/crypto/CryptoSpec.html, De-cember 2006.

63

[11] Andreas Roth. Flexible - Eine erweiterbare GUI für den FlexiProvider(Backend). Technische Universität Darmstadt, 2007.

[12] Marco Ghiglieri. Flexible - Eine erweiterbare GUI für den FlexiProvider(Frontend). Technische Universität Darmstadt, 2007.

[13] Je� McA�er and Jean-Michel Lemieux. Eclipse Rich Client Platform.Addison Wesley, 2006.

[14] Eclipse Foundation. SWT: The Standard Widget Toolkit. http://www.eclipse.org/swt.

[15] Eclipse Foundation. JFace. http://wiki.eclipse.org/index.php/

JFace.

[16] Fraunhofer Institute for Computer Graphics Research IGD. CoDecASN.1 En-/Decoder Library. https://sourceforge.net/projects/

codec.

[17] ITU-T Recommendation X.680. Information Technology - AbstractSyntax Notation One (ASN.1): Speci�cation of basic notation. ISO/IEC8824-1, 2002.

[18] JCrypTool Team. The JCrypTool Project - Plugin Project. https:

//sourceforge.net/projects/jctplugins.

[19] ITU-T Recommendation X.509. Information Technology - Open Sys-tems Interconnection - The Directory: Authentication Framework.ISO/IEC 9594-8, 1997.

[20] Institute of Electrical and Electronics Engineers (IEEE). IEEE Stan-dard Speci�cations for Public-Key Cryptography. Available at: http:

//grouper.ieee.org/groups/1363/P1363, January 2000. Amended byIEEE 1363 Amendment 1: Additional Techniques, 2004.

[21] Alfred J. Menezes, Paul C. van Oorschot, and Scott. A. Vanstone.Handbook of Applied Cryptography. CRC Press, Available at: http:

//www.cacr.math.uwaterloo.ca/hac/index.html, 1996.

[22] RSA Laboratories. PKCS #5: Password-Based Cryptography Standard(version 2.0). Available at: http://rsa.com/rsalabs/node.asp?id=

2127, March 1999.

[23] National Institute of Standards and Technology (NIST). The Keyed-Hash Message Authentication Code (HMAC). Avaiable at: http://

csrc.nist.gov/publications/fips/fips198/fips-198a.pdf, March2002.

64

[24] National Institute of Standards and Technology (NIST). Secure HashStandard. Available at: http://csrc.nist.gov/publications/fips/fips180-2/fips180-2-withchangenotice.pdf, August 2002.

[25] B. Kaliski. A Pseudorandom Bit Generator based on Elliptic Loga-rithms. In Advances in Cryptology - CRYPTO'86, volume 263 of LNCS,pages 83�103. Springer, 1987.

[26] National Institute of Standards and Technology (NIST). Digi-tal Signature Standard (DSS). Available at: http://csrc.nist.

gov/publications/fips/fips186-2/fips186-2-change1.pdf, Jan-uary 2000.

[27] Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlis-sides. Design Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley Professional, 1994.

[28] SUN Microsystems. Java Cryptography Architecture - Sum ProvidersDocumentation. Available at http://java.sun.com/javase/6/docs/

technotes/guides/security/SunProviders.html, December 2006.

[29] Ralph C. Merkle and Martin E. Hellman. On the security of multipleencryption. Communications of the ACM, 24(7):465�467, 1981.

[30] RSA Laboratories. PKCS #12: Personal Information Exchange SyntaxStandard (version 1.0). Available at: http://rsa.com/rsalabs/node.asp?id=2138, June 1999.

[31] American National Standards Institue et al. American Standard Codefor Information Interchange, 1977.

[32] Glen McCluskey. Using Java Re�ection. Available at: http://java.

sun.com/developer/technicalArticles/ALT/Reflection/, 1998.

[33] Eclipse Foundation. Eclipse Plug-in Development Environment. http://wiki.eclipse.org/pde/.

[34] CollabNet. Subversion. http://subversion.tigris.org.

[35] Icon King. Nuvola. http://icon-king.com/?p=15.

[36] Omondo. Omondo. http://www.omondo.de.

[37] Microsoft Corporation. Microsoft Visio. http://office.microsoft.

com/visio.

[38] yWorks. yEd - Java Graph Editor. http://www.yworks.com/en/

products_yed_about.html.

65

[39] The JDOM Project. JDOM. http://www.jdom.org.

[40] The QDox Project. QDox. http://qdox.codehaus.org.

66