|  | Kernel Crypto API Interface Specification | 
|  | ========================================= | 
|  |  | 
|  | Introduction | 
|  | ------------ | 
|  |  | 
|  | The kernel crypto API offers a rich set of cryptographic ciphers as well | 
|  | as other data transformation mechanisms and methods to invoke these. | 
|  | This document contains a description of the API and provides example | 
|  | code. | 
|  |  | 
|  | To understand and properly use the kernel crypto API a brief explanation | 
|  | of its structure is given. Based on the architecture, the API can be | 
|  | separated into different components. Following the architecture | 
|  | specification, hints to developers of ciphers are provided. Pointers to | 
|  | the API function call documentation are given at the end. | 
|  |  | 
|  | The kernel crypto API refers to all algorithms as "transformations". | 
|  | Therefore, a cipher handle variable usually has the name "tfm". Besides | 
|  | cryptographic operations, the kernel crypto API also knows compression | 
|  | transformations and handles them the same way as ciphers. | 
|  |  | 
|  | The kernel crypto API serves the following entity types: | 
|  |  | 
|  | -  consumers requesting cryptographic services | 
|  |  | 
|  | -  data transformation implementations (typically ciphers) that can be | 
|  | called by consumers using the kernel crypto API | 
|  |  | 
|  | This specification is intended for consumers of the kernel crypto API as | 
|  | well as for developers implementing ciphers. This API specification, | 
|  | however, does not discuss all API calls available to data transformation | 
|  | implementations (i.e. implementations of ciphers and other | 
|  | transformations (such as CRC or even compression algorithms) that can | 
|  | register with the kernel crypto API). | 
|  |  | 
|  | Note: The terms "transformation" and cipher algorithm are used | 
|  | interchangeably. | 
|  |  | 
|  | Terminology | 
|  | ----------- | 
|  |  | 
|  | The transformation implementation is an actual code or interface to | 
|  | hardware which implements a certain transformation with precisely | 
|  | defined behavior. | 
|  |  | 
|  | The transformation object (TFM) is an instance of a transformation | 
|  | implementation. There can be multiple transformation objects associated | 
|  | with a single transformation implementation. Each of those | 
|  | transformation objects is held by a crypto API consumer or another | 
|  | transformation. Transformation object is allocated when a crypto API | 
|  | consumer requests a transformation implementation. The consumer is then | 
|  | provided with a structure, which contains a transformation object (TFM). | 
|  |  | 
|  | The structure that contains transformation objects may also be referred | 
|  | to as a "cipher handle". Such a cipher handle is always subject to the | 
|  | following phases that are reflected in the API calls applicable to such | 
|  | a cipher handle: | 
|  |  | 
|  | 1. Initialization of a cipher handle. | 
|  |  | 
|  | 2. Execution of all intended cipher operations applicable for the handle | 
|  | where the cipher handle must be furnished to every API call. | 
|  |  | 
|  | 3. Destruction of a cipher handle. | 
|  |  | 
|  | When using the initialization API calls, a cipher handle is created and | 
|  | returned to the consumer. Therefore, please refer to all initialization | 
|  | API calls that refer to the data structure type a consumer is expected | 
|  | to receive and subsequently to use. The initialization API calls have | 
|  | all the same naming conventions of crypto_alloc\*. | 
|  |  | 
|  | The transformation context is private data associated with the | 
|  | transformation object. |