The EVP Interface

The EVP Interface

In order to make programming with cryptographic functions easier, OpenSSL employs a high-level API called EVP. EVP enables the application programmer to ignore algorithm specific details and write high-level code that works even if the underlying algorithm changes. For example, an application programmer writes a program to encrypt data by using CAST with a 256-bit key. Due to export restrictions, however, he or she must employ DBS with a 64-bit key. EVP enables this process to happen seamlessly with little, if any, retooling. EVP achieves this task by operating as a dispatch layer for function invocations. When a cryptographic operation begins, the application programmer normally passes two structures to the function call:

• 
  

  
  An EVP context. The context is an operation-specific data structure that externalizes and maintains state between function calls. For instance, a cipher context contains the initialization vector for a given algorithm.

  
  


• 
  

  
  An algorithm specifier. This structure encapsulates the algorithm that the EVP function will use. This structure provides basic information (such as block size and key length) and a set of function pointers to the actual cryptographic functions to be invoked.

  
  

As you can see, each individual EVP call is effectively stateless. State is externalized into the context, which has two key advantages:

• 
  

  Thread safety, which OpenSSL does not intrinsically support, is easier to build in because EVP does not contend over many shared resources.

  
  


• 
  

  The application programmer might change the algorithm (from CAST to DES in the earlier example) by changing the cipher specifier passed to thecryptographic function.

  
  

You generally employ EVP by using a three-step process:

1. 
   

   
   Initialization: Functions named EVP_.*_lnit[_ex] indicate to OpenSSL that a cryptographic operation is about to start. They enable the application programmer to specify a context, algorithm, and other initialization parameters.

   
   


2. 
   

   Updating: Functions named EVP_.*_Update provide data to an algorithm, often in an iterative process.

   
   


3. 
   

   Finalization: Functions named EVP_.*_Final_ [ex] finish a particular operation and release any transient resources associated with the context.

   
   

This pattern enables the application programmer to read input data in chunks, performing operations over large data sets without having to have all the data in memory at any one time.

Engines

An OpenSSL engine is an implementation of a particular set of algorithms that —depending on the architecture and available hardware—can be either completely software based or consist of a driver code for dedicated cryptographic hardware. The engine interface was written to enable OpenSSL to take full advantage of special-purpose cryptographic hardware. Using the EVP interface, an applications programmer can either specify an engine on a case-by-case basis as an argument to the initialization function or enable OpenSSL to use a default engine for the appropriate operation.