<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> <book id="KernelCryptoAPI"> <bookinfo> <title>Linux Kernel Crypto API</title> <authorgroup> <author> <firstname>Stephan</firstname> <surname>Mueller</surname> <affiliation> <address> <email>smueller@chronox.de</email> </address> </affiliation> </author> <author> <firstname>Marek</firstname> <surname>Vasut</surname> <affiliation> <address> <email>marek@denx.de</email> </address> </affiliation> </author> </authorgroup> <copyright> <year>2014</year> <holder>Stephan Mueller</holder> </copyright> <legalnotice> <para> This documentation is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. </para> <para> This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. </para> <para> You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA </para> <para> For more details see the file COPYING in the source distribution of Linux. </para> </legalnotice> </bookinfo> <toc></toc> <chapter id="Intro"> <title>Kernel Crypto API Interface Specification</title> <sect1><title>Introduction</title> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> The kernel crypto API serves the following entity types: <itemizedlist> <listitem> <para>consumers requesting cryptographic services</para> </listitem> <listitem> <para>data transformation implementations (typically ciphers) that can be called by consumers using the kernel crypto API</para> </listitem> </itemizedlist> </para> <para> 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). </para> <para> Note: The terms "transformation" and cipher algorithm are used interchangably. </para> </sect1> <sect1><title>Terminology</title> <para> The transformation implementation is an actual code or interface to hardware which implements a certain transformation with precisely defined behavior. </para> <para> 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). </para> <para> 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: </para> <orderedlist> <listitem> <para>Initialization of a cipher handle.</para> </listitem> <listitem> <para>Execution of all intended cipher operations applicable for the handle where the cipher handle must be furnished to every API call.</para> </listitem> <listitem> <para>Destruction of a cipher handle.</para> </listitem> </orderedlist> <para> 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_*. </para> <para> The transformation context is private data associated with the transformation object. </para> </sect1> </chapter> <chapter id="Architecture"><title>Kernel Crypto API Architecture</title> <sect1><title>Cipher algorithm types</title> <para> The kernel crypto API provides different API calls for the following cipher types: <itemizedlist> <listitem><para>Symmetric ciphers</para></listitem> <listitem><para>AEAD ciphers</para></listitem> <listitem><para>Message digest, including keyed message digest</para></listitem> <listitem><para>Random number generation</para></listitem> <listitem><para>User space interface</para></listitem> </itemizedlist> </para> </sect1> <sect1><title>Ciphers And Templates</title> <para> The kernel crypto API provides implementations of single block ciphers and message digests. In addition, the kernel crypto API provides numerous "templates" that can be used in conjunction with the single block ciphers and message digests. Templates include all types of block chaining mode, the HMAC mechanism, etc. </para> <para> Single block ciphers and message digests can either be directly used by a caller or invoked together with a template to form multi-block ciphers or keyed message digests. </para> <para> A single block cipher may even be called with multiple templates. However, templates cannot be used without a single cipher. </para> <para> See /proc/crypto and search for "name". For example: <itemizedlist> <listitem><para>aes</para></listitem> <listitem><para>ecb(aes)</para></listitem> <listitem><para>cmac(aes)</para></listitem> <listitem><para>ccm(aes)</para></listitem> <listitem><para>rfc4106(gcm(aes))</para></listitem> <listitem><para>sha1</para></listitem> <listitem><para>hmac(sha1)</para></listitem> <listitem><para>authenc(hmac(sha1),cbc(aes))</para></listitem> </itemizedlist> </para> <para> In these examples, "aes" and "sha1" are the ciphers and all others are the templates. </para> </sect1> <sect1><title>Synchronous And Asynchronous Operation</title> <para> The kernel crypto API provides synchronous and asynchronous API operations. </para> <para> When using the synchronous API operation, the caller invokes a cipher operation which is performed synchronously by the kernel crypto API. That means, the caller waits until the cipher operation completes. Therefore, the kernel crypto API calls work like regular function calls. For synchronous operation, the set of API calls is small and conceptually similar to any other crypto library. </para> <para> Asynchronous operation is provided by the kernel crypto API which implies that the invocation of a cipher operation will complete almost instantly. That invocation triggers the cipher operation but it does not signal its completion. Before invoking a cipher operation, the caller must provide a callback function the kernel crypto API can invoke to signal the completion of the cipher operation. Furthermore, the caller must ensure it can handle such asynchronous events by applying appropriate locking around its data. The kernel crypto API does not perform any special serialization operation to protect the caller's data integrity. </para> </sect1> <sect1><title>Crypto API Cipher References And Priority</title> <para> A cipher is referenced by the caller with a string. That string has the following semantics: <programlisting> template(single block cipher) </programlisting> where "template" and "single block cipher" is the aforementioned template and single block cipher, respectively. If applicable, additional templates may enclose other templates, such as <programlisting> template1(template2(single block cipher))) </programlisting> </para> <para> The kernel crypto API may provide multiple implementations of a template or a single block cipher. For example, AES on newer Intel hardware has the following implementations: AES-NI, assembler implementation, or straight C. Now, when using the string "aes" with the kernel crypto API, which cipher implementation is used? The answer to that question is the priority number assigned to each cipher implementation by the kernel crypto API. When a caller uses the string to refer to a cipher during initialization of a cipher handle, the kernel crypto API looks up all implementations providing an implementation with that name and selects the implementation with the highest priority. </para> <para> Now, a caller may have the need to refer to a specific cipher implementation and thus does not want to rely on the priority-based selection. To accommodate this scenario, the kernel crypto API allows the cipher implementation to register a unique name in addition to common names. When using that unique name, a caller is therefore always sure to refer to the intended cipher implementation. </para> <para> The list of available ciphers is given in /proc/crypto. However, that list does not specify all possible permutations of templates and ciphers. Each block listed in /proc/crypto may contain the following information -- if one of the components listed as follows are not applicable to a cipher, it is not displayed: </para> <itemizedlist> <listitem> <para>name: the generic name of the cipher that is subject to the priority-based selection -- this name can be used by the cipher allocation API calls (all names listed above are examples for such generic names)</para> </listitem> <listitem> <para>driver: the unique name of the cipher -- this name can be used by the cipher allocation API calls</para> </listitem> <listitem> <para>module: the kernel module providing the cipher implementation (or "kernel" for statically linked ciphers)</para> </listitem> <listitem> <para>priority: the priority value of the cipher implementation</para> </listitem> <listitem> <para>refcnt: the reference count of the respective cipher (i.e. the number of current consumers of this cipher)</para> </listitem> <listitem> <para>selftest: specification whether the self test for the cipher passed</para> </listitem> <listitem> <para>type: <itemizedlist> <listitem> <para>blkcipher for synchronous block ciphers</para> </listitem> <listitem> <para>ablkcipher for asynchronous block ciphers</para> </listitem> <listitem> <para>cipher for single block ciphers that may be used with an additional template</para> </listitem> <listitem> <para>shash for synchronous message digest</para> </listitem> <listitem> <para>ahash for asynchronous message digest</para> </listitem> <listitem> <para>aead for AEAD cipher type</para> </listitem> <listitem> <para>compression for compression type transformations</para> </listitem> <listitem> <para>rng for random number generator</para> </listitem> <listitem> <para>givcipher for cipher with associated IV generator (see the geniv entry below for the specification of the IV generator type used by the cipher implementation)</para> </listitem> </itemizedlist> </para> </listitem> <listitem> <para>blocksize: blocksize of cipher in bytes</para> </listitem> <listitem> <para>keysize: key size in bytes</para> </listitem> <listitem> <para>ivsize: IV size in bytes</para> </listitem> <listitem> <para>seedsize: required size of seed data for random number generator</para> </listitem> <listitem> <para>digestsize: output size of the message digest</para> </listitem> <listitem> <para>geniv: IV generation type: <itemizedlist> <listitem> <para>eseqiv for encrypted sequence number based IV generation</para> </listitem> <listitem> <para>seqiv for sequence number based IV generation</para> </listitem> <listitem> <para>chainiv for chain iv generation</para> </listitem> <listitem> <para><builtin> is a marker that the cipher implements IV generation and handling as it is specific to the given cipher</para> </listitem> </itemizedlist> </para> </listitem> </itemizedlist> </sect1> <sect1><title>Key Sizes</title> <para> When allocating a cipher handle, the caller only specifies the cipher type. Symmetric ciphers, however, typically support multiple key sizes (e.g. AES-128 vs. AES-192 vs. AES-256). These key sizes are determined with the length of the provided key. Thus, the kernel crypto API does not provide a separate way to select the particular symmetric cipher key size. </para> </sect1> <sect1><title>Cipher Allocation Type And Masks</title> <para> The different cipher handle allocation functions allow the specification of a type and mask flag. Both parameters have the following meaning (and are therefore not covered in the subsequent sections). </para> <para> The type flag specifies the type of the cipher algorithm. The caller usually provides a 0 when the caller wants the default handling. Otherwise, the caller may provide the following selections which match the the aforementioned cipher types: </para> <itemizedlist> <listitem> <para>CRYPTO_ALG_TYPE_CIPHER Single block cipher</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_COMPRESS Compression</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data (MAC)</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_GIVCIPHER Asynchronous multi-block cipher packed together with an IV generator (see geniv field in the /proc/crypto listing for the known IV generators)</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_DIGEST Raw message digest</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_HASH Alias for CRYPTO_ALG_TYPE_DIGEST</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_RNG Random Number Generation</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression / decompression instead of performing the operation on one segment only. CRYPTO_ALG_TYPE_PCOMPRESS is intended to replace CRYPTO_ALG_TYPE_COMPRESS once existing consumers are converted.</para> </listitem> </itemizedlist> <para> The mask flag restricts the type of cipher. The only allowed flag is CRYPTO_ALG_ASYNC to restrict the cipher lookup function to asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.Lines 1–500 of 1253. Load more
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> <book id="KernelCryptoAPI"> <bookinfo> <title>Linux Kernel Crypto API</title> <authorgroup> <author> <firstname>Stephan</firstname> <surname>Mueller</surname> <affiliation> <address> <email>smueller@chronox.de</email> </address> </affiliation> </author> <author> <firstname>Marek</firstname> <surname>Vasut</surname> <affiliation> <address> <email>marek@denx.de</email> </address> </affiliation> </author> </authorgroup> <copyright> <year>2014</year> <holder>Stephan Mueller</holder> </copyright> <legalnotice> <para> This documentation is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. </para> <para> This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. </para> <para> You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA </para> <para> For more details see the file COPYING in the source distribution of Linux. </para> </legalnotice> </bookinfo> <toc></toc> <chapter id="Intro"> <title>Kernel Crypto API Interface Specification</title> <sect1><title>Introduction</title> <para> 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. </para> <para> 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. </para> <para> 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. </para> <para> The kernel crypto API serves the following entity types: <itemizedlist> <listitem> <para>consumers requesting cryptographic services</para> </listitem> <listitem> <para>data transformation implementations (typically ciphers) that can be called by consumers using the kernel crypto API</para> </listitem> </itemizedlist> </para> <para> 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). </para> <para> Note: The terms "transformation" and cipher algorithm are used interchangably. </para> </sect1> <sect1><title>Terminology</title> <para> The transformation implementation is an actual code or interface to hardware which implements a certain transformation with precisely defined behavior. </para> <para> 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). </para> <para> 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: </para> <orderedlist> <listitem> <para>Initialization of a cipher handle.</para> </listitem> <listitem> <para>Execution of all intended cipher operations applicable for the handle where the cipher handle must be furnished to every API call.</para> </listitem> <listitem> <para>Destruction of a cipher handle.</para> </listitem> </orderedlist> <para> 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_*. </para> <para> The transformation context is private data associated with the transformation object. </para> </sect1> </chapter> <chapter id="Architecture"><title>Kernel Crypto API Architecture</title> <sect1><title>Cipher algorithm types</title> <para> The kernel crypto API provides different API calls for the following cipher types: <itemizedlist> <listitem><para>Symmetric ciphers</para></listitem> <listitem><para>AEAD ciphers</para></listitem> <listitem><para>Message digest, including keyed message digest</para></listitem> <listitem><para>Random number generation</para></listitem> <listitem><para>User space interface</para></listitem> </itemizedlist> </para> </sect1> <sect1><title>Ciphers And Templates</title> <para> The kernel crypto API provides implementations of single block ciphers and message digests. In addition, the kernel crypto API provides numerous "templates" that can be used in conjunction with the single block ciphers and message digests. Templates include all types of block chaining mode, the HMAC mechanism, etc. </para> <para> Single block ciphers and message digests can either be directly used by a caller or invoked together with a template to form multi-block ciphers or keyed message digests. </para> <para> A single block cipher may even be called with multiple templates. However, templates cannot be used without a single cipher. </para> <para> See /proc/crypto and search for "name". For example: <itemizedlist> <listitem><para>aes</para></listitem> <listitem><para>ecb(aes)</para></listitem> <listitem><para>cmac(aes)</para></listitem> <listitem><para>ccm(aes)</para></listitem> <listitem><para>rfc4106(gcm(aes))</para></listitem> <listitem><para>sha1</para></listitem> <listitem><para>hmac(sha1)</para></listitem> <listitem><para>authenc(hmac(sha1),cbc(aes))</para></listitem> </itemizedlist> </para> <para> In these examples, "aes" and "sha1" are the ciphers and all others are the templates. </para> </sect1> <sect1><title>Synchronous And Asynchronous Operation</title> <para> The kernel crypto API provides synchronous and asynchronous API operations. </para> <para> When using the synchronous API operation, the caller invokes a cipher operation which is performed synchronously by the kernel crypto API. That means, the caller waits until the cipher operation completes. Therefore, the kernel crypto API calls work like regular function calls. For synchronous operation, the set of API calls is small and conceptually similar to any other crypto library. </para> <para> Asynchronous operation is provided by the kernel crypto API which implies that the invocation of a cipher operation will complete almost instantly. That invocation triggers the cipher operation but it does not signal its completion. Before invoking a cipher operation, the caller must provide a callback function the kernel crypto API can invoke to signal the completion of the cipher operation. Furthermore, the caller must ensure it can handle such asynchronous events by applying appropriate locking around its data. The kernel crypto API does not perform any special serialization operation to protect the caller's data integrity. </para> </sect1> <sect1><title>Crypto API Cipher References And Priority</title> <para> A cipher is referenced by the caller with a string. That string has the following semantics: <programlisting> template(single block cipher) </programlisting> where "template" and "single block cipher" is the aforementioned template and single block cipher, respectively. If applicable, additional templates may enclose other templates, such as <programlisting> template1(template2(single block cipher))) </programlisting> </para> <para> The kernel crypto API may provide multiple implementations of a template or a single block cipher. For example, AES on newer Intel hardware has the following implementations: AES-NI, assembler implementation, or straight C. Now, when using the string "aes" with the kernel crypto API, which cipher implementation is used? The answer to that question is the priority number assigned to each cipher implementation by the kernel crypto API. When a caller uses the string to refer to a cipher during initialization of a cipher handle, the kernel crypto API looks up all implementations providing an implementation with that name and selects the implementation with the highest priority. </para> <para> Now, a caller may have the need to refer to a specific cipher implementation and thus does not want to rely on the priority-based selection. To accommodate this scenario, the kernel crypto API allows the cipher implementation to register a unique name in addition to common names. When using that unique name, a caller is therefore always sure to refer to the intended cipher implementation. </para> <para> The list of available ciphers is given in /proc/crypto. However, that list does not specify all possible permutations of templates and ciphers. Each block listed in /proc/crypto may contain the following information -- if one of the components listed as follows are not applicable to a cipher, it is not displayed: </para> <itemizedlist> <listitem> <para>name: the generic name of the cipher that is subject to the priority-based selection -- this name can be used by the cipher allocation API calls (all names listed above are examples for such generic names)</para> </listitem> <listitem> <para>driver: the unique name of the cipher -- this name can be used by the cipher allocation API calls</para> </listitem> <listitem> <para>module: the kernel module providing the cipher implementation (or "kernel" for statically linked ciphers)</para> </listitem> <listitem> <para>priority: the priority value of the cipher implementation</para> </listitem> <listitem> <para>refcnt: the reference count of the respective cipher (i.e. the number of current consumers of this cipher)</para> </listitem> <listitem> <para>selftest: specification whether the self test for the cipher passed</para> </listitem> <listitem> <para>type: <itemizedlist> <listitem> <para>blkcipher for synchronous block ciphers</para> </listitem> <listitem> <para>ablkcipher for asynchronous block ciphers</para> </listitem> <listitem> <para>cipher for single block ciphers that may be used with an additional template</para> </listitem> <listitem> <para>shash for synchronous message digest</para> </listitem> <listitem> <para>ahash for asynchronous message digest</para> </listitem> <listitem> <para>aead for AEAD cipher type</para> </listitem> <listitem> <para>compression for compression type transformations</para> </listitem> <listitem> <para>rng for random number generator</para> </listitem> <listitem> <para>givcipher for cipher with associated IV generator (see the geniv entry below for the specification of the IV generator type used by the cipher implementation)</para> </listitem> </itemizedlist> </para> </listitem> <listitem> <para>blocksize: blocksize of cipher in bytes</para> </listitem> <listitem> <para>keysize: key size in bytes</para> </listitem> <listitem> <para>ivsize: IV size in bytes</para> </listitem> <listitem> <para>seedsize: required size of seed data for random number generator</para> </listitem> <listitem> <para>digestsize: output size of the message digest</para> </listitem> <listitem> <para>geniv: IV generation type: <itemizedlist> <listitem> <para>eseqiv for encrypted sequence number based IV generation</para> </listitem> <listitem> <para>seqiv for sequence number based IV generation</para> </listitem> <listitem> <para>chainiv for chain iv generation</para> </listitem> <listitem> <para><builtin> is a marker that the cipher implements IV generation and handling as it is specific to the given cipher</para> </listitem> </itemizedlist> </para> </listitem> </itemizedlist> </sect1> <sect1><title>Key Sizes</title> <para> When allocating a cipher handle, the caller only specifies the cipher type. Symmetric ciphers, however, typically support multiple key sizes (e.g. AES-128 vs. AES-192 vs. AES-256). These key sizes are determined with the length of the provided key. Thus, the kernel crypto API does not provide a separate way to select the particular symmetric cipher key size. </para> </sect1> <sect1><title>Cipher Allocation Type And Masks</title> <para> The different cipher handle allocation functions allow the specification of a type and mask flag. Both parameters have the following meaning (and are therefore not covered in the subsequent sections). </para> <para> The type flag specifies the type of the cipher algorithm. The caller usually provides a 0 when the caller wants the default handling. Otherwise, the caller may provide the following selections which match the the aforementioned cipher types: </para> <itemizedlist> <listitem> <para>CRYPTO_ALG_TYPE_CIPHER Single block cipher</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_COMPRESS Compression</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data (MAC)</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_GIVCIPHER Asynchronous multi-block cipher packed together with an IV generator (see geniv field in the /proc/crypto listing for the known IV generators)</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_DIGEST Raw message digest</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_HASH Alias for CRYPTO_ALG_TYPE_DIGEST</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_RNG Random Number Generation</para> </listitem> <listitem> <para>CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression / decompression instead of performing the operation on one segment only. CRYPTO_ALG_TYPE_PCOMPRESS is intended to replace CRYPTO_ALG_TYPE_COMPRESS once existing consumers are converted.</para> </listitem> </itemizedlist> <para> The mask flag restricts the type of cipher. The only allowed flag is CRYPTO_ALG_ASYNC to restrict the cipher lookup function to asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.