DPDK  16.04.0
Data Fields
rte_crypto_sym_op Struct Reference

#include <rte_crypto_sym.h>

Data Fields

struct rte_mbufm_src
struct rte_mbufm_dst
struct rte_cryptodev_sym_sessionsession
struct rte_crypto_sym_xformxform
uint32_t offset
uint32_t length
struct {
   uint32_t   offset
   uint32_t   length
data
uint8_t * data
phys_addr_t phys_addr
uint16_t length
struct {
   uint8_t *   data
   uint16_t   length
iv
struct {
   uint32_t   offset
   uint32_t   length
data
struct {
   uint8_t *   data
   phys_addr_t   phys_addr
   uint16_t   length
digest
struct {
   uint8_t *   data
   phys_addr_t   phys_addr
   uint16_t   length
aad

Detailed Description

Symmetric Cryptographic Operation.

This structure contains data relating to performing symmetric cryptographic processing on a referenced mbuf data buffer.

When a symmetric crypto operation is enqueued with the device for processing it must have a valid rte_mbuf structure attached, via m_src parameter, which contains the source data which the crypto operation is to be performed on.

Definition at line 368 of file rte_crypto_sym.h.

Field Documentation

struct rte_mbuf* m_src

source mbuf

Examples:
l2fwd-crypto/main.c.

Definition at line 369 of file rte_crypto_sym.h.

struct rte_mbuf* m_dst

destination mbuf

Definition at line 370 of file rte_crypto_sym.h.

struct rte_cryptodev_sym_session* session

Handle for the initialised session context

Definition at line 375 of file rte_crypto_sym.h.

struct rte_crypto_sym_xform* xform

Session-less API crypto operation parameters

Definition at line 377 of file rte_crypto_sym.h.

uint32_t offset

Starting point for cipher processing, specified as number of bytes from start of data in the source buffer. The result of the cipher operation will be written back into the output buffer starting at this location.

Note
For Snow3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2, this field should be in bits.

Starting point for hash processing, specified as number of bytes from start of packet in source buffer.

Note
For CCM and GCM modes of operation, this field is ignored. The field aad field should be set instead.
For AES-GMAC (RTE_CRYPTO_AUTH_AES_GMAC) mode of operation, this field specifies the start of the AAD data in the source buffer.
For Snow3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2 this field should be in bits.

Definition at line 384 of file rte_crypto_sym.h.

uint32_t length

The message length, in bytes, of the source buffer on which the cryptographic operation will be computed. This must be a multiple of the block size if a block cipher is being used. This is also the same as the result length.

Note
In the case of CCM RTE_CRYPTO_AUTH_AES_CCM, this value should not include the length of the padding or the length of the MAC; the driver will compute the actual number of bytes over which the encryption will occur, which will include these values.
For AES-GMAC RTE_CRYPTO_AUTH_AES_GMAC, this field should be set to 0.
For Snow3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2 this field should be in bits.

The message length, in bytes, of the source buffer that the hash will be computed on.

Note
For CCM and GCM modes of operation, this field is ignored. The field aad field should be set instead.
For AES-GMAC RTE_CRYPTO_AUTH_AES_GMAC mode of operation, this field specifies the length of the AAD data in the source buffer.
For Snow3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2 this field should be in bits.

Definition at line 396 of file rte_crypto_sym.h.

struct { ... } data

Data offsets and length for ciphering

Examples:
l2fwd-crypto/main.c.
uint8_t* data

Initialisation Vector or Counter.

                      - For block ciphers in CBC or F8 mode, or for Kasumi
                      in F8 mode, or for SNOW3G in UEA2 mode, this is the
                      Initialisation Vector (IV) value.

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

                      - For GCM mode, this is either the IV (if the length
                      is 96 bits) or J0 (for other sizes), where J0 is as
                      defined by NIST SP800-38D. Regardless of the IV
                      length, a full 16 bytes needs to be allocated.

                      - 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.

                      - 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.

If this member of this structure is set this is a pointer to the location where the digest result should be inserted (in the case of digest generation) or where the purported digest exists (in the case of digest verification).

At session creation time, the client specified the digest result length with the digest_length member of the rte_crypto_auth_xform structure. For physical crypto devices the caller must allocate at least digest_length of physically contiguous memory at this location.

For digest generation, the digest result will overwrite any data at this location.

Note
For GCM (RTE_CRYPTO_AUTH_AES_GCM), for "digest result" read "authentication tag T".

If this member is not set the digest result is understood to be in the destination buffer for digest generation, and in the source buffer for digest verification. The location of the digest result in this case is immediately following the region over which the digest is computed.

Pointer to Additional Authenticated Data (AAD) needed for authenticated cipher mechanisms (CCM and GCM), and to the IV for SNOW3G authentication (RTE_CRYPTO_AUTH_SNOW3G_UIA2). For other authentication mechanisms this pointer is ignored.

The length of the data pointed to by this field is set up for the session in the rte_crypto_auth_xform structure as part of the rte_cryptodev_sym_session_create function call. This length must not exceed 240 bytes.

Specifically for CCM (RTE_CRYPTO_AUTH_AES_CCM), the caller should setup this field as follows:

  • the nonce should be written starting at an offset of one byte into the array, leaving room for the implementation to write in the flags to the first byte.
  • the additional authentication data itself should be written starting at an offset of 18 bytes into the array, leaving room for the length encoding in the first two bytes of the second block.
  • the array should be big enough to hold the above fields, plus any padding to round this up to the nearest multiple of the block size (16 bytes). Padding will be added by the implementation.

Finally, for GCM (RTE_CRYPTO_AUTH_AES_GCM), the caller should setup this field as follows:

  • the AAD is written in starting at byte 0
  • the array must be big enough to hold the AAD, plus any space to round this up to the nearest multiple of the block size (16 bytes).
Note
For AES-GMAC (RTE_CRYPTO_AUTH_AES_GMAC) mode of operation, this field is not used and should be set to 0. Instead the AAD data should be placed in the source buffer.

Definition at line 422 of file rte_crypto_sym.h.

phys_addr_t phys_addr

Physical address of digest

physical address

Definition at line 448 of file rte_crypto_sym.h.

uint16_t length

Length of valid IV data.

                      - For block ciphers in CBC or F8 mode, or for Kasumi
                      in F8 mode, or for SNOW3G 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).

                      - For GCM mode, this is either 12 (for 96-bit IVs)
                      or 16, in which case data points to J0.

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

Length of digest

Definition at line 450 of file rte_crypto_sym.h.

struct { ... } iv

Initialisation vector parameters

Examples:
l2fwd-crypto/main.c.
struct { ... } data

Data offsets and length for authentication

struct { ... } digest

Digest parameters

Examples:
l2fwd-crypto/main.c.
struct { ... } aad

Additional authentication parameters

Examples:
l2fwd-crypto/main.c.

The documentation for this struct was generated from the following file: