TABLE OF CONTENTS Traditional security toolkits have been implemented using a "collection of functions" design in which each encryption capability is wrapped up in its own set of functions. For example there might be a "load a DES key" function, an "encrypt with DES in CBC mode" function, a "decrypt with DES in CFB mode" function, and so on [1] [2]. More sophisticated toolkits hide the plethora of algorithm-specific functions under a single set of umbrella interface functions with often complex algorithm-selection criteria, in some cases requiring the setting of up to a dozen parameters to select the mode of operation [3] [4] [5] [6]. Either approach requires that developers tightly couple the application to the underlying encryption implementation, requiring a high degree of cryptographic awareness from developers and forcing each new algorithm and application to be treated as a distinct development. In addition, there is the danger in fact almost a certainty due to the tricky nature of cryptographic applications and the subtle problems arising from them that the implementation will be misused by developers who aren't cryptography experts, when it could be argued that it is the task of the toolkit to protect developers from making these mistakes [7].
Alternative approaches concentrate on providing functionality for a particular type of service such as authentication, integrity, or confidentiality. Some examples of this type of design are the GSS-API [8] [9] [10], which is session-oriented and is used to control session-style communications with other entities (an example implementation consists...
