The author of this manual page is Angelos D. Keromytis (angelos@cis.upenn.edu)
Copyright (c) 2000, 2001 Angelos D. Keromytis
Permission to use, copy, and modify this software with or without fee
is hereby granted, provided that this entire notice is included in
all source code copies of any software which is or includes a copy or
modification of this software.
THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR
IMPLIED WARRANTY. IN PARTICULAR, NONE OF THE AUTHORS MAKES ANY
REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
PURPOSE.
$FreeBSD$
.Dd May 11, 2020 .Dt CRYPTO 9 .Os .Sh NAME .Nm crypto .Nd API for cryptographic services in the kernel .Sh SYNOPSIS n opencrypto/cryptodev.h .Sh DESCRIPTION .Nm is a framework for in-kernel cryptography. It permits in-kernel consumers to encrypt and decrypt data and also enables userland applications to use cryptographic hardware through the
p .Nm supports two modes of operation: one mode for symmetric-keyed cryptographic requests and digest, and a second mode for asymmetric-key requests and modular arithmetic. .Ss Symmetric-Key Mode Symmetric-key operations include encryption and decryption operations using block and stream ciphers as well as computation and verification of message authentication codes (MACs). In this mode, consumers allocate sessions to describe a transform as discussed in .Xr crypto_session 9 . Consumers then allocate request objects to describe each transformation such as encrypting a network packet or decrypting a disk sector. Requests are described in .Xr crypto_request 9 .
p Device drivers are responsible for processing requests submitted by consumers. .Xr crypto_driver 9 describes the interfaces drivers use to register with the framework, helper routines the framework provides to faciliate request processing, and the interfaces drivers are required to provide. .Ss Asymmetric-Key Mode Assymteric-key operations do not use sessions. Instead, these operations perform individual mathematical operations using a set of input and output parameters. These operations are described in .Xr crypto_asym 9 . Drivers that support asymmetric operations use additional interfaces described in .Xr crypto_asym 9 in addition to the base interfaces described in .Xr crypto_driver 9 . .Ss Callbacks Since the consumers may not be associated with a process, drivers may not .Xr sleep 9 . The same holds for the framework. Thus, a callback mechanism is used to notify a consumer that a request has been completed (the callback is specified by the consumer on a per-request basis). The callback is invoked by the framework whether the request was successfully completed or not. Errors are reported to the callback function.
p Session initialization does not use callbacks and returns errors synchronously. .Ss Session Migration For symmetric-key operations, a specific error code, .Er EAGAIN , is used to indicate that a session handle has changed and that the request may be re-submitted immediately with the new session. The consumer should update its saved copy of the session handle to the value of .Fa crp_session so that future requests use the new session. .Ss Supported Algorithms More details on some algorithms may be found in .Xr crypto 7 . These algorithms are used for symmetric-mode operations. Asymmetric-mode operations support operations described in .Xr crypto_asym 9 .
p The following authentication algorithms are supported:
p l -tag -offset indent -width CRYPTO_AES_CCM_CBC_MAC -compact t Dv CRYPTO_AES_CCM_CBC_MAC t Dv CRYPTO_AES_NIST_GMAC t Dv CRYPTO_BLAKE2B t Dv CRYPTO_BLAKE2S t Dv CRYPTO_NULL_HMAC t Dv CRYPTO_POLY1305 t Dv CRYPTO_RIPEMD160 t Dv CRYPTO_RIPEMD160_HMAC t Dv CRYPTO_SHA1 t Dv CRYPTO_SHA1_HMAC t Dv CRYPTO_SHA2_224 t Dv CRYPTO_SHA2_224_HMAC t Dv CRYPTO_SHA2_256 t Dv CRYPTO_SHA2_256_HMAC t Dv CRYPTO_SHA2_384 t Dv CRYPTO_SHA2_384_HMAC t Dv CRYPTO_SHA2_512 t Dv CRYPTO_SHA2_512_HMAC .El
p The following encryption algorithms are supported:
p l -tag -offset indent -width CRYPTO_CAMELLIA_CBC -compact t Dv CRYPTO_AES_CBC t Dv CRYPTO_AES_ICM t Dv CRYPTO_AES_XTS t Dv CRYPTO_CAMELLIA_CBC t Dv CRYPTO_CHACHA20 t Dv CRYPTO_NULL_CBC .El
p The following authenticated encryption with additional data (AEAD) algorithms are supported:
p l -tag -offset indent -width CRYPTO_AES_NIST_GCM_16 -compact t Dv CRYPTO_AES_CCM_16 t Dv CRYPTO_AES_NIST_GCM_16 .El
p The following compression algorithms are supported:
p l -tag -offset indent -width CRYPTO_DEFLATE_COMP -compact t Dv CRYPTO_DEFLATE_COMP .El .Sh FILES l -tag -width ".Pa sys/opencrypto/crypto.c" t Pa sys/opencrypto/crypto.c most of the framework code .El .Sh SEE ALSO .Xr crypto 4 , .Xr ipsec 4 , .Xr crypto 7 , .Xr crypto_asym 9 , .Xr crypto_driver 9 , .Xr crypto_request 9 , .Xr crypto_session 9 , .Xr sleep 9 .Sh HISTORY The cryptographic framework first appeared in .Ox 2.7 and was written by .An Angelos D. Keromytis Aq Mt angelos@openbsd.org . .Sh BUGS The framework needs a mechanism for determining which driver is best for a specific set of algorithms associated with a session. Some type of benchmarking is in order here.