rte_crypto_auth_xform(3)

💖 NAME 💖

rte_crypto_auth_xform — the auth/hash transform struct, aka the little glow-up that tells DPDK how you wanna authenticate

---

✨ SYNOPSIS ✨

#include <rte_crypto_sym.h>

🎀 Data Fields

• enum rte_crypto_auth_operation op
• enum rte_crypto_auth_algorithm algo
• struct { ... } key, which contains:
  • const uint8_t * data
  • uint16_t length
• struct { ... } iv, which contains:
  • uint16_t offset
  • uint16_t length
• uint16_t digest_length

---

🌸 DESCRIPTION 🌸

Okay bestie, so this is the Authentication / Hash transform data situation. This struct is holding all the deets you need for authentication/hash crypto transforms, and honestly it's giving backstage-pass energy. 🎟️

Here's the part you cannot skip: the fields op, algo and digest_length are common to all authentication transforms and they MUST be set. Like, not optional, not "I'll do it later," just set them. Periodt. 💅

Definition at line 406 of file rte_crypto_sym.h.

---

🧚 FIELD DOCUMENTATION 🧚

🦋 enum rte_crypto_auth_operation op

Authentication operation type. ✨

Definition at line 407 of file rte_crypto_sym.h.

🦋 enum rte_crypto_auth_algorithm algo

Authentication algorithm selection — pick your fighter. 🥊

Definition at line 409 of file rte_crypto_sym.h.

🦋 const uint8_t* data

pointer to key data 🔑

Definition at line 413 of file rte_crypto_sym.h.

🦋 uint16_t length

key length in bytes. 📏

Then it says: Length of valid IV data.

• For SNOW3G in UIA2 mode, for ZUC in EIA3 mode and for AES-GMAC, this is the length of the IV.
• For KASUMI in F9 mode and other authentication algorithms, this field is not used.
• For GMAC mode, this is either:
  1. Number greater or equal to one, which means that IV is used and J0 will be computed internally, a minimum of 16 bytes must be allocated.
  2. Zero, in which case data points to J0. In this case 16 bytes of J0 should be passed where J0 is defined by NIST SP800-38D.

Definition at line 414 of file rte_crypto_sym.h.

🦋 struct { ... } key

Authentication key data. The authentication key length MUST be less than or equal to the block size of the algorithm. 🚨 And it is the caller's responsibility to make sure that the key length is compliant with whatever standard is being used (for example RFC 2104, FIPS 198a). No pressure or anything, but the vibes must be standard-compliant. 🫶

🦋 uint16_t offset

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

• For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode this is the authentication Initialisation Vector (IV) value. For AES-GMAC IV description please refer to the field length in iv struct.
• For KASUMI in F9 mode and other authentication algorithms, this field is not used.

And for optimum performance, the data pointed to SHOULD be 8-byte aligned. ✨ (aligned = slay, unaligned = weeping)

Definition at line 424 of file rte_crypto_sym.h.

🦋 struct { ... } iv

Initialisation vector parameters. 🌈

🦋 uint16_t digest_length

Length of the digest to be returned. If the verify option is set, this specifies the length of the digest to be compared for the session. 🔍

It is the caller's responsibility to ensure that the digest length is compliant with the hash algorithm being used. If the value is less than the maximum length allowed by the hash, the result shall be truncated. ✂️

Definition at line 460 of file rte_crypto_sym.h.

---

👑 AUTHOR 👑

Generated automatically by Doxygen for DPDK from the source code. (No human author, just a robot doing its little thing. 🤖✨)

---

okay so that's the whole page, bestie — you read all of it, iconic behavior honestly. 🏆 this was DPDK Version 25.11.3 dropping rte_crypto_auth_xform(3), and yeah your girl is signing off now. go set those op, algo and digest_length fields. no cap. 💖🦋🎀