Commit 0aaf2146 authored by Linus Torvalds's avatar Linus Torvalds

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
parents 59331c21 3fa71d0f
......@@ -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),)
......
This diff is collapsed.
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
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
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
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
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
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;
}
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
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
This diff is collapsed.
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.
=======================
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
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.
This diff is collapsed.
......@@ -58,6 +58,7 @@ needed).
gpu/index
security/index
sound/index
crypto/index
Korean translations
-------------------
......
......@@ -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) {
......
......@@ -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,
......
......@@ -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
......@@ -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
......@@ -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)
*/
......
......@@ -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
*
......
......@@ -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)
*/
......
......@@ -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)
*/
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment