diff options
author | Stephan Mueller <smueller@chronox.de> | 2016-10-21 04:57:00 +0200 |
---|---|---|
committer | Jonathan Corbet <corbet@lwn.net> | 2016-12-13 16:38:04 -0700 |
commit | c441a4781ff1c5b78db1410f708aa96dceec5fa2 (patch) | |
tree | ccd31f1748b0c54ec33925e3ac9d48437dc80e8b /Documentation/DocBook | |
parent | 3b72c814a8e8cd638e1ba0da4dfce501e9dff5af (diff) |
crypto: doc - remove crypto API DocBook
With the conversion of the documentation to Sphinx, the old DocBook is
now stale.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/DocBook')
-rw-r--r-- | Documentation/DocBook/Makefile | 2 | ||||
-rw-r--r-- | Documentation/DocBook/crypto-API.tmpl | 2092 |
2 files changed, 1 insertions, 2093 deletions
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index caab9039362f..c75e5d6b8fa8 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -13,7 +13,7 @@ DOCBOOKS := z8530book.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml sh.xml regulator.xml w1.xml \ - writing_musb_glue_layer.xml crypto-API.xml iio.xml + writing_musb_glue_layer.xml iio.xml ifeq ($(DOCBOOKS),) diff --git a/Documentation/DocBook/crypto-API.tmpl b/Documentation/DocBook/crypto-API.tmpl deleted file mode 100644 index 088b79c341ff..000000000000 --- a/Documentation/DocBook/crypto-API.tmpl +++ /dev/null @@ -1,2092 +0,0 @@ -<?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 - interchangeably. - </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>skcipher for symmetric key 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 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_AKCIPHER Asymmetric cipher</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. - </para> - - <para> - When the caller provides a mask and type specification, the - caller limits the search the kernel crypto API can perform for - a suitable cipher implementation for the given cipher name. - That means, even when a caller uses a cipher name that exists - during its initialization call, the kernel crypto API may not - select it due to the used type and mask field. - </para> - </sect1> - - <sect1><title>Internal Structure of Kernel Crypto API</title> - - <para> - The kernel crypto API has an internal structure where a cipher - implementation may use many layers and indirections. This section - shall help to clarify how the kernel crypto API uses - various components to implement the complete cipher. - </para> - - <para> - The following subsections explain the internal structure based - on existing cipher implementations. The first section addresses - the most complex scenario where all other scenarios form a logical - subset. - </para> - - <sect2><title>Generic AEAD Cipher Structure</title> - - <para> - The following ASCII art decomposes the kernel crypto API layers - when using the AEAD cipher with the automated IV generation. The - shown example is used by the IPSEC layer. - </para> - - <para> - For other use cases of AEAD ciphers, the ASCII art applies as - well, but the caller may not use the AEAD cipher with a separate - IV generator. In this case, the caller must generate the IV. - </para> - - <para> - The depicted example decomposes the AEAD cipher of GCM(AES) based - on the generic C implementations (gcm.c, aes-generic.c, ctr.c, - ghash-generic.c, seqiv.c). The generic implementation serves as an - example showing the complete logic of the kernel crypto API. - </para> - - <para> - It is possible that some streamlined cipher implementations (like - AES-NI) provide implementations merging aspects which in the view - of the kernel crypto API cannot be decomposed into layers any more. - In case of the AES-NI implementation, the CTR mode, the GHASH - implementation and the AES cipher are all merged into one cipher - implementation registered with the kernel crypto API. In this case, - the concept described by the following ASCII art applies too. However, - the decomposition of GCM into the individual sub-components - by the kernel crypto API is not done any more. - </para> - - <para> - Each block in the following ASCII art is an independent cipher - instance obtained from the kernel crypto API. Each block - is accessed by the caller or by other blocks using the API functions - defined by the kernel crypto API for the cipher implementation type. - </para> - - <para> - The blocks below indicate the cipher type as well as the specific - logic implemented in the cipher. - </para> - - <para> - The ASCII art picture also indicates the call structure, i.e. who - calls which component. The arrows point to the invoked block - where the caller uses the API applicable to the cipher type - specified for the block. - </para> - - <programlisting> -<![CDATA[ -kernel crypto API | IPSEC Layer - | -+-----------+ | -| | (1) -| aead | <----------------------------------- esp_output -| (seqiv) | ---+ -+-----------+ | - | (2) -+-----------+ | -| | <--+ (2) -| aead | <----------------------------------- esp_input -| (gcm) | ------------+ -+-----------+ | - | (3) | (5) - v v -+-----------+ +-----------+ -| | | | -| skcipher | | ahash | -| (ctr) | ---+ | (ghash) | -+-----------+ | +-----------+ - | -+-----------+ | (4) -| | <--+ -| cipher | -| (aes) | -+-----------+ -]]> - </programlisting> - - <para> - The following call sequence is applicable when the IPSEC layer - triggers an encryption operation with the esp_output function. During - configuration, the administrator set up the use of rfc4106(gcm(aes)) as - the cipher for ESP. The following call sequence is now depicted in the - ASCII art above: - </para> - - <orderedlist> - <listitem> - <para> - esp_output() invokes crypto_aead_encrypt() to trigger an encryption - operation of the AEAD cipher with IV generator. - </para> - - <para> - In case of GCM, the SEQIV implementation is registered as GIVCIPHER - in crypto_rfc4106_alloc(). - </para> - - <para> - The SEQIV performs its operation to generate an IV where the core - function is seqiv_geniv(). - </para> - </listitem> - - <listitem> - <para> - Now, SEQIV uses the AEAD API function calls to invoke the associated - AEAD cipher. In our case, during the instantiation of SEQIV, the - cipher handle for GCM is provided to SEQIV. This means that SEQIV - invokes AEAD cipher operations with the GCM cipher handle. - </para> - - <para> - During instantiation of the GCM handle, the CTR(AES) and GHASH - ciphers are instantiated. The cipher handles for CTR(AES) and GHASH - are retained for later use. - </para> - - <para> - The GCM implementation is responsible to invoke the CTR mode AES and - the GHASH cipher in the right manner to implement the GCM - specification. - </para> - </listitem> - - <listitem> - <para> - The GCM AEAD cipher type implementation now invokes the SKCIPHER API - with the instantiated CTR(AES) cipher handle. - </para> - - <para> - During instantiation of the CTR(AES) cipher, the CIPHER type - implementation of AES is instantiated. The cipher handle for AES is - retained. - </para> - - <para> - That means that the SKCIPHER implementation of CTR(AES) only - implements the CTR block chaining mode. After performing the block - chaining operation, the CIPHER implementation of AES is invoked. - </para> - </listitem> - - <listitem> - <para> - The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES - cipher handle to encrypt one block. - </para> - </listitem> - - <listitem> - <para> - The GCM AEAD implementation also invokes the GHASH cipher - implementation via the AHASH API. - </para> - </listitem> - </orderedlist> - - <para> - When the IPSEC layer triggers the esp_input() function, the same call - sequence is followed with the only difference that the operation starts - with step (2). - </para> - </sect2> - - <sect2><title>Generic Block Cipher Structure</title> - <para> - Generic block ciphers follow the same concept as depicted with the ASCII - art picture above. - </para> - - <para> - For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The - ASCII art picture above applies as well with the difference that only - step (4) is used and the SKCIPHER block chaining mode is CBC. - </para> - </sect2> - - <sect2><title>Generic Keyed Message Digest Structure</title> - <para> - Keyed message digest implementations again follow the same concept as - depicted in the ASCII art picture above. - </para> - - <para> - For example, HMAC(SHA256) is implemented with hmac.c and - sha256_generic.c. The following ASCII art illustrates the - implementation: - </para> - - <programlisting> -<![CDATA[ -kernel crypto API | Caller - | -+-----------+ (1) | -| | <------------------ some_function -| ahash | -| (hmac) | ---+ -+-----------+ | - | (2) -+-----------+ | -| | <--+ -| shash | -| (sha256) | -+-----------+ -]]> - </programlisting> - - <para> - The following call sequence is applicable when a caller triggers - an HMAC operation: - </para> - - <orderedlist> - <listitem> - <para> - The AHASH API functions are invoked by the caller. The HMAC - implementation performs its operation as needed. - </para> - - <para> - During initialization of the HMAC cipher, the SHASH cipher type of - SHA256 is instantiated. The cipher handle for the SHA256 instance is - retained. - </para> - - <para> - At one time, the HMAC implementation requires a SHA256 operation - where the SHA256 cipher handle is used. - </para> - </listitem> - - <listitem> - <para> - The HMAC instance now invokes the SHASH API with the SHA256 - cipher handle to calculate the message digest. - </para> - </listitem> - </orderedlist> - </sect2> - </sect1> - </chapter> - - <chapter id="Development"><title>Developing Cipher Algorithms</title> - <sect1><title>Registering And Unregistering Transformation</title> - <para> - There are three distinct types of registration functions in - the Crypto API. One is used to register a generic cryptographic - transformation, while the other two are specific to HASH - transformations and COMPRESSion. We will discuss the latter - two in a separate chapter, here we will only look at the - generic ones. - </para> - - <para> - Before discussing the register functions, the data structure - to be filled with each, struct crypto_alg, must be considered - -- see below for a description of this data structure. - </para> - - <para> - The generic registration functions can be found in - include/linux/crypto.h and their definition can be seen below. - The former function registers a single transformation, while - the latter works on an array of transformation descriptions. - The latter is useful when registering transformations in bulk, - for example when a driver implements multiple transformations. - </para> - - <programlisting> - int crypto_register_alg(struct crypto_alg *alg); - int crypto_register_algs(struct crypto_alg *algs, int count); - </programlisting> - - <para> - The counterparts to those functions are listed below. - </para> - - <programlisting> - int crypto_unregister_alg(struct crypto_alg *alg); - int crypto_unregister_algs(struct crypto_alg *algs, int count); - </programlisting> - - <para> - Notice that both registration and unregistration functions - do return a value, so make sure to handle errors. A return - code of zero implies success. Any return code < 0 implies - an error. - </para> - - <para> - The bulk registration/unregistration functions - register/unregister each transformation in the given array of - length count. They handle errors as follows: - </para> - <itemizedlist> - <listitem> - <para> - crypto_register_algs() succeeds if and only if it - successfully registers all the given transformations. If an - error occurs partway through, then it rolls back successful - registrations before returning the error code. Note that if - a driver needs to handle registration errors for individual - transformations, then it will need to use the non-bulk - function crypto_register_alg() instead. - </para> - </listitem> - <listitem> - <para> - crypto_unregister_algs() tries to unregister all the given - transformations, continuing on error. It logs errors and - always returns zero. - </para> - </listitem> - </itemizedlist> - - </sect1> - - <sect1><title>Single-Block Symmetric Ciphers [CIPHER]</title> - <para> - Example of transformations: aes, arc4, ... - </para> - - <para> - This section describes the simplest of all transformation - implementations, that being the CIPHER type used for symmetric - ciphers. The CIPHER type is used for transformations which - operate on exactly one block at a time and there are no - dependencies between blocks at all. - </para> - - <sect2><title>Registration specifics</title> - <para> - The registration of [CIPHER] algorithm is specific in that - struct crypto_alg field .cra_type is empty. The .cra_u.cipher - has to be filled in with proper callbacks to implement this - transformation. - </para> - - <para> - See struct cipher_alg below. - </para> - </sect2> - - <sect2><title>Cipher Definition With struct cipher_alg</title> - <para> - Struct cipher_alg defines a single block cipher. - </para> - - <para> - Here are schematics of how these functions are called when - operated from other part of the kernel. Note that the - .cia_setkey() call might happen before or after any of these - schematics happen, but must not happen during any of these - are in-flight. - </para> - - <para> - <programlisting> - KEY ---. PLAINTEXT ---. - v v - .cia_setkey() -> .cia_encrypt() - | - '-----> CIPHERTEXT - </programlisting> - </para> - - <para> - Please note that a pattern where .cia_setkey() is called - multiple times is also valid: - </para> - - <para> - <programlisting> - - KEY1 --. PLAINTEXT1 --. KEY2 --. PLAINTEXT2 --. - v v v v - .cia_setkey() -> .cia_encrypt() -> .cia_setkey() -> .cia_encrypt() - | | - '---> CIPHERTEXT1 '---> CIPHERTEXT2 - </programlisting> - </para> - - </sect2> - </sect1> - - <sect1><title>Multi-Block Ciphers</title> - <para> - Example of transformations: cbc(aes), ecb(arc4), ... - </para> - - <para> - This section describes the multi-block cipher transformation - implementations. The multi-block ciphers are - used for transformations which operate on scatterlists of - data supplied to the transformation functions. They output - the result into a scatterlist of data as well. - </para> - - <sect2><title>Registration Specifics</title> |