DPDK  19.02.0
Data Fields
rte_crypto_cipher_xform Struct Reference

#include <rte_crypto_sym.h>

Data Fields

enum rte_crypto_cipher_operation op
enum rte_crypto_cipher_algorithm algo
struct {
   uint8_t *   data
   uint16_t   length
key
struct {
   uint16_t   offset
   uint16_t   length
iv

Detailed Description

Symmetric Cipher Setup Data.

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

Examples:
examples/fips_validation/fips_dev_self_test.c, and examples/fips_validation/main.c.

Definition at line 107 of file rte_crypto_sym.h.

Field Documentation

This parameter determines if the cipher operation is an encrypt or a decrypt operation. For the RC4 algorithm and the F8/CTR modes, only encrypt operations are valid.

Examples:
examples/fips_validation/fips_dev_self_test.c, examples/fips_validation/main.c, and examples/ip_pipeline/cli.c.

Definition at line 108 of file rte_crypto_sym.h.

uint8_t* data
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).

              - 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.
Examples:
examples/fips_validation/fips_dev_self_test.c, examples/fips_validation/main.c, and examples/ip_pipeline/cli.c.

Definition at line 118 of file rte_crypto_sym.h.

struct { ... } key

Cipher key

      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.

      For AES-XTS mode of operation, two keys must be provided and
      key.data must point to the two keys concatenated together (Key1 ||
      Key2). The cipher key length will contain the total size of both
      keys.

      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.
       - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
       - Both keys must have the same size.
Examples:
examples/fips_validation/fips_dev_self_test.c, examples/fips_validation/main.c, and examples/ip_pipeline/cli.c.
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 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. 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.

Examples:
examples/fips_validation/fips_dev_self_test.c, examples/fips_validation/main.c, and examples/ip_pipeline/cli.c.

Definition at line 148 of file rte_crypto_sym.h.

struct { ... } iv

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