p .Cd pseudo-device crypto
p n sys/ioctl.h n sys/time.h n crypto/cryptodev.h .Sh DESCRIPTION The .Nm driver gives user-mode applications access to hardware-accelerated cryptographic transforms, as implemented by the .Xr opencrypto 9 in-kernel interface. The
a /dev/crypto special device provides an .Xr ioctl 2 based interface. User-mode applications should open the special device, then issue .Xr ioctl 2 calls on the descriptor. The .Nm device provides two distinct modes of operation: one mode for symmetric-keyed cryptographic requests, and a second mode for both asymmetric-key (public-key/private-key) requests, and for modular exponentiation (for Diffie-Hellman key exchange). The two modes are described separately below. .Sh SYMMETRIC-KEY OPERATION The symmetric-key operation mode provides a context-based API to traditional symmetric-key encryption (or privacy) algorithms, or to keyed and unkeyed one-way hash (HMAC and MAC) algorithms. The symmetric-key mode also permits fused operation, where the hardware performs both a privacy algorithm and an integrity-check algorithm in a single pass over the data: either a fused encrypt/HMAC-generate operation, or a fused HMAC-verify/decrypt operation.
p
To use symmetric mode, you must first create a session specifying
the algorithm(s) and key(s) to use; then issue encrypt or decrypt
requests against the session.
.Ss Symmetric-key privacy algorithms
Contingent upon device drivers for installed cryptographic hardware
registering with
.Xr opencrypto 9 ,
as providers of a given algorithm, some or all of the following
symmetric-key privacy algorithms may be available:
l -tag -compact -width CRYPTO_RIPEMD160_HMAC -offset indent t CRYPTO_DES_CBC t CRYPTO_3DES_CBC t CRYPTO_BLF_CBC t CRYPTO_CAST_CBC t CRYPTO_SKIPJACK_CBC t CRYPTO_AES_CBC t CRYPTO_ARC4 .El
.Ss Integrity-check operations
Contingent upon hardware support, some or all of the following
keyed one-way hash algorithms may be available:
l -tag -compact -width CRYPTO_RIPEMD160_HMAC -offset indent t CRYPTO_RIPEMD160_HMAC t CRYPTO_MD5_KPDK t CRYPTO_SHA1_KPDK t CRYPTO_MD5_HMAC t CRYPTO_SHA1_HMAC t CRYPTO_SHA2_HMAC t CRYPTO_MD5 t CRYPTO_SHA1 .El
The
.Em CRYPTO_MD5
and
.Em CRYPTO_SHA1
algorithms are actually unkeyed, but should be requested
as symmetric-key hash algorithms with a zero-length key.
.Ss IOCTL Request Descriptions
l -tag -width CIOCFKEY
t Dv CRIOCGET Fa int *fd Clone the fd argument to
.Xr ioctl 4 ,
yielding a new file descriptor which can be used to create
crypto sessions and request crypto operations.
t Dv CRIOCGSESSION Fa struct session_op *sessp Persistently bind a file descriptor returned by a previous
.Dv CRIOCGET
to a session: that is, to the chosen privacy algorithm, integrity
algorithm, and keys specified in
.Fa sessp .
The special value 0 for either privacy or integrity
is reserved to indicate that the indicated operation (privacy or integrity)
is not desired for this session.
p For non-zero symmetric-key privacy algorithms, the privacy algorithm must be specified in .Fa sess-\*[Gt]cipher , the key length in .Fa sessp-\*[Gt]keylen , and the key value in the octets addressed by .Fa sessp-\*[Gt]key .
p
For keyed one-way hash algorithms, the one-way hash must be specified
in
.Fa sessp-\*[Gt]mac ,
the key length in
.Fa sessp-\*[Gt]mackey ,
and the key value in the octets addressed by
.Fa sessp-\*[Gt]mackeylen .
p
Support for a specific combination of fused privacy and
integrity-check algorithms depends on whether the underlying
hardware supports that combination.
Not all combinations are supported
by all hardware, even if the hardware supports each operation as a
stand-alone non-fused operation.
t Dv CIOCCRYPT Fa struct crpyto_op *cr_op Request a symmetric-key (or unkeyed hash) operation.
The file descriptor argument to
.Xr ioctl 4
must have been bound to a valid session.
To encrypt, set
.Fa cr_op-\*[Gt]op
to
.Dv COP_ENCRYPT .
To decrypt, set
.Fa cr_op-\*[Gt]op
to
.Dv COP_DECRYPT .
The field
.Fa cr_op-\*[Gt]len
supplies the length of the input buffer; the fields
.Fa cr_op-\*[Gt]src ,
.Fa cr_op-\*[Gt]dst ,
.Fa cr_op-\*[Gt]mac ,
.Fa cr_op-\*[Gt]iv
supply the addresses of the input buffer, output buffer,
one-way hash, and initialization vector, respectively.
t Dv CIOCFSESSION Fa void Destroys the /dev/crypto session associated with the file-descriptor
argument.
.El
.Sh ASYMMETRIC-KEY OPERATION
.Ss Asymmetric-key algorithms
Contingent upon hardware support, the following asymmetric
(public-key/private-key; or key-exchange subroutine) operations may
also be available:
l -column "CRK_DH_COMPUTE_KEY" "Input parameter" "Output parameter" -offset indent -compact t Em "Algorithm" Ta "Input parameter" Ta "Output parameter" t Em " " Ta "Count" Ta "Count" t Dv CRK_MOD_EXP Ta 3 Ta 1 t Dv CRK_MOD_EXP_CRT Ta 6 Ta 1 t Dv CRK_DSA_SIGN Ta 5 Ta 2 t Dv CRK_DSA_VERIFY Ta 7 Ta 0 t Dv CRK_DH_COMPUTE_KEY Ta 3 Ta 1 .El
p See below for discussion of the input and output parameter counts. .Ss Asymmetric-key commands l -tag -width CIOCFKEY t Dv CIOCASSYMFEAT Fa int *feature_mask Returns a bitmask of supported asymmetric-key operations. Each of the above-listed asymmetric operations is present if and only if the bit position numbered by the code for that operation is set. For example, .Dv CRK_MOD_EXP is available if and only if the bit
q 1 \*[Lt]\*[Lt] Dv CRK_MOD_EX is set. t Dv CIOCFKEY Fa struct crypt_kop *kop Performs an asymmetric-key operation from the list above. The specific operation is supplied in .Fa kop-\*[Gt]crk_op ; final status for the operation is returned in .Fa kop-\*[Gt]crk_status . The number of input arguments and the number of output arguments is specified in .Fa kop-\*[Gt]crk_iparams and .Fa kop-\*[Gt]crk_iparams , respectively. The field .Fa crk_param[] must be filled in with exactly .Fa kop-\*[Gt]crk_iparams + kop-\*[Gt]crk_oparams arguments, each encoded as a .Fa struct crparam (address, bitlength) pair. .El
p
The semantics of these arguments are currently undocumented.
.Sh SEE ALSO
.Xr hifn 4 ,
.Xr ubsec 4 ,
.Xr opencrypto 9
.Sh HISTORY
The
.Nm
driver is derived from a version which appeared in
.Fx 4.8 ,
which in turn is based on code which appeared in
.Ox 3.2 .
.Sh BUGS
Error checking and reporting is weak.
The values specified for symmetric-key key sizes to
.Dv CRIOCGSESSION
must exactly match the values expected by
.XR opencrypto 9 .
The output buffer and MAC buffers supplied to
.Dv CRIOCRYPT
must follow whether privacy or integrity algorithms were specified for
session: if you request a
.No non- Ns Dv NULL
algorithm, you must supply a suitably-sized buffer.
p The scheme for passing arguments for asymmetric requests is Baroque.