summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2016-12-17 16:00:34 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2016-12-17 16:00:34 -0800
commit0aaf2146ecf00f7932f472ec5aa30d999c89530c (patch)
tree690dd244437f1974b8132fcb1e360213f827bf94
parent59331c215daf600a650e281b6e8ef3e1ed1174c2 (diff)
parent3fa71d0f58a9b9df84e8e79196f961bcfbf01b2e (diff)
downloadlinux-0aaf2146ecf00f7932f472ec5aa30d999c89530c.tar.bz2
Merge tag 'docs-4.10-2' of git://git.lwn.net/linux
Pull more documentation updates from Jonathan Corbet: "This converts the crypto DocBook to Sphinx" * tag 'docs-4.10-2' of git://git.lwn.net/linux: crypto: doc - optimize compilation crypto: doc - clarify AEAD memory structure crypto: doc - remove crypto_alloc_ablkcipher crypto: doc - add KPP documentation crypto: doc - fix separation of cipher / req API crypto: doc - fix source comments for Sphinx crypto: doc - remove crypto API DocBook crypto: doc - convert crypto API documentation to Sphinx
-rw-r--r--Documentation/DocBook/Makefile2
-rw-r--r--Documentation/DocBook/crypto-API.tmpl2092
-rw-r--r--Documentation/crypto/api-aead.rst23
-rw-r--r--Documentation/crypto/api-akcipher.rst20
-rw-r--r--Documentation/crypto/api-digest.rst35
-rw-r--r--Documentation/crypto/api-kpp.rst38
-rw-r--r--Documentation/crypto/api-rng.rst14
-rw-r--r--Documentation/crypto/api-samples.rst224
-rw-r--r--Documentation/crypto/api-skcipher.rst62
-rw-r--r--Documentation/crypto/api.rst25
-rw-r--r--Documentation/crypto/architecture.rst441
-rw-r--r--Documentation/crypto/devel-algos.rst247
-rw-r--r--Documentation/crypto/index.rst24
-rw-r--r--Documentation/crypto/intro.rst74
-rw-r--r--Documentation/crypto/userspace-if.rst387
-rw-r--r--Documentation/index.rst1
-rw-r--r--crypto/algif_aead.c14
-rw-r--r--include/crypto/aead.h50
-rw-r--r--include/crypto/dh.h58
-rw-r--r--include/crypto/ecdh.h58
-rw-r--r--include/crypto/hash.h2
-rw-r--r--include/crypto/kpp.h15
-rw-r--r--include/crypto/skcipher.h4
-rw-r--r--include/linux/crypto.h4
24 files changed, 1770 insertions, 2144 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>&lt;builtin&gt; 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 &lt; 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() -&gt; .cia_encrypt()
- |
- '-----&gt; 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() -&gt; .cia_encrypt() -&gt; .cia_setkey() -&gt; .cia_encrypt()
- | |
- '---&gt; CIPHERTEXT1 '---&gt; 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>
-
- <para>
- The registration of multi-block cipher algorithms
- is one of the most standard procedures throughout the crypto API.
- </para>
-
- <para>
- Note, if a cipher implementation requires a proper alignment
- of data, the caller should use the functions of
- crypto_skcipher_alignmask() to identify a memory alignment mask.
- The kernel crypto API is able to process requests that are unaligned.
- This implies, however, additional overhead as the kernel
- crypto API needs to perform the realignment of the data which
- may imply moving of data.
- </para>
- </sect2>
-
- <sect2><title>Cipher Definition With struct blkcipher_alg and ablkcipher_alg</title>
- <para>
- Struct blkcipher_alg defines a synchronous block cipher whereas
- struct ablkcipher_alg defines an asynchronous block cipher.
- </para>
-
- <para>
- Please refer to the single block cipher description for schematics
- of the block cipher usage.
- </para>
- </sect2>
-
- <sect2><title>Specifics Of Asynchronous Multi-Block Cipher</title>
- <para>
- There are a couple of specifics to the asynchronous interface.
- </para>
-
- <para>
- First of all, some of the drivers will want to use the
- Generic ScatterWalk in case the hardware needs to be fed
- separate chunks of the scatterlist which contains the
- plaintext and will contain the ciphertext. Please refer
- to the ScatterWalk interface offered by the Linux kernel
- scatter / gather list implementation.
- </para>
- </sect2>
- </sect1>
-
- <sect1><title>Hashing [HASH]</title>
-
- <para>
- Example of transformations: crc32, md5, sha1, sha256,...
- </para>
-
- <sect2><title>Registering And Unregistering The Transformation</title>
-
- <para>
- There are multiple ways to register a HASH transformation,
- depending on whether the transformation is synchronous [SHASH]
- or asynchronous [AHASH] and the amount of HASH transformations
- we are registering. You can find the prototypes defined in
- include/crypto/internal/hash.h:
- </para>
-
- <programlisting>
- int crypto_register_ahash(struct ahash_alg *alg);
-
- int crypto_register_shash(struct shash_alg *alg);
- int crypto_register_shashes(struct shash_alg *algs, int count);
- </programlisting>
-
- <para>
- The respective counterparts for unregistering the HASH
- transformation are as follows:
- </para>
-
- <programlisting>
- int crypto_unregister_ahash(struct ahash_alg *alg);
-
- int crypto_unregister_shash(struct shash_alg *alg);
- int crypto_unregister_shashes(struct shash_alg *algs, int count);
- </programlisting>
- </sect2>
-
- <sect2><title>Cipher Definition With struct shash_alg and ahash_alg</title>
- <para>
- Here are schematics of how these functions are called when
- operated from other part of the kernel. Note that the .setkey()
- call might happen before or after any of these schematics happen,
- but must not happen during any of these are in-flight. Please note
- that calling .init() followed immediately by .finish() is also a
- perfectly valid transformation.
- </para>
-
- <programlisting>
- I) DATA -----------.
- v
- .init() -&gt; .update() -&gt; .final() ! .update() might not be called
- ^ | | at all in this scenario.
- '----' '---&gt; HASH
-
- II) DATA -----------.-----------.
- v v
- .init() -&gt; .update() -&gt; .finup() ! .update() may not be called
- ^ | | at all in this scenario.
- '----' '---&gt; HASH
-
- III) DATA -----------.
- v
- .digest() ! The entire process is handled
- | by the .digest() call.
- '---------------&gt; HASH
- </programlisting>
-
- <para>
- Here is a schematic of how the .export()/.import() functions are
- called when used from another part of the kernel.
- </para>
-
- <programlisting>
- KEY--. DATA--.
- v v ! .update() may not be called
- .setkey() -&gt; .init() -&gt; .update() -&gt; .export() at all in this scenario.
- ^ | |
- '-----' '--&gt; PARTIAL_HASH
-
- ----------- other transformations happen here -----------
-
- PARTIAL_HASH--. DATA1--.
- v v
- .import -&gt; .update() -&gt; .final() ! .update() may not be called
- ^ | | at all in this scenario.
- '----' '--&gt; HASH1
-
- PARTIAL_HASH--. DATA2-.
- v v
- .import -&gt; .finup()
- |
- '---------------&gt; HASH2
- </programlisting>
- </sect2>
-
- <sect2><title>Specifics Of Asynchronous HASH Transformation</title>
- <para>
- Some of the drivers will want to use the Generic ScatterWalk
- in case the implementation needs to be fed separate chunks of the
- scatterlist which contains the input data. The buffer containing
- the resulting hash will always be properly aligned to
- .cra_alignmask so there is no need to worry about this.
- </para>
- </sect2>
- </sect1>
- </chapter>
-
- <chapter id="User"><title>User Space Interface</title>
- <sect1><title>Introduction</title>
- <para>
- The concepts of the kernel crypto API visible to kernel space is fully
- applicable to the user space interface as well. Therefore, the kernel
- crypto API high level discussion for the in-kernel use cases applies
- here as well.
- </para>
-
- <para>
- The major difference, however, is that user space can only act as a
- consumer and never as a provider of a transformation or cipher algorithm.
- </para>
-
- <para>
- The following covers the user space interface exported by the kernel
- crypto API. A working example of this description is libkcapi that
- can be obtained from [1]. That library can be used by user space
- applications that require cryptographic services from the kernel.
- </para>
-
- <para>
- Some details of the in-kernel kernel crypto API aspects do not
- apply to user space, however. This includes the difference between
- synchronous and asynchronous invocations. The user space API call
- is fully synchronous.
- </para>
-
- <para>
- [1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
- </para>
-
- </sect1>
-
- <sect1><title>User Space API General Remarks</title>
- <para>
- The kernel crypto API is accessible from user space. Currently,
- the following ciphers are accessible:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>Message digest including keyed message digest (HMAC, CMAC)</para>
- </listitem>
-
- <listitem>
- <para>Symmetric ciphers</para>
- </listitem>
-
- <listitem>
- <para>AEAD ciphers</para>
- </listitem>
-
- <listitem>
- <para>Random Number Generators</para>
- </listitem>
- </itemizedlist>
-
- <para>
- The interface is provided via socket type using the type AF_ALG.
- In addition, the setsockopt option type is SOL_ALG. In case the
- user space header files do not export these flags yet, use the
- following macros:
- </para>
-
- <programlisting>
-#ifndef AF_ALG
-#define AF_ALG 38
-#endif
-#ifndef SOL_ALG
-#define SOL_ALG 279
-#endif
- </programlisting>
-
- <para>
- A cipher is accessed with the same name as done for the in-kernel
- API calls. This includes the generic vs. unique naming schema for
- ciphers as well as the enforcement of priorities for generic names.
- </para>
-
- <para>
- To interact with the kernel crypto API, a socket must be
- created by the user space application. User space invokes the cipher
- operation with the send()/write() system call family. The result of the
- cipher operation is obtained with the read()/recv() system call family.
- </para>
-
- <para>
- The following API calls assume that the socket descriptor
- is already opened by the user space application and discusses only
- the kernel crypto API specific invocations.
- </para>
-
- <para>
- To initialize the socket interface, the following sequence has to
- be performed by the consumer:
- </para>
-
- <orderedlist>
- <listitem>
- <para>
- Create a socket of type AF_ALG with the struct sockaddr_alg
- parameter specified below for the different cipher types.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Invoke bind with the socket descriptor
- </para>
- </listitem>
-
- <listitem>
- <para>
- Invoke accept with the socket descriptor. The accept system call
- returns a new file descriptor that is to be used to interact with
- the particular cipher instance. When invoking send/write or recv/read
- system calls to send data to the kernel or obtain data from the
- kernel, the file descriptor returned by accept must be used.
- </para>
- </listitem>
- </orderedlist>
- </sect1>
-
- <sect1><title>In-place Cipher operation</title>
- <para>
- Just like the in-kernel operation of the kernel crypto API, the user
- space interface allows the cipher operation in-place. That means that
- the input buffer used for the send/write system call and the output
- buffer used by the read/recv system call may be one and the same.
- This is of particular interest for symmetric cipher operations where a
- copying of the output data to its final destination can be avoided.
- </para>
-
- <para>
- If a consumer on the other hand wants to maintain the plaintext and
- the ciphertext in different memory locations, all a consumer needs
- to do is to provide different memory pointers for the encryption and
- decryption operation.
- </para>
- </sect1>
-
- <sect1><title>Message Digest API</title>
- <para>
- The message digest type to be used for the cipher operation is
- selected when invoking the bind syscall. bind requires the caller
- to provide a filled struct sockaddr data structure. This data
- structure must be filled as follows:
- </para>
-
- <programlisting>
-struct sockaddr_alg sa = {
- .salg_family = AF_ALG,
- .salg_type = "hash", /* this selects the hash logic in the kernel */
- .salg_name = "sha1" /* this is the cipher name */
-};
- </programlisting>
-
- <para>
- The salg_type value "hash" applies to message digests and keyed
- message digests. Though, a keyed message digest is referenced by
- the appropriate salg_name. Please see below for the setsockopt
- interface that explains how the key can be set for a keyed message
- digest.
- </para>
-
- <para>
- Using the send() system call, the application provides the data that
- should be processed with the message digest. The send system call
- allows the following flags to be specified:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- MSG_MORE: If this flag is set, the send system call acts like a
- message digest update function where the final hash is not
- yet calculated. If the flag is not set, the send system call
- calculates the final message digest immediately.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- With the recv() system call, the application can read the message
- digest from the kernel crypto API. If the buffer is too small for the
- message digest, the flag MSG_TRUNC is set by the kernel.
- </para>
-
- <para>
- In order to set a message digest key, the calling application must use
- the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC
- operation is performed without the initial HMAC state change caused by
- the key.
- </para>
- </sect1>
-
- <sect1><title>Symmetric Cipher API</title>
- <para>
- The operation is very similar to the message digest discussion.
- During initialization, the struct sockaddr data structure must be
- filled as follows:
- </para>
-
- <programlisting>
-struct sockaddr_alg sa = {
- .salg_family = AF_ALG,
- .salg_type = "skcipher", /* this selects the symmetric cipher */
- .salg_name = "cbc(aes)" /* this is the cipher name */
-};
- </programlisting>
-
- <para>
- Before data can be sent to the kernel using the write/send system
- call family, the consumer must set the key. The key setting is
- described with the setsockopt invocation below.
- </para>
-
- <para>
- Using the sendmsg() system call, the application provides the data that should be processed for encryption or decryption. In addition, the IV is
- specified with the data structure provided by the sendmsg() system call.
- </para>
-
- <para>
- The sendmsg system call parameter of struct msghdr is embedded into the
- struct cmsghdr data structure. See recv(2) and cmsg(3) for more
- information on how the cmsghdr data structure is used together with the
- send/recv system call family. That cmsghdr data structure holds the
- following information specified with a separate header instances:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- specification of the cipher operation type with one of these flags:
- </para>
- <itemizedlist>
- <listitem>
- <para>ALG_OP_ENCRYPT - encryption of data</para>
- </listitem>
- <listitem>
- <para>ALG_OP_DECRYPT - decryption of data</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- specification of the IV information marked with the flag ALG_SET_IV
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- The send system call family allows the following flag to be specified:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- MSG_MORE: If this flag is set, the send system call acts like a
- cipher update function where more input data is expected
- with a subsequent invocation of the send system call.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- Note: The kernel reports -EINVAL for any unexpected data. The caller
- must make sure that all data matches the constraints given in
- /proc/crypto for the selected cipher.
- </para>
-
- <para>
- With the recv() system call, the application can read the result of
- the cipher operation from the kernel crypto API. The output buffer
- must be at least as large as to hold all blocks of the encrypted or
- decrypted data. If the output data size is smaller, only as many
- blocks are returned that fit into that output buffer size.
- </para>
- </sect1>
-
- <sect1><title>AEAD Cipher API</title>
- <para>
- The operation is very similar to the symmetric cipher discussion.
- During initialization, the struct sockaddr data structure must be
- filled as follows:
- </para>
-
- <programlisting>
-struct sockaddr_alg sa = {
- .salg_family = AF_ALG,
- .salg_type = "aead", /* this selects the symmetric cipher */
- .salg_name = "gcm(aes)" /* this is the cipher name */
-};
- </programlisting>
-
- <para>
- Before data can be sent to the kernel using the write/send system
- call family, the consumer must set the key. The key setting is
- described with the setsockopt invocation below.
- </para>
-
- <para>
- In addition, before data can be sent to the kernel using the
- write/send system call family, the consumer must set the authentication
- tag size. To set the authentication tag size, the caller must use the
- setsockopt invocation described below.
- </para>
-
- <para>
- Using the sendmsg() system call, the application provides the data that should be processed for encryption or decryption. In addition, the IV is
- specified with the data structure provided by the sendmsg() system call.
- </para>
-
- <para>
- The sendmsg system call parameter of struct msghdr is embedded into the
- struct cmsghdr data structure. See recv(2) and cmsg(3) for more
- information on how the cmsghdr data structure is used together with the
- send/recv system call family. That cmsghdr data structure holds the
- following information specified with a separate header instances:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- specification of the cipher operation type with one of these flags:
- </para>
- <itemizedlist>
- <listitem>
- <para>ALG_OP_ENCRYPT - encryption of data</para>
- </listitem>
- <listitem>
- <para>ALG_OP_DECRYPT - decryption of data</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- specification of the IV information marked with the flag ALG_SET_IV
- </para>
- </listitem>
-
- <listitem>
- <para>
- specification of the associated authentication data (AAD) with the
- flag ALG_SET_AEAD_ASSOCLEN. The AAD is sent to the kernel together
- with the plaintext / ciphertext. See below for the memory structure.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- The send system call family allows the following flag to be specified:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- MSG_MORE: If this flag is set, the send system call acts like a
- cipher update function where more input data is expected
- with a subsequent invocation of the send system call.
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- Note: The kernel reports -EINVAL for any unexpected data. The caller
- must make sure that all data matches the constraints given in
- /proc/crypto for the selected cipher.
- </para>
-
- <para>
- With the recv() system call, the application can read the result of
- the cipher operation from the kernel crypto API. The output buffer
- must be at least as large as defined with the memory structure below.
- If the output data size is smaller, the cipher operation is not performed.
- </para>
-
- <para>
- The authenticated decryption operation may indicate an integrity error.
- Such breach in integrity is marked with the -EBADMSG error code.
- </para>
-
- <sect2><title>AEAD Memory Structure</title>
- <para>
- The AEAD cipher operates with the following information that
- is communicated between user and kernel space as one data stream:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>plaintext or ciphertext</para>
- </listitem>
-
- <listitem>
- <para>associated authentication data (AAD)</para>
- </listitem>
-
- <listitem>
- <para>authentication tag</para>
- </listitem>
- </itemizedlist>
-
- <para>
- The sizes of the AAD and the authentication tag are provided with
- the sendmsg and setsockopt calls (see there). As the kernel knows
- the size of the entire data stream, the kernel is now able to
- calculate the right offsets of the data components in the data
- stream.
- </para>
-
- <para>
- The user space caller must arrange the aforementioned information
- in the following order:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- AEAD encryption input: AAD || plaintext
- </para>
- </listitem>
-
- <listitem>
- <para>
- AEAD decryption input: AAD || ciphertext || authentication tag
- </para>
- </listitem>
- </itemizedlist>
-
- <para>
- The output buffer the user space caller provides must be at least as
- large to hold the following data:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- AEAD encryption output: ciphertext || authentication tag
- </para>
- </listitem>
-
- <listitem>
- <para>
- AEAD decryption output: plaintext
- </para>
- </listitem>
- </itemizedlist>
- </sect2>
- </sect1>
-
- <sect1><title>Random Number Generator API</title>
- <para>
- Again, the operation is very similar to the other APIs.
- During initialization, the struct sockaddr data structure must be
- filled as follows:
- </para>
-
- <programlisting>
-struct sockaddr_alg sa = {
- .salg_family = AF_ALG,
- .salg_type = "rng", /* this selects the symmetric cipher */
- .salg_name = "drbg_nopr_sha256" /* this is the cipher name */
-};
- </programlisting>
-
- <para>
- Depending on the RNG type, the RNG must be seeded. The seed is provided
- using the setsockopt interface to set the key. For example, the
- ansi_cprng requires a seed. The DRBGs do not require a seed, but
- may be seeded.
- </para>
-
- <para>
- Using the read()/recvmsg() system calls, random numbers can be obtained.
- The kernel generates at most 128 bytes in one call. If user space
- requires more data, multiple calls to read()/recvmsg() must be made.
- </para>
-
- <para>
- WARNING: The user space caller may invoke the initially mentioned
- accept system call multiple times. In this case, the returned file
- descriptors have the same state.
- </para>
-
- </sect1>
-
- <sect1><title>Zero-Copy Interface</title>
- <para>
- In addition to the send/write/read/recv system call family, the AF_ALG
- interface can be accessed with the zero-copy interface of splice/vmsplice.
- As the name indicates, the kernel tries to avoid a copy operation into
- kernel space.
- </para>
-
- <para>
- The zero-copy operation requires data to be aligned at the page boundary.
- Non-aligned data can be used as well, but may require more operations of
- the kernel which would defeat the speed gains obtained from the zero-copy
- interface.
- </para>
-
- <para>
- The system-interent limit for the size of one zero-copy operation is
- 16 pages. If more data is to be sent to AF_ALG, user space must slice
- the input into segments with a maximum size of 16 pages.
- </para>
-
- <para>
- Zero-copy can be used with the following code example (a complete working
- example is provided with libkcapi):
- </para>
-
- <programlisting>
-int pipes[2];
-
-pipe(pipes);
-/* input data in iov */
-vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
-/* opfd is the file descriptor returned from accept() system call */
-splice(pipes[0], NULL, opfd, NULL, ret, 0);
-read(opfd, out, outlen);
- </programlisting>
-
- </sect1>
-
- <sect1><title>Setsockopt Interface</title>
- <para>
- In addition to the read/recv and send/write system call handling
- to send and retrieve data subject to the cipher operation, a consumer
- also needs to set the additional information for the cipher operation.
- This additional information is set using the setsockopt system call
- that must be invoked with the file descriptor of the open cipher
- (i.e. the file descriptor returned by the accept system call).
- </para>
-
- <para>
- Each setsockopt invocation must use the level SOL_ALG.
- </para>
-
- <para>
- The setsockopt interface allows setting the following data using
- the mentioned optname:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- ALG_SET_KEY -- Setting the key. Key setting is applicable to:
- </para>
- <itemizedlist>
- <listitem>
- <para>the skcipher cipher type (symmetric ciphers)</para>
- </listitem>
- <listitem>
- <para>the hash cipher type (keyed message digests)</para>
- </listitem>
- <listitem>
- <para>the AEAD cipher type</para>
- </listitem>
- <listitem>
- <para>the RNG cipher type to provide the seed</para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size
- for AEAD ciphers. For a encryption operation, the authentication
- tag of the given size will be generated. For a decryption operation,
- the provided ciphertext is assumed to contain an authentication tag
- of the given size (see section about AEAD memory layout below).
- </para>
- </listitem>
- </itemizedlist>
-
- </sect1>
-
- <sect1><title>User space API example</title>
- <para>
- Please see [1] for libkcapi which provides an easy-to-use wrapper
- around the aforementioned Netlink kernel interface. [1] also contains
- a test application that invokes all libkcapi API calls.
- </para>
-
- <para>
- [1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
- </para>
-
- </sect1>
-
- </chapter>
-
- <chapter id="API"><title>Programming Interface</title>
- <para>
- Please note that the kernel crypto API contains the AEAD givcrypt
- API (crypto_aead_giv* and aead_givcrypt_* function calls in
- include/crypto/aead.h). This API is obsolete and will be removed
- in the future. To obtain the functionality of an AEAD cipher with
- internal IV generation, use the IV generator as a regular cipher.
- For example, rfc4106(gcm(aes)) is the AEAD cipher with external
- IV generation and seqniv(rfc4106(gcm(aes))) implies that the kernel
- crypto API generates the IV. Different IV generators are available.
- </para>
- <sect1><title>Block Cipher Context Data Structures</title>
-!Pinclude/linux/crypto.h Block Cipher Context Data Structures
-!Finclude/crypto/aead.h aead_request
- </sect1>
- <sect1><title>Block Cipher Algorithm Definitions</title>
-!Pinclude/linux/crypto.h Block Cipher Algorithm Definitions
-!Finclude/linux/crypto.h crypto_alg
-!Finclude/linux/crypto.h ablkcipher_alg
-!Finclude/crypto/aead.h aead_alg
-!Finclude/linux/crypto.h blkcipher_alg
-!Finclude/linux/crypto.h cipher_alg
-!Finclude/crypto/rng.h rng_alg
- </sect1>
- <sect1><title>Symmetric Key Cipher API</title>
-!Pinclude/crypto/skcipher.h Symmetric Key Cipher API
-!Finclude/crypto/skcipher.h crypto_alloc_skcipher
-!Finclude/crypto/skcipher.h crypto_free_skcipher
-!Finclude/crypto/skcipher.h crypto_has_skcipher
-!Finclude/crypto/skcipher.h crypto_skcipher_ivsize
-!Finclude/crypto/skcipher.h crypto_skcipher_blocksize
-!Finclude/crypto/skcipher.h crypto_skcipher_setkey
-!Finclude/crypto/skcipher.h crypto_skcipher_reqtfm
-!Finclude/crypto/skcipher.h crypto_skcipher_encrypt
-!Finclude/crypto/skcipher.h crypto_skcipher_decrypt
- </sect1>
- <sect1><title>Symmetric Key Cipher Request Handle</title>
-!Pinclude/crypto/skcipher.h Symmetric Key Cipher Request Handle
-!Finclude/crypto/skcipher.h crypto_skcipher_reqsize
-!Finclude/crypto/skcipher.h skcipher_request_set_tfm
-!Finclude/crypto/skcipher.h skcipher_request_alloc
-!Finclude/crypto/skcipher.h skcipher_request_free
-!Finclude/crypto/skcipher.h skcipher_request_set_callback
-!Finclude/crypto/skcipher.h skcipher_request_set_crypt
- </sect1>
- <sect1><title>Asynchronous Block Cipher API - Deprecated</title>
-!Pinclude/linux/crypto.h Asynchronous Block Cipher API
-!Finclude/linux/crypto.h crypto_alloc_ablkcipher
-!Finclude/linux/crypto.h crypto_free_ablkcipher
-!Finclude/linux/crypto.h crypto_has_ablkcipher
-!Finclude/linux/crypto.h crypto_ablkcipher_ivsize
-!Finclude/linux/crypto.h crypto_ablkcipher_blocksize
-!Finclude/linux/crypto.h crypto_ablkcipher_setkey
-!Finclude/linux/crypto.h crypto_ablkcipher_reqtfm
-!Finclude/linux/crypto.h crypto_ablkcipher_encrypt
-!Finclude/linux/crypto.h crypto_ablkcipher_decrypt
- </sect1>
- <sect1><title>Asynchronous Cipher Request Handle - Deprecated</title>
-!Pinclude/linux/crypto.h Asynchronous Cipher Request Handle
-!Finclude/linux/crypto.h crypto_ablkcipher_reqsize
-!Finclude/linux/crypto.h ablkcipher_request_set_tfm
-!Finclude/linux/crypto.h ablkcipher_request_alloc
-!Finclude/linux/crypto.h ablkcipher_request_free
-!Finclude/linux/crypto.h ablkcipher_request_set_callback
-!Finclude/linux/crypto.h ablkcipher_request_set_crypt
- </sect1>
- <sect1><title>Authenticated Encryption With Associated Data (AEAD) Cipher API</title>
-!Pinclude/crypto/aead.h Authenticated Encryption With Associated Data (AEAD) Cipher API
-!Finclude/crypto/aead.h crypto_alloc_aead
-!Finclude/crypto/aead.h crypto_free_aead
-!Finclude/crypto/aead.h crypto_aead_ivsize
-!Finclude/crypto/aead.h crypto_aead_authsize
-!Finclude/crypto/aead.h crypto_aead_blocksize
-!Finclude/crypto/aead.h crypto_aead_setkey
-!Finclude/crypto/aead.h crypto_aead_setauthsize
-!Finclude/crypto/aead.h crypto_aead_encrypt
-!Finclude/crypto/aead.h crypto_aead_decrypt
- </sect1>
- <sect1><title>Asynchronous AEAD Request Handle</title>
-!Pinclude/crypto/aead.h Asynchronous AEAD Request Handle
-!Finclude/crypto/aead.h crypto_aead_reqsize
-!Finclude/crypto/aead.h aead_request_set_tfm
-!Finclude/crypto/aead.h aead_request_alloc
-!Finclude/crypto/aead.h aead_request_free
-!Finclude/crypto/aead.h aead_request_set_callback
-!Finclude/crypto/aead.h aead_request_set_crypt
-!Finclude/crypto/aead.h aead_request_set_ad
- </sect1>
- <sect1><title>Synchronous Block Cipher API - Deprecated</title>
-!Pinclude/linux/crypto.h Synchronous Block Cipher API
-!Finclude/linux/crypto.h crypto_alloc_blkcipher
-!Finclude/linux/crypto.h crypto_free_blkcipher
-!Finclude/linux/crypto.h crypto_has_blkcipher
-!Finclude/linux/crypto.h crypto_blkcipher_name
-!Finclude/linux/crypto.h crypto_blkcipher_ivsize
-!Finclude/linux/crypto.h crypto_blkcipher_blocksize
-!Finclude/linux/crypto.h crypto_blkcipher_setkey
-!Finclude/linux/crypto.h crypto_blkcipher_encrypt
-!Finclude/linux/crypto.h crypto_blkcipher_encrypt_iv
-!Finclude/linux/crypto.h crypto_blkcipher_decrypt
-!Finclude/linux/crypto.h crypto_blkcipher_decrypt_iv
-!Finclude/linux/crypto.h crypto_blkcipher_set_iv
-!Finclude/linux/crypto.h crypto_blkcipher_get_iv
- </sect1>
- <sect1><title>Single Block Cipher API</title>
-!Pinclude/linux/crypto.h Single Block Cipher API
-!Finclude/linux/crypto.h crypto_alloc_cipher
-!Finclude/linux/crypto.h crypto_free_cipher
-!Finclude/linux/crypto.h crypto_has_cipher
-!Finclude/linux/crypto.h crypto_cipher_blocksize
-!Finclude/linux/crypto.h crypto_cipher_setkey
-!Finclude/linux/crypto.h crypto_cipher_encrypt_one
-!Finclude/linux/crypto.h crypto_cipher_decrypt_one
- </sect1>
- <sect1><title>Message Digest Algorithm Definitions</title>
-!Pinclude/crypto/hash.h Message Digest Algorithm Definitions
-!Finclude/crypto/hash.h hash_alg_common
-!Finclude/crypto/hash.h ahash_alg
-!Finclude/crypto/hash.h shash_alg
- </sect1>
- <sect1><title>Asynchronous Message Digest API</title>
-!Pinclude/crypto/hash.h Asynchronous Message Digest API
-!Finclude/crypto/hash.h crypto_alloc_ahash
-!Finclude/crypto/hash.h crypto_free_ahash
-!Finclude/crypto/hash.h crypto_ahash_init
-!Finclude/crypto/hash.h crypto_ahash_digestsize
-!Finclude/crypto/hash.h crypto_ahash_reqtfm
-!Finclude/crypto/hash.h crypto_ahash_reqsize
-!Finclude/crypto/hash.h crypto_ahash_setkey
-!Finclude/crypto/hash.h crypto_ahash_finup
-!Finclude/crypto/hash.h crypto_ahash_final
-!Finclude/crypto/hash.h crypto_ahash_digest
-!Finclude/crypto/hash.h crypto_ahash_export
-!Finclude/crypto/hash.h crypto_ahash_import
- </sect1>
- <sect1><title>Asynchronous Hash Request Handle</title>
-!Pinclude/crypto/hash.h Asynchronous Hash Request Handle
-!Finclude/crypto/hash.h ahash_request_set_tfm
-!Finclude/crypto/hash.h ahash_request_alloc
-!Finclude/crypto/hash.h ahash_request_free
-!Finclude/crypto/hash.h ahash_request_set_callback
-!Finclude/crypto/hash.h ahash_request_set_crypt
- </sect1>
- <sect1><title>Synchronous Message Digest API</title>
-!Pinclude/crypto/hash.h Synchronous Message Digest API
-!Finclude/crypto/hash.h crypto_alloc_shash
-!Finclude/crypto/hash.h crypto_free_shash
-!Finclude/crypto/hash.h crypto_shash_blocksize
-!Finclude/crypto/hash.h crypto_shash_digestsize
-!Finclude/crypto/hash.h crypto_shash_descsize
-!Finclude/crypto/hash.h crypto_shash_setkey
-!Finclude/crypto/hash.h crypto_shash_digest
-!Finclude/crypto/hash.h crypto_shash_export
-!Finclude/crypto/hash.h crypto_shash_import
-!Finclude/crypto/hash.h crypto_shash_init
-!Finclude/crypto/hash.h crypto_shash_update
-!Finclude/crypto/hash.h crypto_shash_final
-!Finclude/crypto/hash.h crypto_shash_finup
- </sect1>
- <sect1><title>Crypto API Random Number API</title>
-!Pinclude/crypto/rng.h Random number generator API
-!Finclude/crypto/rng.h crypto_alloc_rng
-!Finclude/crypto/rng.h crypto_rng_alg
-!Finclude/crypto/rng.h crypto_free_rng
-!Finclude/crypto/rng.h crypto_rng_generate
-!Finclude/crypto/rng.h crypto_rng_get_bytes
-!Finclude/crypto/rng.h crypto_rng_reset
-!Finclude/crypto/rng.h crypto_rng_seedsize
-!Cinclude/crypto/rng.h
- </sect1>
- <sect1><title>Asymmetric Cipher API</title>
-!Pinclude/crypto/akcipher.h Generic Public Key API
-!Finclude/crypto/akcipher.h akcipher_alg
-!Finclude/crypto/akcipher.h akcipher_request
-!Finclude/crypto/akcipher.h crypto_alloc_akcipher
-!Finclude/crypto/akcipher.h crypto_free_akcipher
-!Finclude/crypto/akcipher.h crypto_akcipher_set_pub_key
-!Finclude/crypto/akcipher.h crypto_akcipher_set_priv_key
- </sect1>
- <sect1><title>Asymmetric Cipher Request Handle</title>
-!Finclude/crypto/akcipher.h akcipher_request_alloc
-!Finclude/crypto/akcipher.h akcipher_request_free
-!Finclude/crypto/akcipher.h akcipher_request_set_callback
-!Finclude/crypto/akcipher.h akcipher_request_set_crypt
-!Finclude/crypto/akcipher.h crypto_akcipher_maxsize
-!Finclude/crypto/akcipher.h crypto_akcipher_encrypt
-!Finclude/crypto/akcipher.h crypto_akcipher_decrypt
-!Finclude/crypto/akcipher.h crypto_akcipher_sign
-!Finclude/crypto/akcipher.h crypto_akcipher_verify
- </sect1>
- </chapter>
-
- <chapter id="Code"><title>Code Examples</title>
- <sect1><title>Code Example For Symmetric Key Cipher Operation</title>
- <programlisting>
-
-struct tcrypt_result {
- struct completion completion;
- int err;
-};
-
-/* tie all data structures together */
-struct skcipher_def {
- struct scatterlist sg;
- struct crypto_skcipher *tfm;
- struct skcipher_request *req;
- struct tcrypt_result result;
-};
-
-/* Callback function */
-static void test_skcipher_cb(struct crypto_async_request *req, int error)
-{
- struct tcrypt_result *result = req-&gt;data;
-
- if (error == -EINPROGRESS)
- return;
- result-&gt;err = error;
- complete(&amp;result-&gt;completion);
- pr_info("Encryption finished successfully\n");
-}
-
-/* Perform cipher operation */
-static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
- int enc)
-{
- int rc = 0;
-
- if (enc)
- rc = crypto_skcipher_encrypt(sk-&gt;req);
- else
- rc = crypto_skcipher_decrypt(sk-&gt;req);
-
- switch (rc) {
- case 0:
- break;
- case -EINPROGRESS:
- case -EBUSY:
- rc = wait_for_completion_interruptible(
- &amp;sk-&gt;result.completion);
- if (!rc &amp;&amp; !sk-&gt;result.err) {
- reinit_completion(&amp;sk-&gt;result.completion);
- break;
- }
- default:
- pr_info("skcipher encrypt returned with %d result %d\n",
- rc, sk-&gt;result.err);
- break;
- }
- init_completion(&amp;sk-&gt;result.completion);
-
- return rc;
-}
-
-/* Initialize and trigger cipher operation */
-static int test_skcipher(void)
-{
- struct skcipher_def sk;
- struct crypto_skcipher *skcipher = NULL;
- struct skcipher_request *req = NULL;
- char *scratchpad = NULL;
- char *ivdata = NULL;
- unsigned char key[32];
- int ret = -EFAULT;
-
- skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0);
- if (IS_ERR(skcipher)) {
- pr_info("could not allocate skcipher handle\n");
- return PTR_ERR(skcipher);
- }
-
- req = skcipher_request_alloc(skcipher, GFP_KERNEL);
- if (!req) {
- pr_info("could not allocate skcipher request\n");
- ret = -ENOMEM;
- goto out;
- }
-
- skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- test_skcipher_cb,
- &amp;sk.result);
-
- /* AES 256 with random key */
- get_random_bytes(&amp;key, 32);
- if (crypto_skcipher_setkey(skcipher, key, 32)) {
- pr_info("key could not be set\n");
- ret = -EAGAIN;
- goto out;
- }
-
- /* IV will be random */
- ivdata = kmalloc(16, GFP_KERNEL);
- if (!ivdata) {
- pr_info("could not allocate ivdata\n");
- goto out;
- }
- get_random_bytes(ivdata, 16);
-
- /* Input data will be random */
- scratchpad = kmalloc(16, GFP_KERNEL);
- if (!scratchpad) {
- pr_info("could not allocate scratchpad\n");
- goto out;
- }
- get_random_bytes(scratchpad, 16);
-
- sk.tfm = skcipher;
- sk.req = req;
-
- /* We encrypt one block */
- sg_init_one(&amp;sk.sg, scratchpad, 16);
- skcipher_request_set_crypt(req, &amp;sk.sg, &amp;sk.sg, 16, ivdata);
- init_completion(&amp;sk.result.completion);
-
- /* encrypt data */
- ret = test_skcipher_encdec(&amp;sk, 1);
- if (ret)
- goto out;
-
- pr_info("Encryption triggered successfully\n");
-
-out:
- if (skcipher)
- crypto_free_skcipher(skcipher);
- if (req)
- skcipher_request_free(req);
- if (ivdata)
- kfree(ivdata);
- if (scratchpad)
- kfree(scratchpad);
- return ret;
-}
- </programlisting>
- </sect1>
-
- <sect1><title>Code Example For Use of Operational State Memory With SHASH</title>
- <programlisting>
-
-struct sdesc {
- struct shash_desc shash;
- char ctx[];
-};
-
-static struct sdescinit_sdesc(struct crypto_shash *alg)
-{
- struct sdescsdesc;
- int size;
-
- size = sizeof(struct shash_desc) + crypto_shash_descsize(alg);
- sdesc = kmalloc(size, GFP_KERNEL);
- if (!sdesc)
- return ERR_PTR(-ENOMEM);
- sdesc-&gt;shash.tfm = alg;
- sdesc-&gt;shash.flags = 0x0;
- return sdesc;
-}
-
-static int calc_hash(struct crypto_shashalg,
- const unsigned chardata, unsigned int datalen,
- unsigned chardigest) {
- struct sdescsdesc;
- int ret;
-
- sdesc = init_sdesc(alg);
- if (IS_ERR(sdesc)) {
- pr_info("trusted_key: can't alloc %s\n", hash_alg);
- return PTR_ERR(sdesc);
- }
-
- ret = crypto_shash_digest(&amp;sdesc-&gt;shash, data, datalen, digest);
- kfree(sdesc);
- return ret;
-}
- </programlisting>
- </sect1>
-
- <sect1><title>Code Example For Random Number Generator Usage</title>
- <programlisting>
-
-static int get_random_numbers(u8 *buf, unsigned int len)
-{
- struct crypto_rngrng = NULL;
- chardrbg = "drbg_nopr_sha256"; /* Hash DRBG with SHA-256, no PR */
- int ret;
-
- if (!buf || !len) {
- pr_debug("No output buffer provided\n");
- return -EINVAL;
- }
-
- rng = crypto_alloc_rng(drbg, 0, 0);
- if (IS_ERR(rng)) {
- pr_debug("could not allocate RNG handle for %s\n", drbg);
- return -PTR_ERR(rng);
- }
-
- ret = crypto_rng_get_bytes(rng, buf, len);
- if (ret &lt; 0)
- pr_debug("generation of random numbers failed\n");
- else if (ret == 0)
- pr_debug("RNG returned no data");
- else
- pr_debug("RNG returned %d bytes of data\n", ret);
-
-out:
- crypto_free_rng(rng);
- return ret;
-}
- </programlisting>
- </sect1>
- </chapter>
- </book>
diff --git a/Documentation/crypto/api-aead.rst b/Documentation/crypto/api-aead.rst
new file mode 100644
index 000000000000..d15256f1ae36
--- /dev/null
+++ b/Documentation/crypto/api-aead.rst
@@ -0,0 +1,23 @@
+Authenticated Encryption With Associated Data (AEAD) Algorithm Definitions
+--------------------------------------------------------------------------
+
+.. kernel-doc:: include/crypto/aead.h
+ :doc: Authenticated Encryption With Associated Data (AEAD) Cipher API
+
+.. kernel-doc:: include/crypto/aead.h
+ :functions: aead_request aead_alg
+
+Authenticated Encryption With Associated Data (AEAD) Cipher API
+---------------------------------------------------------------
+
+.. kernel-doc:: include/crypto/aead.h
+ :functions: crypto_alloc_aead crypto_free_aead crypto_aead_ivsize crypto_aead_authsize crypto_aead_blocksize crypto_aead_setkey crypto_aead_setauthsize crypto_aead_encrypt crypto_aead_decrypt
+
+Asynchronous AEAD Request Handle
+--------------------------------
+
+.. kernel-doc:: include/crypto/aead.h
+ :doc: Asynchronous AEAD Request Handle
+
+.. kernel-doc:: include/crypto/aead.h
+ :functions: crypto_aead_reqsize aead_request_set_tfm aead_request_alloc aead_request_free aead_request_set_callback aead_request_set_crypt aead_request_set_ad
diff --git a/Documentation/crypto/api-akcipher.rst b/Documentation/crypto/api-akcipher.rst
new file mode 100644
index 000000000000..40aa8746e2a1
--- /dev/null
+++ b/Documentation/crypto/api-akcipher.rst
@@ -0,0 +1,20 @@
+Asymmetric Cipher Algorithm Definitions
+---------------------------------------
+
+.. kernel-doc:: include/crypto/akcipher.h
+ :functions: akcipher_alg akcipher_request
+
+Asymmetric Cipher API
+---------------------
+
+.. kernel-doc:: include/crypto/akcipher.h
+ :doc: Generic Public Key API
+
+.. kernel-doc:: include/crypto/akcipher.h
+ :functions: crypto_alloc_akcipher crypto_free_akcipher crypto_akcipher_set_pub_key crypto_akcipher_set_priv_key crypto_akcipher_maxsize crypto_akcipher_encrypt crypto_akcipher_decrypt crypto_akcipher_sign crypto_akcipher_verify
+
+Asymmetric Cipher Request Handle
+--------------------------------
+
+.. kernel-doc:: include/crypto/akcipher.h
+ :functions: akcipher_request_alloc akcipher_request_free akcipher_request_set_callback akcipher_request_set_crypt
diff --git a/Documentation/crypto/api-digest.rst b/Documentation/crypto/api-digest.rst
new file mode 100644
index 000000000000..07356fa99200
--- /dev/null
+++ b/Documentation/crypto/api-digest.rst
@@ -0,0 +1,35 @@
+Message Digest Algorithm Definitions
+------------------------------------
+
+.. kernel-doc:: include/crypto/hash.h
+ :doc: Message Digest Algorithm Definitions
+
+.. kernel-doc:: include/crypto/hash.h
+ :functions: hash_alg_common ahash_alg shash_alg
+
+Asynchronous Message Digest API
+-------------------------------
+
+.. kernel-doc:: include/crypto/hash.h
+ :doc: Asynchronous Message Digest API
+
+.. kernel-doc:: include/crypto/hash.h
+ :functions: crypto_alloc_ahash crypto_free_ahash crypto_ahash_init crypto_ahash_digestsize crypto_ahash_reqtfm crypto_ahash_reqsize crypto_ahash_setkey crypto_ahash_finup crypto_ahash_final crypto_ahash_digest crypto_ahash_export crypto_ahash_import
+
+Asynchronous Hash Request Handle
+--------------------------------
+
+.. kernel-doc:: include/crypto/hash.h
+ :doc: Asynchronous Hash Request Handle
+
+.. kernel-doc:: include/crypto/hash.h
+ :functions: ahash_request_set_tfm ahash_request_alloc ahash_request_free ahash_request_set_callback ahash_request_set_crypt
+
+Synchronous Message Digest API
+------------------------------
+
+.. kernel-doc:: include/crypto/hash.h
+ :doc: Synchronous Message Digest API
+
+.. kernel-doc:: include/crypto/hash.h
+ :functions: crypto_alloc_shash crypto_free_shash crypto_shash_blocksize crypto_shash_digestsize crypto_shash_descsize crypto_shash_setkey crypto_shash_digest crypto_shash_export crypto_shash_import crypto_shash_init crypto_shash_update crypto_shash_final crypto_shash_finup
diff --git a/Documentation/crypto/api-kpp.rst b/Documentation/crypto/api-kpp.rst
new file mode 100644
index 000000000000..7d86ab906bdf
--- /dev/null
+++ b/Documentation/crypto/api-kpp.rst
@@ -0,0 +1,38 @@
+Key-agreement Protocol Primitives (KPP) Cipher Algorithm Definitions
+--------------------------------------------------------------------
+
+.. kernel-doc:: include/crypto/kpp.h
+ :functions: kpp_request crypto_kpp kpp_alg kpp_secret
+
+Key-agreement Protocol Primitives (KPP) Cipher API
+--------------------------------------------------
+
+.. kernel-doc:: include/crypto/kpp.h
+ :doc: Generic Key-agreement Protocol Primitives API
+
+.. kernel-doc:: include/crypto/kpp.h
+ :functions: crypto_alloc_kpp crypto_free_kpp crypto_kpp_set_secret crypto_kpp_generate_public_key crypto_kpp_compute_shared_secret crypto_kpp_maxsize
+
+Key-agreement Protocol Primitives (KPP) Cipher Request Handle
+-------------------------------------------------------------
+
+.. kernel-doc:: include/crypto/kpp.h
+ :functions: kpp_request_alloc kpp_request_free kpp_request_set_callback kpp_request_set_input kpp_request_set_output
+
+ECDH Helper Functions
+---------------------
+
+.. kernel-doc:: include/crypto/ecdh.h
+ :doc: ECDH Helper Functions
+
+.. kernel-doc:: include/crypto/ecdh.h
+ :functions: ecdh crypto_ecdh_key_len crypto_ecdh_encode_key crypto_ecdh_decode_key
+
+DH Helper Functions
+-------------------
+
+.. kernel-doc:: include/crypto/dh.h
+ :doc: DH Helper Functions
+
+.. kernel-doc:: include/crypto/dh.h
+ :functions: dh crypto_dh_key_len crypto_dh_encode_key crypto_dh_decode_key
diff --git a/Documentation/crypto/api-rng.rst b/Documentation/crypto/api-rng.rst
new file mode 100644
index 000000000000..10ba7436cee4
--- /dev/null
+++ b/Documentation/crypto/api-rng.rst
@@ -0,0 +1,14 @@
+Random Number Algorithm Definitions
+-----------------------------------
+
+.. kernel-doc:: include/crypto/rng.h
+ :functions: rng_alg
+
+Crypto API Random Number API
+----------------------------
+
+.. kernel-doc:: include/crypto/rng.h
+ :doc: Random number generator API
+
+.. kernel-doc:: include/crypto/rng.h
+ :functions: crypto_alloc_rng crypto_rng_alg crypto_free_rng crypto_rng_generate crypto_rng_get_bytes crypto_rng_reset crypto_rng_seedsize
diff --git a/Documentation/crypto/api-samples.rst b/Documentation/crypto/api-samples.rst
new file mode 100644
index 000000000000..0a10819f6107
--- /dev/null
+++ b/Documentation/crypto/api-samples.rst
@@ -0,0 +1,224 @@
+Code Examples
+=============
+
+Code Example For Symmetric Key Cipher Operation
+-----------------------------------------------
+
+::
+
+
+ struct tcrypt_result {
+ struct completion completion;
+ int err;
+ };
+
+ /* tie all data structures together */
+ struct skcipher_def {
+ struct scatterlist sg;
+ struct crypto_skcipher *tfm;
+ struct skcipher_request *req;
+ struct tcrypt_result result;
+ };
+
+ /* Callback function */
+ static void test_skcipher_cb(struct crypto_async_request *req, int error)
+ {
+ struct tcrypt_result *result = req->data;
+
+ if (error == -EINPROGRESS)
+ return;
+ result->err = error;
+ complete(&result->completion);
+ pr_info("Encryption finished successfully\n");
+ }
+
+ /* Perform cipher operation */
+ static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
+ int enc)
+ {
+ int rc = 0;
+
+ if (enc)
+ rc = crypto_skcipher_encrypt(sk->req);
+ else
+ rc = crypto_skcipher_decrypt(sk->req);
+
+ switch (rc) {
+ case 0:
+ break;
+ case -EINPROGRESS:
+ case -EBUSY:
+ rc = wait_for_completion_interruptible(
+ &sk->result.completion);
+ if (!rc && !sk->result.err) {
+ reinit_completion(&sk->result.completion);
+ break;
+ }
+ default:
+ pr_info("skcipher encrypt returned with %d result %d\n",
+ rc, sk->result.err);
+ break;
+ }
+ init_completion(&sk->result.completion);
+
+ return rc;
+ }
+
+ /* Initialize and trigger cipher operation */
+ static int test_skcipher(void)
+ {
+ struct skcipher_def sk;
+ struct crypto_skcipher *skcipher = NULL;
+ struct skcipher_request *req = NULL;
+ char *scratchpad = NULL;
+ char *ivdata = NULL;
+ unsigned char key[32];
+ int ret = -EFAULT;
+
+ skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0);
+ if (IS_ERR(skcipher)) {
+ pr_info("could not allocate skcipher handle\n");
+ return PTR_ERR(skcipher);
+ }
+
+ req = skcipher_request_alloc(skcipher, GFP_KERNEL);
+ if (!req) {
+ pr_info("could not allocate skcipher request\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+ test_skcipher_cb,
+ &sk.result);
+
+ /* AES 256 with random key */
+ get_random_bytes(&key, 32);
+ if (crypto_skcipher_setkey(skcipher, key, 32)) {
+ pr_info("key could not be set\n");
+ ret = -EAGAIN;
+ goto out;
+ }
+
+ /* IV will be random */
+ ivdata = kmalloc(16, GFP_KERNEL);
+ if (!ivdata) {
+ pr_info("could not allocate ivdata\n");
+ goto out;
+ }
+ get_random_bytes(ivdata, 16);
+
+ /* Input data will be random */
+ scratchpad = kmalloc(16, GFP_KERNEL);
+ if (!scratchpad) {
+ pr_info("could not allocate scratchpad\n");
+ goto out;
+ }
+ get_random_bytes(scratchpad, 16);
+
+ sk.tfm = skcipher;
+ sk.req = req;
+
+ /* We encrypt one block */
+ sg_init_one(&sk.sg, scratchpad, 16);
+ skcipher_request_set_crypt(req, &sk.sg, &sk.sg, 16, ivdata);
+ init_completion(&sk.result.completion);
+
+ /* encrypt data */
+ ret = test_skcipher_encdec(&sk, 1);
+ if (ret)
+ goto out;
+
+ pr_info("Encryption triggered successfully\n");
+
+ out:
+ if (skcipher)
+ crypto_free_skcipher(skcipher);
+ if (req)
+ skcipher_request_free(req);
+ if (ivdata)
+ kfree(ivdata);
+ if (scratchpad)
+ kfree(scratchpad);
+ return ret;
+ }
+
+
+Code Example For Use of Operational State Memory With SHASH
+-----------------------------------------------------------
+
+::
+
+
+ struct sdesc {
+ struct shash_desc shash;
+ char ctx[];
+ };
+
+ static struct sdescinit_sdesc(struct crypto_shash *alg)
+ {
+ struct sdescsdesc;
+ int size;
+
+ size = sizeof(struct shash_desc) + crypto_shash_descsize(alg);
+ sdesc = kmalloc(size, GFP_KERNEL);
+ if (!sdesc)
+ return ERR_PTR(-ENOMEM);
+ sdesc->shash.tfm = alg;
+ sdesc->shash.flags = 0x0;
+ return sdesc;
+ }
+
+ static int calc_hash(struct crypto_shashalg,
+ const unsigned chardata, unsigned int datalen,
+ unsigned chardigest) {
+ struct sdescsdesc;
+ int ret;
+
+ sdesc = init_sdesc(alg);
+ if (IS_ERR(sdesc)) {
+ pr_info("trusted_key: can't alloc %s\n", hash_alg);
+ return PTR_ERR(sdesc);
+ }
+
+ ret = crypto_shash_digest(&sdesc->shash, data, datalen, digest);
+ kfree(sdesc);
+ return ret;
+ }
+
+
+Code Example For Random Number Generator Usage
+----------------------------------------------
+
+::
+
+
+ static int get_random_numbers(u8 *buf, unsigned int len)
+ {
+ struct crypto_rngrng = NULL;
+ chardrbg = "drbg_nopr_sha256"; /* Hash DRBG with SHA-256, no PR */
+ int ret;
+
+ if (!buf || !len) {
+ pr_debug("No output buffer provided\n");
+ return -EINVAL;
+ }
+
+ rng = crypto_alloc_rng(drbg, 0, 0);
+ if (IS_ERR(rng)) {
+ pr_debug("could not allocate RNG handle for %s\n", drbg);
+ return -PTR_ERR(rng);
+ }
+
+ ret = crypto_rng_get_bytes(rng, buf, len);
+ if (ret < 0)
+ pr_debug("generation of random numbers failed\n");
+ else if (ret == 0)
+ pr_debug("RNG returned no data");
+ else
+ pr_debug("RNG returned %d bytes of data\n", ret);
+
+ out:
+ crypto_free_rng(rng);
+ return ret;
+ }
diff --git a/Documentation/crypto/api-skcipher.rst b/Documentation/crypto/api-skcipher.rst
new file mode 100644
index 000000000000..b20028a361a9
--- /dev/null
+++ b/Documentation/crypto/api-skcipher.rst
@@ -0,0 +1,62 @@
+Block Cipher Algorithm Definitions
+----------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+ :doc: Block Cipher Algorithm Definitions
+
+.. kernel-doc:: include/linux/crypto.h
+ :functions: crypto_alg ablkcipher_alg blkcipher_alg cipher_alg
+
+Symmetric Key Cipher API
+------------------------
+
+.. kernel-doc:: include/crypto/skcipher.h
+ :doc: Symmetric Key Cipher API
+
+.. kernel-doc:: include/crypto/skcipher.h
+ :functions: crypto_alloc_skcipher crypto_free_skcipher crypto_has_skcipher crypto_skcipher_ivsize crypto_skcipher_blocksize crypto_skcipher_setkey crypto_skcipher_reqtfm crypto_skcipher_encrypt crypto_skcipher_decrypt
+
+Symmetric Key Cipher Request Handle
+-----------------------------------
+
+.. kernel-doc:: include/crypto/skcipher.h
+ :doc: Symmetric Key Cipher Request Handle
+
+.. kernel-doc:: include/crypto/skcipher.h
+ :functions: crypto_skcipher_reqsize skcipher_request_set_tfm skcipher_request_alloc skcipher_request_free skcipher_request_set_callback skcipher_request_set_crypt
+
+Single Block Cipher API
+-----------------------
+
+.. kernel-doc:: include/linux/crypto.h
+ :doc: Single Block Cipher API
+
+.. kernel-doc:: include/linux/crypto.h
+ :functions: crypto_alloc_cipher crypto_free_cipher crypto_has_cipher crypto_cipher_blocksize crypto_cipher_setkey crypto_cipher_encrypt_one crypto_cipher_decrypt_one
+
+Asynchronous Block Cipher API - Deprecated
+------------------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+ :doc: Asynchronous Block Cipher API
+
+.. kernel-doc:: include/linux/crypto.h
+ :functions: crypto_free_ablkcipher crypto_has_ablkcipher crypto_ablkcipher_ivsize crypto_ablkcipher_blocksize crypto_ablkcipher_setkey crypto_ablkcipher_reqtfm crypto_ablkcipher_encrypt crypto_ablkcipher_decrypt
+
+Asynchronous Cipher Request Handle - Deprecated
+-----------------------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+ :doc: Asynchronous Cipher Request Handle
+
+.. kernel-doc:: include/linux/crypto.h
+ :functions: crypto_ablkcipher_reqsize ablkcipher_request_set_tfm ablkcipher_request_alloc ablkcipher_request_free ablkcipher_request_set_callback ablkcipher_request_set_crypt
+
+Synchronous Block Cipher API - Deprecated
+-----------------------------------------
+
+.. kernel-doc:: include/linux/crypto.h
+ :doc: Synchronous Block Cipher API
+
+.. kernel-doc:: include/linux/crypto.h
+ :functions: crypto_alloc_blkcipher rypto_free_blkcipher crypto_has_blkcipher crypto_blkcipher_name crypto_blkcipher_ivsize crypto_blkcipher_blocksize crypto_blkcipher_setkey crypto_blkcipher_encrypt crypto_blkcipher_encrypt_iv crypto_blkcipher_decrypt crypto_blkcipher_decrypt_iv crypto_blkcipher_set_iv crypto_blkcipher_get_iv
diff --git a/Documentation/crypto/api.rst b/Documentation/crypto/api.rst
new file mode 100644
index 000000000000..2e519193ab4a
--- /dev/null
+++ b/Documentation/crypto/api.rst
@@ -0,0 +1,25 @@
+Programming Interface
+=====================
+
+Please note that the kernel crypto API contains the AEAD givcrypt API
+(crypto_aead_giv\* and aead_givcrypt\* function calls in
+include/crypto/aead.h). This API is obsolete and will be removed in the
+future. To obtain the functionality of an AEAD cipher with internal IV
+generation, use the IV generator as a regular cipher. For example,
+rfc4106(gcm(aes)) is the AEAD cipher with external IV generation and
+seqniv(rfc4106(gcm(aes))) implies that the kernel crypto API generates
+the IV. Different IV generators are available.
+
+.. class:: toc-title
+
+ Table of contents
+
+.. toctree::
+ :maxdepth: 2
+
+ api-skcipher
+ api-aead
+ api-digest
+ api-rng
+ api-akcipher
+ api-kpp
diff --git a/Documentation/crypto/architecture.rst b/Documentation/crypto/architecture.rst
new file mode 100644
index 000000000000..ca2d09b991f5
--- /dev/null
+++ b/Documentation/crypto/architecture.rst
@@ -0,0 +1,441 @@
+Kernel Crypto API Architecture
+==============================
+
+Cipher algorithm types
+----------------------
+
+The kernel crypto API provides different API calls for the following
+cipher types:
+
+- Symmetric ciphers
+
+- AEAD ciphers
+
+- Message digest, including keyed message digest
+
+- Random number generation
+
+- User space interface
+
+Ciphers And Templates
+---------------------
+
+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.
+
+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.
+
+A single block cipher may even be called with multiple templates.
+However, templates cannot be used without a single cipher.
+
+See /proc/crypto and search for "name". For example:
+
+- aes
+
+- ecb(aes)
+
+- cmac(aes)
+
+- ccm(aes)
+
+- rfc4106(gcm(aes))
+
+- sha1
+
+- hmac(sha1)
+
+- authenc(hmac(sha1),cbc(aes))
+
+In these examples, "aes" and "sha1" are the ciphers and all others are
+the templates.
+
+Synchronous And Asynchronous Operation
+--------------------------------------
+
+The kernel crypto API provides synchronous and asynchronous API
+operations.
+
+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.
+
+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.
+
+Crypto API Cipher References And Priority
+-----------------------------------------
+
+A cipher is referenced by the caller with a string. That string has the
+following semantics:
+
+::
+
+ template(single block cipher)
+
+
+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
+
+::
+
+ template1(template2(single block cipher)))
+
+
+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.
+
+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.
+
+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:
+
+- 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)
+
+- driver: the unique name of the cipher -- this name can be used by the
+ cipher allocation API calls
+
+- module: the kernel module providing the cipher implementation (or
+ "kernel" for statically linked ciphers)
+
+- priority: the priority value of the cipher implementation
+
+- refcnt: the reference count of the respective cipher (i.e. the number
+ of current consumers of this cipher)
+
+- selftest: specification whether the self test for the cipher passed
+
+- type:
+
+ - skcipher for symmetric key ciphers
+
+ - cipher for single block ciphers that may be used with an
+ additional template
+
+ - shash for synchronous message digest
+
+ - ahash for asynchronous message digest
+
+ - aead for AEAD cipher type
+
+ - compression for compression type transformations
+
+ - rng for random number generator
+
+ - 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)
+
+ - kpp for a Key-agreement Protocol Primitive (KPP) cipher such as
+ an ECDH or DH implementation
+
+- blocksize: blocksize of cipher in bytes
+
+- keysize: key size in bytes
+
+- ivsize: IV size in bytes
+
+- seedsize: required size of seed data for random number generator
+
+- digestsize: output size of the message digest
+
+- geniv: IV generation type:
+
+ - eseqiv for encrypted sequence number based IV generation
+
+ - seqiv for sequence number based IV generation
+
+ - chainiv for chain iv generation
+
+ - <builtin> is a marker that the cipher implements IV generation and
+ handling as it is specific to the given cipher
+
+Key Sizes
+---------
+
+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.
+
+Cipher Allocation Type And Masks
+--------------------------------
+
+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).
+
+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:
+
+- CRYPTO_ALG_TYPE_CIPHER Single block cipher
+
+- CRYPTO_ALG_TYPE_COMPRESS Compression
+
+- CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data
+ (MAC)
+
+- CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher
+
+- CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher
+
+- 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)
+
+- CRYPTO_ALG_TYPE_KPP Key-agreement Protocol Primitive (KPP) such as
+ an ECDH or DH implementation
+
+- CRYPTO_ALG_TYPE_DIGEST Raw message digest
+
+- CRYPTO_ALG_TYPE_HASH Alias for CRYPTO_ALG_TYPE_DIGEST
+
+- CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash
+
+- CRYPTO_ALG_TYPE_AHASH Asynchronous multi-block hash
+
+- CRYPTO_ALG_TYPE_RNG Random Number Generation
+
+- CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher
+
+- 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.
+
+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.
+
+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.
+
+Internal Structure of Kernel Crypto API
+---------------------------------------
+
+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.
+
+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.
+
+Generic AEAD Cipher Structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+The blocks below indicate the cipher type as well as the specific logic
+implemented in the cipher.
+
+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.
+
+::
+
+
+ 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) |
+ +-----------+
+
+
+
+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:
+
+1. esp_output() invokes crypto_aead_encrypt() to trigger an
+ encryption operation of the AEAD cipher with IV generator.
+
+ In case of GCM, the SEQIV implementation is registered as GIVCIPHER
+ in crypto_rfc4106_alloc().
+
+ The SEQIV performs its operation to generate an IV where the core
+ function is seqiv_geniv().
+
+2. 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.
+
+ 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.
+
+ The GCM implementation is responsible to invoke the CTR mode AES and
+ the GHASH cipher in the right manner to implement the GCM
+ specification.
+
+3. The GCM AEAD cipher type implementation now invokes the SKCIPHER API
+ with the instantiated CTR(AES) cipher handle.
+
+ During instantiation of the CTR(AES) cipher, the CIPHER type
+ implementation of AES is instantiated. The cipher handle for AES is
+ retained.
+
+ 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.
+
+4. The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
+ cipher handle to encrypt one block.
+
+5. The GCM AEAD implementation also invokes the GHASH cipher
+ implementation via the AHASH API.
+
+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).
+
+Generic Block Cipher Structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Generic block ciphers follow the same concept as depicted with the ASCII
+art picture above.
+
+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.
+
+Generic Keyed Message Digest Structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Keyed message digest implementations again follow the same concept as
+depicted in the ASCII art picture above.
+
+For example, HMAC(SHA256) is implemented with hmac.c and
+sha256_generic.c. The following ASCII art illustrates the
+implementation:
+
+::
+
+
+ kernel crypto API | Caller
+ |
+ +-----------+ (1) |
+ | | <------------------ some_function
+ | ahash |
+ | (hmac) | ---+
+ +-----------+ |
+ | (2)
+ +-----------+ |
+ | | <--+
+ | shash |
+ | (sha256) |
+ +-----------+
+
+
+
+The following call sequence is applicable when a caller triggers an HMAC
+operation:
+
+1. The AHASH API functions are invoked by the caller. The HMAC
+ implementation performs its operation as needed.
+
+ During initialization of the HMAC cipher, the SHASH cipher type of
+ SHA256 is instantiated. The cipher handle for the SHA256 instance is
+ retained.
+
+ At one time, the HMAC implementation requires a SHA256 operation
+ where the SHA256 cipher handle is used.
+
+2. The HMAC instance now invokes the SHASH API with the SHA256 cipher
+ handle to calculate the message digest.
diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst
new file mode 100644
index 000000000000..66f50d32dcec
--- /dev/null
+++ b/Documentation/crypto/devel-algos.rst
@@ -0,0 +1,247 @@
+Developing Cipher Algorithms
+============================
+
+Registering And Unregistering Transformation
+--------------------------------------------
+
+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.
+
+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.
+
+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.
+
+::
+
+ int crypto_register_alg(struct crypto_alg *alg);
+ int crypto_register_algs(struct crypto_alg *algs, int count);
+
+
+The counterparts to those functions are listed below.
+
+::
+
+ int crypto_unregister_alg(struct crypto_alg *alg);
+ int crypto_unregister_algs(struct crypto_alg *algs, int count);
+
+
+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.
+
+The bulk registration/unregistration functions register/unregister each
+transformation in the given array of length count. They handle errors as
+follows:
+
+- 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.
+
+- crypto_unregister_algs() tries to unregister all the given
+ transformations, continuing on error. It logs errors and always
+ returns zero.
+
+Single-Block Symmetric Ciphers [CIPHER]
+---------------------------------------
+
+Example of transformations: aes, arc4, ...
+
+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.
+
+Registration specifics
+~~~~~~~~~~~~~~~~~~~~~~
+
+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.
+
+See struct cipher_alg below.
+
+Cipher Definition With struct cipher_alg
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Struct cipher_alg defines a single block cipher.
+
+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.
+
+::
+
+ KEY ---. PLAINTEXT ---.
+ v v
+ .cia_setkey() -> .cia_encrypt()
+ |
+ '-----> CIPHERTEXT
+
+
+Please note that a pattern where .cia_setkey() is called multiple times
+is also valid:
+
+::
+
+
+ KEY1 --. PLAINTEXT1 --. KEY2 --. PLAINTEXT2 --.
+ v v v v
+ .cia_setkey() -> .cia_encrypt() -> .cia_setkey() -> .cia_encrypt()
+ | |
+ '---> CIPHERTEXT1 '---> CIPHERTEXT2
+
+
+Multi-Block Ciphers
+-------------------
+
+Example of transformations: cbc(aes), ecb(arc4), ...
+
+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.
+
+Registration Specifics
+~~~~~~~~~~~~~~~~~~~~~~
+
+The registration of multi-block cipher algorithms is one of the most
+standard procedures throughout the crypto API.
+
+Note, if a cipher implementation requires a proper alignment of data,
+the caller should use the functions of crypto_skcipher_alignmask() to
+identify a memory alignment mask. The kernel crypto API is able to
+process requests that are unaligned. This implies, however, additional
+overhead as the kernel crypto API needs to perform the realignment of
+the data which may imply moving of data.
+
+Cipher Definition With struct blkcipher_alg and ablkcipher_alg
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Struct blkcipher_alg defines a synchronous block cipher whereas struct
+ablkcipher_alg defines an asynchronous block cipher.
+
+Please refer to the single block cipher description for schematics of
+the block cipher usage.
+
+Specifics Of Asynchronous Multi-Block Cipher
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are a couple of specifics to the asynchronous interface.
+
+First of all, some of the drivers will want to use the Generic
+ScatterWalk in case the hardware needs to be fed separate chunks of the
+scatterlist which contains the plaintext and will contain the
+ciphertext. Please refer to the ScatterWalk interface offered by the
+Linux kernel scatter / gather list implementation.
+
+Hashing [HASH]
+--------------
+
+Example of transformations: crc32, md5, sha1, sha256,...
+
+Registering And Unregistering The Transformation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are multiple ways to register a HASH transformation, depending on
+whether the transformation is synchronous [SHASH] or asynchronous
+[AHASH] and the amount of HASH transformations we are registering. You
+can find the prototypes defined in include/crypto/internal/hash.h:
+
+::
+
+ int crypto_register_ahash(struct ahash_alg *alg);
+
+ int crypto_register_shash(struct shash_alg *alg);
+ int crypto_register_shashes(struct shash_alg *algs, int count);
+
+
+The respective counterparts for unregistering the HASH transformation
+are as follows:
+
+::
+
+ int crypto_unregister_ahash(struct ahash_alg *alg);
+
+ int crypto_unregister_shash(struct shash_alg *alg);
+ int crypto_unregister_shashes(struct shash_alg *algs, int count);
+
+
+Cipher Definition With struct shash_alg and ahash_alg
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here are schematics of how these functions are called when operated from
+other part of the kernel. Note that the .setkey() call might happen
+before or after any of these schematics happen, but must not happen
+during any of these are in-flight. Please note that calling .init()
+followed immediately by .finish() is also a perfectly valid
+transformation.
+
+::
+
+ I) DATA -----------.
+ v
+ .init() -> .update() -> .final() ! .update() might not be called
+ ^ | | at all in this scenario.
+ '----' '---> HASH
+
+ II) DATA -----------.-----------.
+ v v
+ .init() -> .update() -> .finup() ! .update() may not be called
+ ^ | | at all in this scenario.
+ '----' '---> HASH
+
+ III) DATA -----------.
+ v
+ .digest() ! The entire process is handled
+ | by the .digest() call.
+ '---------------> HASH
+
+
+Here is a schematic of how the .export()/.import() functions are called
+when used from another part of the kernel.
+
+::
+
+ KEY--. DATA--.
+ v v ! .update() may not be called
+ .setkey() -> .init() -> .update() -> .export() at all in this scenario.
+ ^ | |
+ '-----' '--> PARTIAL_HASH
+
+ ----------- other transformations happen here -----------
+
+ PARTIAL_HASH--. DATA1--.
+ v v
+ .import -> .update() -> .final() ! .update() may not be called
+ ^ | | at all in this scenario.
+ '----' '--> HASH1
+
+ PARTIAL_HASH--. DATA2-.
+ v v
+ .import -> .finup()
+ |
+ '---------------> HASH2
+
+
+Specifics Of Asynchronous HASH Transformation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some of the drivers will want to use the Generic ScatterWalk in case the
+implementation needs to be fed separate chunks of the scatterlist which
+contains the input data. The buffer containing the resulting hash will
+always be properly aligned to .cra_alignmask so there is no need to
+worry about this.
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
new file mode 100644
index 000000000000..94c4786f2573
--- /dev/null
+++ b/Documentation/crypto/index.rst
@@ -0,0 +1,24 @@
+=======================
+Linux Kernel Crypto API
+=======================
+
+:Author: Stephan Mueller
+:Author: Marek Vasut
+
+This documentation outlines the Linux kernel crypto API with its
+concepts, details about developing cipher implementations, employment of the API
+for cryptographic use cases, as well as programming examples.
+
+.. class:: toc-title
+
+ Table of contents
+
+.. toctree::
+ :maxdepth: 2
+
+ intro
+ architecture
+ devel-algos
+ userspace-if
+ api
+ api-samples
diff --git a/Documentation/crypto/intro.rst b/Documentation/crypto/intro.rst
new file mode 100644
index 000000000000..9aa89ebbfba9
--- /dev/null
+++ b/Documentation/crypto/intro.rst
@@ -0,0 +1,74 @@
+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.
diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
new file mode 100644
index 000000000000..de5a72e32bc9
--- /dev/null
+++ b/Documentation/crypto/userspace-if.rst
@@ -0,0 +1,387 @@
+User Space Interface
+====================
+
+Introduction
+------------
+
+The concepts of the kernel crypto API visible to kernel space is fully
+applicable to the user space interface as well. Therefore, the kernel
+crypto API high level discussion for the in-kernel use cases applies
+here as well.
+
+The major difference, however, is that user space can only act as a
+consumer and never as a provider of a transformation or cipher
+algorithm.
+
+The following covers the user space interface exported by the kernel
+crypto API. A working example of this description is libkcapi that can
+be obtained from [1]. That library can be used by user space
+applications that require cryptographic services from the kernel.
+
+Some details of the in-kernel kernel crypto API aspects do not apply to
+user space, however. This includes the difference between synchronous
+and asynchronous invocations. The user space API call is fully
+synchronous.
+
+[1] http://www.chronox.de/libkcapi.html
+
+User Space API General Remarks
+------------------------------
+
+The kernel crypto API is accessible from user space. Currently, the
+following ciphers are accessible:
+
+- Message digest including keyed message digest (HMAC, CMAC)
+
+- Symmetric ciphers
+
+- AEAD ciphers
+
+- Random Number Generators
+
+The interface is provided via socket type using the type AF_ALG. In
+addition, the setsockopt option type is SOL_ALG. In case the user space
+header files do not export these flags yet, use the following macros:
+
+::
+
+ #ifndef AF_ALG
+ #define AF_ALG 38
+ #endif
+ #ifndef SOL_ALG
+ #define SOL_ALG 279
+ #endif
+
+
+A cipher is accessed with the same name as done for the in-kernel API
+calls. This includes the generic vs. unique naming schema for ciphers as
+well as the enforcement of priorities for generic names.
+
+To interact with the kernel crypto API, a socket must be created by the
+user space application. User space invokes the cipher operation with the
+send()/write() system call family. The result of the cipher operation is
+obtained with the read()/recv() system call family.
+
+The following API calls assume that the socket descriptor is already
+opened by the user space application and discusses only the kernel
+crypto API specific invocations.
+
+To initialize the socket interface, the following sequence has to be
+performed by the consumer:
+
+1. Create a socket of type AF_ALG with the struct sockaddr_alg
+ parameter specified below for the different cipher types.
+
+2. Invoke bind with the socket descriptor
+
+3. Invoke accept with the socket descriptor. The accept system call
+ returns a new file descriptor that is to be used to interact with the
+ particular cipher instance. When invoking send/write or recv/read
+ system calls to send data to the kernel or obtain data from the
+ kernel, the file descriptor returned by accept must be used.
+
+In-place Cipher operation
+-------------------------
+
+Just like the in-kernel operation of the kernel crypto API, the user
+space interface allows the cipher operation in-place. That means that
+the input buffer used for the send/write system call and the output
+buffer used by the read/recv system call may be one and the same. This
+is of particular interest for symmetric cipher operations where a
+copying of the output data to its final destination can be avoided.
+
+If a consumer on the other hand wants to maintain the plaintext and the
+ciphertext in different memory locations, all a consumer needs to do is
+to provide different memory pointers for the encryption and decryption
+operation.
+
+Message Digest API
+------------------
+
+The message digest type to be used for the cipher operation is selected
+when invoking the bind syscall. bind requires the caller to provide a
+filled struct sockaddr data structure. This data structure must be
+filled as follows:
+
+::
+
+ struct sockaddr_alg sa = {
+ .salg_family = AF_ALG,
+ .salg_type = "hash", /* this selects the hash logic in the kernel */
+ .salg_name = "sha1" /* this is the cipher name */
+ };
+
+
+The salg_type value "hash" applies to message digests and keyed message
+digests. Though, a keyed message digest is referenced by the appropriate
+salg_name. Please see below for the setsockopt interface that explains
+how the key can be set for a keyed message digest.
+
+Using the send() system call, the application provides the data that
+should be processed with the message digest. The send system call allows
+the following flags to be specified:
+
+- MSG_MORE: If this flag is set, the send system call acts like a
+ message digest update function where the final hash is not yet
+ calculated. If the flag is not set, the send system call calculates
+ the final message digest immediately.
+
+With the recv() system call, the application can read the message digest
+from the kernel crypto API. If the buffer is too small for the message
+digest, the flag MSG_TRUNC is set by the kernel.
+
+In order to set a message digest key, the calling application must use
+the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC
+operation is performed without the initial HMAC state change caused by
+the key.
+
+Symmetric Cipher API
+--------------------
+
+The operation is very similar to the message digest discussion. During
+initialization, the struct sockaddr data structure must be filled as
+follows:
+
+::
+
+ struct sockaddr_alg sa = {
+ .salg_family = AF_ALG,
+ .salg_type = "skcipher", /* this selects the symmetric cipher */
+ .salg_name = "cbc(aes)" /* this is the cipher name */
+ };
+
+
+Before data can be sent to the kernel using the write/send system call
+family, the consumer must set the key. The key setting is described with
+the setsockopt invocation below.
+
+Using the sendmsg() system call, the application provides the data that
+should be processed for encryption or decryption. In addition, the IV is
+specified with the data structure provided by the sendmsg() system call.
+
+The sendmsg system call parameter of struct msghdr is embedded into the
+struct cmsghdr data structure. See recv(2) and cmsg(3) for more
+information on how the cmsghdr data structure is used together with the
+send/recv system call family. That cmsghdr data structure holds the
+following information specified with a separate header instances:
+
+- specification of the cipher operation type with one of these flags:
+
+ - ALG_OP_ENCRYPT - encryption of data
+
+ - ALG_OP_DECRYPT - decryption of data
+
+- specification of the IV information marked with the flag ALG_SET_IV
+
+The send system call family allows the following flag to be specified:
+
+- MSG_MORE: If this flag is set, the send system call acts like a
+ cipher update function where more input data is expected with a
+ subsequent invocation of the send system call.
+
+Note: The kernel reports -EINVAL for any unexpected data. The caller
+must make sure that all data matches the constraints given in
+/proc/crypto for the selected cipher.
+
+With the recv() system call, the application can read the result of the
+cipher operation from the kernel crypto API. The output buffer must be
+at least as large as to hold all blocks of the encrypted or decrypted
+data. If the output data size is smaller, only as many blocks are
+returned that fit into that output buffer size.
+
+AEAD Cipher API
+---------------
+
+The operation is very similar to the symmetric cipher discussion. During
+initialization, the struct sockaddr data structure must be filled as
+follows:
+
+::
+
+ struct sockaddr_alg sa = {
+ .salg_family = AF_ALG,
+ .salg_type = "aead", /* this selects the symmetric cipher */
+ .salg_name = "gcm(aes)" /* this is the cipher name */
+ };
+
+
+Before data can be sent to the kernel using the write/send system call
+family, the consumer must set the key. The key setting is described with
+the setsockopt invocation below.
+
+In addition, before data can be sent to the kernel using the write/send
+system call family, the consumer must set the authentication tag size.
+To set the authentication tag size, the caller must use the setsockopt
+invocation described below.
+
+Using the sendmsg() system call, the application provides the data that
+should be processed for encryption or decryption. In addition, the IV is
+specified with the data structure provided by the sendmsg() system call.
+
+The sendmsg system call parameter of struct msghdr is embedded into the
+struct cmsghdr data structure. See recv(2) and cmsg(3) for more
+information on how the cmsghdr data structure is used together with the
+send/recv system call family. That cmsghdr data structure holds the
+following information specified with a separate header instances:
+
+- specification of the cipher operation type with one of these flags:
+
+ - ALG_OP_ENCRYPT - encryption of data
+
+ - ALG_OP_DECRYPT - decryption of data
+
+- specification of the IV information marked with the flag ALG_SET_IV
+
+- specification of the associated authentication data (AAD) with the
+ flag ALG_SET_AEAD_ASSOCLEN. The AAD is sent to the kernel together
+ with the plaintext / ciphertext. See below for the memory structure.
+
+The send system call family allows the following flag to be specified:
+
+- MSG_MORE: If this flag is set, the send system call acts like a
+ cipher update function where more input data is expected with a
+ subsequent invocation of the send system call.
+
+Note: The kernel reports -EINVAL for any unexpected data. The caller
+must make sure that all data matches the constraints given in
+/proc/crypto for the selected cipher.
+
+With the recv() system call, the application can read the result of the
+cipher operation from the kernel crypto API. The output buffer must be
+at least as large as defined with the memory structure below. If the
+output data size is smaller, the cipher operation is not performed.
+
+The authenticated decryption operation may indicate an integrity error.
+Such breach in integrity is marked with the -EBADMSG error code.
+
+AEAD Memory Structure
+~~~~~~~~~~~~~~~~~~~~~
+
+The AEAD cipher operates with the following information that is
+communicated between user and kernel space as one data stream:
+
+- plaintext or ciphertext
+
+- associated authentication data (AAD)
+
+- authentication tag
+
+The sizes of the AAD and the authentication tag are provided with the
+sendmsg and setsockopt calls (see there). As the kernel knows the size
+of the entire data stream, the kernel is now able to calculate the right
+offsets of the data components in the data stream.
+
+The user space caller must arrange the aforementioned information in the
+following order:
+
+- AEAD encryption input: AAD \|\| plaintext
+
+- AEAD decryption input: AAD \|\| ciphertext \|\| authentication tag
+
+The output buffer the user space caller provides must be at least as
+large to hold the following data:
+
+- AEAD encryption output: ciphertext \|\| authentication tag
+
+- AEAD decryption output: plaintext
+
+Random Number Generator API
+---------------------------
+
+Again, the operation is very similar to the other APIs. During
+initialization, the struct sockaddr data structure must be filled as
+follows:
+
+::
+
+ struct sockaddr_alg sa = {
+ .salg_family = AF_ALG,
+ .salg_type = "rng", /* this selects the symmetric cipher */
+ .salg_name = "drbg_nopr_sha256" /* this is the cipher name */
+ };
+
+
+Depending on the RNG type, the RNG must be seeded. The seed is provided
+using the setsockopt interface to set the key. For example, the
+ansi_cprng requires a seed. The DRBGs do not require a seed, but may be
+seeded.
+
+Using the read()/recvmsg() system calls, random numbers can be obtained.
+The kernel generates at most 128 bytes in one call. If user space
+requires more data, multiple calls to read()/recvmsg() must be made.
+
+WARNING: The user space caller may invoke the initially mentioned accept
+system call multiple times. In this case, the returned file descriptors
+have the same state.
+
+Zero-Copy Interface
+-------------------
+
+In addition to the send/write/read/recv system call family, the AF_ALG
+interface can be accessed with the zero-copy interface of
+splice/vmsplice. As the name indicates, the kernel tries to avoid a copy
+operation into kernel space.
+
+The zero-copy operation requires data to be aligned at the page
+boundary. Non-aligned data can be used as well, but may require more
+operations of the kernel which would defeat the speed gains obtained
+from the zero-copy interface.
+
+The system-interent limit for the size of one zero-copy operation is 16
+pages. If more data is to be sent to AF_ALG, user space must slice the
+input into segments with a maximum size of 16 pages.
+
+Zero-copy can be used with the following code example (a complete
+working example is provided with libkcapi):
+
+::
+
+ int pipes[2];
+
+ pipe(pipes);
+ /* input data in iov */
+ vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
+ /* opfd is the file descriptor returned from accept() system call */
+ splice(pipes[0], NULL, opfd, NULL, ret, 0);
+ read(opfd, out, outlen);
+
+
+Setsockopt Interface
+--------------------
+
+In addition to the read/recv and send/write system call handling to send
+and retrieve data subject to the cipher operation, a consumer also needs
+to set the additional information for the cipher operation. This
+additional information is set using the setsockopt system call that must
+be invoked with the file descriptor of the open cipher (i.e. the file
+descriptor returned by the accept system call).
+
+Each setsockopt invocation must use the level SOL_ALG.
+
+The setsockopt interface allows setting the following data using the
+mentioned optname:
+
+- ALG_SET_KEY -- Setting the key. Key setting is applicable to:
+
+ - the skcipher cipher type (symmetric ciphers)
+
+ - the hash cipher type (keyed message digests)
+
+ - the AEAD cipher type
+
+ - the RNG cipher type to provide the seed
+
+- ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size for
+ AEAD ciphers. For a encryption operation, the authentication tag of
+ the given size will be generated. For a decryption operation, the
+ provided ciphertext is assumed to contain an authentication tag of
+ the given size (see section about AEAD memory layout below).
+
+User space API example
+----------------------
+
+Please see [1] for libkcapi which provides an easy-to-use wrapper around
+the aforementioned Netlink kernel interface. [1] also contains a test
+application that invokes all libkcapi API calls.
+
+[1] http://www.chronox.de/libkcapi.html
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 2bd8fdc9207c..cb5d77699c60 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -58,6 +58,7 @@ needed).
gpu/index
security/index
sound/index
+ crypto/index
Korean translations
-------------------
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 668ef402c6eb..f849311e9fd4 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -556,18 +556,8 @@ static int aead_recvmsg_sync(struct socket *sock, struct msghdr *msg, int flags)
lock_sock(sk);
/*
- * AEAD memory structure: For encryption, the tag is appended to the
- * ciphertext which implies that the memory allocated for the ciphertext
- * must be increased by the tag length. For decryption, the tag
- * is expected to be concatenated to the ciphertext. The plaintext
- * therefore has a memory size of the ciphertext minus the tag length.
- *
- * The memory structure for cipher operation has the following
- * structure:
- * AEAD encryption input: assoc data || plaintext
- * AEAD encryption output: cipherntext || auth tag
- * AEAD decryption input: assoc data || ciphertext || auth tag
- * AEAD decryption output: plaintext
+ * Please see documentation of aead_request_set_crypt for the
+ * description of the AEAD memory structure expected from the caller.
*/
if (ctx->more) {
diff --git a/include/crypto/aead.h b/include/crypto/aead.h
index 12f84327ca36..03b97629442c 100644
--- a/include/crypto/aead.h
+++ b/include/crypto/aead.h
@@ -55,14 +55,14 @@
* The scatter list pointing to the input data must contain:
*
* * for RFC4106 ciphers, the concatenation of
- * associated authentication data || IV || plaintext or ciphertext. Note, the
- * same IV (buffer) is also set with the aead_request_set_crypt call. Note,
- * the API call of aead_request_set_ad must provide the length of the AAD and
- * the IV. The API call of aead_request_set_crypt only points to the size of
- * the input plaintext or ciphertext.
+ * associated authentication data || IV || plaintext or ciphertext. Note, the
+ * same IV (buffer) is also set with the aead_request_set_crypt call. Note,
+ * the API call of aead_request_set_ad must provide the length of the AAD and
+ * the IV. The API call of aead_request_set_crypt only points to the size of
+ * the input plaintext or ciphertext.
*
* * for "normal" AEAD ciphers, the concatenation of
- * associated authentication data || plaintext or ciphertext.
+ * associated authentication data || plaintext or ciphertext.
*
* It is important to note that if multiple scatter gather list entries form
* the input data mentioned above, the first entry must not point to a NULL
@@ -452,7 +452,7 @@ static inline void aead_request_free(struct aead_request *req)
* completes
*
* The callback function is registered with the aead_request handle and
- * must comply with the following template
+ * must comply with the following template::
*
* void callback_function(struct crypto_async_request *req, int error)
*/
@@ -483,30 +483,18 @@ static inline void aead_request_set_callback(struct aead_request *req,
* destination is the ciphertext. For a decryption operation, the use is
* reversed - the source is the ciphertext and the destination is the plaintext.
*
- * For both src/dst the layout is associated data, plain/cipher text,
- * authentication tag.
- *
- * The content of the AD in the destination buffer after processing
- * will either be untouched, or it will contain a copy of the AD
- * from the source buffer. In order to ensure that it always has
- * a copy of the AD, the user must copy the AD over either before
- * or after processing. Of course this is not relevant if the user
- * is doing in-place processing where src == dst.
- *
- * IMPORTANT NOTE AEAD requires an authentication tag (MAC). For decryption,
- * the caller must concatenate the ciphertext followed by the
- * authentication tag and provide the entire data stream to the
- * decryption operation (i.e. the data length used for the
- * initialization of the scatterlist and the data length for the
- * decryption operation is identical). For encryption, however,
- * the authentication tag is created while encrypting the data.
- * The destination buffer must hold sufficient space for the
- * ciphertext and the authentication tag while the encryption
- * invocation must only point to the plaintext data size. The
- * following code snippet illustrates the memory usage
- * buffer = kmalloc(ptbuflen + (enc ? authsize : 0));
- * sg_init_one(&sg, buffer, ptbuflen + (enc ? authsize : 0));
- * aead_request_set_crypt(req, &sg, &sg, ptbuflen, iv);
+ * The memory structure for cipher operation has the following structure:
+ *
+ * - AEAD encryption input: assoc data || plaintext
+ * - AEAD encryption output: assoc data || cipherntext || auth tag
+ * - AEAD decryption input: assoc data || ciphertext || auth tag
+ * - AEAD decryption output: assoc data || plaintext
+ *
+ * Albeit the kernel requires the presence of the AAD buffer, however,
+ * the kernel does not fill the AAD buffer in the output case. If the
+ * caller wants to have that data buffer filled, the caller must either
+ * use an in-place cipher operation (i.e. same memory location for
+ * input/output memory location).
*/
static inline void aead_request_set_crypt(struct aead_request *req,
struct scatterlist *src,
diff --git a/include/crypto/dh.h b/include/crypto/dh.h
index 5102a8f282e6..6b424ad3482e 100644
--- a/include/crypto/dh.h
+++ b/include/crypto/dh.h
@@ -13,6 +13,27 @@
#ifndef _CRYPTO_DH_
#define _CRYPTO_DH_
+/**
+ * DOC: DH Helper Functions
+ *
+ * To use DH with the KPP cipher API, the following data structure and
+ * functions should be used.
+ *
+ * To use DH with KPP, the following functions should be used to operate on
+ * a DH private key. The packet private key that can be set with
+ * the KPP API function call of crypto_kpp_set_secret.
+ */
+
+/**
+ * struct dh - define a DH private key
+ *
+ * @key: Private DH key
+ * @p: Diffie-Hellman parameter P
+ * @g: Diffie-Hellman generator G
+ * @key_size: Size of the private DH key
+ * @p_size: Size of DH parameter P
+ * @g_size: Size of DH generator G
+ */
struct dh {
void *key;
void *p;
@@ -22,8 +43,45 @@ struct dh {
unsigned int g_size;
};
+/**
+ * crypto_dh_key_len() - Obtain the size of the private DH key
+ * @params: private DH key
+ *
+ * This function returns the packet DH key size. A caller can use that
+ * with the provided DH private key reference to obtain the required
+ * memory size to hold a packet key.
+ *
+ * Return: size of the key in bytes
+ */
int crypto_dh_key_len(const struct dh *params);
+
+/**
+ * crypto_dh_encode_key() - encode the private key
+ * @buf: Buffer allocated by the caller to hold the packet DH
+ * private key. The buffer should be at least crypto_dh_key_len
+ * bytes in size.
+ * @len: Length of the packet private key buffer
+ * @params: Buffer with the caller-specified private key
+ *
+ * The DH implementations operate on a packet representation of the private
+ * key.
+ *
+ * Return: -EINVAL if buffer has insufficient size, 0 on success
+ */
int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params);
+
+/**
+ * crypto_dh_decode_key() - decode a private key
+ * @buf: Buffer holding a packet key that should be decoded
+ * @len: Lenth of the packet private key buffer
+ * @params: Buffer allocated by the caller that is filled with the
+ * unpacket DH private key.
+ *
+ * The unpacking obtains the private key by pointing @p to the correct location
+ * in @buf. Thus, both pointers refer to the same memory.
+ *
+ * Return: -EINVAL if buffer has insufficient size, 0 on success
+ */
int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh *params);
#endif
diff --git a/include/crypto/ecdh.h b/include/crypto/ecdh.h
index 84bad548d194..03a64f62ba7a 100644
--- a/include/crypto/ecdh.h
+++ b/include/crypto/ecdh.h
@@ -13,18 +13,76 @@
#ifndef _CRYPTO_ECDH_
#define _CRYPTO_ECDH_
+/**
+ * DOC: ECDH Helper Functions
+ *
+ * To use ECDH with the KPP cipher API, the following data structure and
+ * functions should be used.
+ *
+ * The ECC curves known to the ECDH implementation are specified in this
+ * header file.
+ *
+ * To use ECDH with KPP, the following functions should be used to operate on
+ * an ECDH private key. The packet private key that can be set with
+ * the KPP API function call of crypto_kpp_set_secret.
+ */
+
/* Curves IDs */
#define ECC_CURVE_NIST_P192 0x0001
#define ECC_CURVE_NIST_P256 0x0002
+/**
+ * struct ecdh - define an ECDH private key
+ *
+ * @curve_id: ECC curve the key is based on.
+ * @key: Private ECDH key
+ * @key_size: Size of the private ECDH key
+ */
struct ecdh {
unsigned short curve_id;
char *key;
unsigned short key_size;
};
+/**
+ * crypto_ecdh_key_len() - Obtain the size of the private ECDH key
+ * @params: private ECDH key
+ *
+ * This function returns the packet ECDH key size. A caller can use that
+ * with the provided ECDH private key reference to obtain the required
+ * memory size to hold a packet key.
+ *
+ * Return: size of the key in bytes
+ */
int crypto_ecdh_key_len(const struct ecdh *params);
+
+/**
+ * crypto_ecdh_encode_key() - encode the private key
+ * @buf: Buffer allocated by the caller to hold the packet ECDH
+ * private key. The buffer should be at least crypto_ecdh_key_len
+ * bytes in size.
+ * @len: Length of the packet private key buffer
+ * @p: Buffer with the caller-specified private key
+ *
+ * The ECDH implementations operate on a packet representation of the private
+ * key.
+ *
+ * Return: -EINVAL if buffer has insufficient size, 0 on success
+ */
int crypto_ecdh_encode_key(char *buf, unsigned int len, const struct ecdh *p);
+
+/**
+ * crypto_ecdh_decode_key() - decode a private key
+ * @buf: Buffer holding a packet key that should be decoded
+ * @len: Lenth of the packet private key buffer
+ * @p: Buffer allocated by the caller that is filled with the
+ * unpacket ECDH private key.
+ *
+ * The unpacking obtains the private key by pointing @p to the correct location
+ * in @buf. Thus, both pointers refer to the same memory.
+ *
+ * Return: -EINVAL if buffer has insufficient size, 0 on success
+ */
int crypto_ecdh_decode_key(const char *buf, unsigned int len, struct ecdh *p);
#endif
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index 26605888a199..216a2b876147 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -605,7 +605,7 @@ static inline struct ahash_request *ahash_request_cast(
* the cipher operation completes.
*
* The callback function is registered with the &ahash_request handle and
- * must comply with the following template
+ * must comply with the following template::
*
* void callback_function(struct crypto_async_request *req, int error)
*/
diff --git a/include/crypto/kpp.h b/include/crypto/kpp.h
index 30791f75c180..4307a2f2365f 100644
--- a/include/crypto/kpp.h
+++ b/include/crypto/kpp.h
@@ -71,7 +71,7 @@ struct crypto_kpp {
*
* @reqsize: Request context size required by algorithm
* implementation
- * @base Common crypto API algorithm data structure
+ * @base: Common crypto API algorithm data structure
*/
struct kpp_alg {
int (*set_secret)(struct crypto_kpp *tfm, void *buffer,
@@ -89,7 +89,7 @@ struct kpp_alg {
};
/**
- * DOC: Generic Key-agreement Protocol Primitevs API
+ * DOC: Generic Key-agreement Protocol Primitives API
*
* The KPP API is used with the algorithm type
* CRYPTO_ALG_TYPE_KPP (listed as type "kpp" in /proc/crypto)
@@ -264,6 +264,12 @@ struct kpp_secret {
* Function invokes the specific kpp operation for a given alg.
*
* @tfm: tfm handle
+ * @buffer: Buffer holding the packet representation of the private
+ * key. The structure of the packet key depends on the particular
+ * KPP implementation. Packing and unpacking helpers are provided
+ * for ECDH and DH (see the respective header files for those
+ * implementations).
+ * @len: Length of the packet private key buffer.
*
* Return: zero on success; error code in case of error
*/
@@ -279,7 +285,10 @@ static inline int crypto_kpp_set_secret(struct crypto_kpp *tfm, void *buffer,
* crypto_kpp_generate_public_key() - Invoke kpp operation
*
* Function invokes the specific kpp operation for generating the public part
- * for a given kpp algorithm
+ * for a given kpp algorithm.
+ *
+ * To generate a private key, the caller should use a random number generator.
+ * The output of the requested length serves as the private key.
*
* @req: kpp key request
*
diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index cc4d98a7892e..750b14f1ada4 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -516,7 +516,7 @@ static inline void skcipher_request_zero(struct skcipher_request *req)
* skcipher_request_set_callback() - set asynchronous callback function
* @req: request handle
* @flags: specify zero or an ORing of the flags
- * CRYPTO_TFM_REQ_MAY_BACKLOG the request queue may back log and
+ * CRYPTO_TFM_REQ_MAY_BACKLOG the request queue may back log and
* increase the wait queue beyond the initial maximum size;
* CRYPTO_TFM_REQ_MAY_SLEEP the request processing may sleep
* @compl: callback function pointer to be registered with the request handle
@@ -533,7 +533,7 @@ static inline void skcipher_request_zero(struct skcipher_request *req)
* cipher operation completes.
*
* The callback function is registered with the skcipher_request handle and
- * must comply with the following template
+ * must comply with the following template::
*
* void callback_function(struct crypto_async_request *req, int error)
*/
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 167aea29d41e..c0b0cf3d2d2f 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -963,7 +963,7 @@ static inline void ablkcipher_request_free(struct ablkcipher_request *req)
* ablkcipher_request_set_callback() - set asynchronous callback function
* @req: request handle
* @flags: specify zero or an ORing of the flags
- * CRYPTO_TFM_REQ_MAY_BACKLOG the request queue may back log and
+ * CRYPTO_TFM_REQ_MAY_BACKLOG the request queue may back log and
* increase the wait queue beyond the initial maximum size;
* CRYPTO_TFM_REQ_MAY_SLEEP the request processing may sleep
* @compl: callback function pointer to be registered with the request handle
@@ -980,7 +980,7 @@ static inline void ablkcipher_request_free(struct ablkcipher_request *req)
* cipher operation completes.
*
* The callback function is registered with the ablkcipher_request handle and
- * must comply with the following template
+ * must comply with the following template::
*
* void callback_function(struct crypto_async_request *req, int error)
*/