Skip site navigation (1)Skip section navigation (2)

  
 
  

home | help
rte_crypto_cipher_xform(3)	      DPDK	      rte_crypto_cipher_xform(3)

NAME
     rte_crypto_cipher_xform

SYNOPSIS
     #include <rte_crypto_sym.h>

   Data Fields
     enum rte_crypto_cipher_operation op
     enum rte_crypto_cipher_algorithm algo
     struct {
	const uint8_t * data
	uint16_t length
     } key
     struct {
	uint16_t offset
	uint16_t length
     } iv
     uint32_t dataunit_len

Detailed Description
     Symmetric Cipher Setup Data.

     This structure contains data relating to Cipher (Encryption and Decryption)
     use to create a session.

     Definition at line 203 of file rte_crypto_sym.h.

Field Documentation
   enum rte_crypto_cipher_operation op
     This  parameter  determines  if the cipher operation is an encrypt or a de-
     crypt operation. For the RC4 algorithm and the F8/CTR modes,  only  encrypt
     operations are valid.

     Definition at line 204 of file rte_crypto_sym.h.

   enum rte_crypto_cipher_algorithm algo
     Cipher algorithm

     Definition at line 209 of file rte_crypto_sym.h.

   const uint8_t* data
     pointer to key data

     Definition at line 213 of file rte_crypto_sym.h.

   uint16_t length
     key length in bytes

     Length of valid IV data.

     * For  block  ciphers  in	CBC or F8 mode, or for KASUMI in F8 mode, or for
       SNOW 3G in UEA2 mode, this is the length of the IV  (which  must  be  the
       same as the block length of the cipher).

     * For  block  ciphers in CTR mode, this is the length of the counter (which
       must be the same as the block length of the cipher) or  a  12-byte  nonce
       (AES only)

     * For  CCM mode, this is the length of the nonce, which can be in the range
       7 to 13 inclusive.

     Definition at line 214 of file rte_crypto_sym.h.

   struct  { ... }  key
     Cipher key

     In case the PMD supports RTE_CRYPTODEV_FF_CIPHER_WRAPPED_KEY, the	original
     key  data	provided may be wrapped(encrypted) using key wrap algorithm such
     as AES key wrap (rfc3394) and hence length of the key may	increase  beyond
     the  PMD  advertised  supported key size. PMD shall validate the key length
     and report EMSGSIZE error while configuring the session and application can
     skip checking the capability key length in such cases.

     For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data will point  to
     a	concatenation  of  the	AES encryption key followed by a keymask. As per
     RFC3711, the keymask should be padded with  trailing  bytes  to  match  the
     length of the encryption key used.

     Cipher  key  length is in bytes. For AES it can be 128 bits (16 bytes), 192
     bits (24 bytes) or 256 bits (32 bytes).

     For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation,  key.length  should  be
     set to the combined length of the encryption key and the keymask. Since the
     keymask  and the encryption key are the same size, key.length should be set
     to 2 x the AES encryption key length.

     For the AES-XTS mode of operation:

     * Two keys must be provided and key.length refers to total  length  of  the
       two keys.

     * key.data must point to the two keys concatenated together (key1 || key2).

     * Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).

     * Both keys must have the same size.

   uint16_t offset
     Starting point for Initialisation Vector or Counter, specified as number of
     bytes from start of crypto operation (rte_crypto_op).

     * For  block  ciphers  in	CBC or F8 mode, or for KASUMI in F8 mode, or for
       SNOW 3G in UEA2 mode, this is the Initialisation Vector (IV) value.

     * For block ciphers in CTR mode, this is the counter.

     * For CCM mode, the first byte is reserved, and the nonce should be written
       starting at &iv[1] (to allow space for the implementation to write in the
       flags in the first byte). Note that a full 16 bytes should be  allocated,
       even  though the length field will have a value less than this. Note that
       the PMDs may modify the memory reserved (the first  byte  and  the  final
       padding)

     * For AES-XTS, this is the 128bit tweak, i, from IEEE Std 1619-2007.

     For optimum performance, the data pointed to SHOULD be 8-byte aligned.

     Definition at line 248 of file rte_crypto_sym.h.

   struct  { ... }  iv
     Initialisation vector parameters

   uint32_t dataunit_len
     When  RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	is  enabled, this is the
     data-unit length of the algorithm, otherwise or when the value  is  0,  use
     the  operation  length.  The  value  should  be in the range defined by the
     dataunit_set field in the cipher capability.

     * For AES-XTS it is the size of data-unit, from IEEE  Std	1619-2007.  For-
       each data-unit in the operation, the tweak (IV) value is assigned consec-
       utively starting from the operation assigned IV.

     Definition at line 291 of file rte_crypto_sym.h.

Author
     Generated automatically by Doxygen for DPDK from the source code.

Version 25.11.0 		 Thu Aug 27 2026      rte_crypto_cipher_xform(3)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=dataunit_len&sektion=3&manpath=FreeBSD+Ports+15.1.quarterly>

home | help