rte_crypto_cipher_xform(3)

💖 NAME 💖

rte_crypto_cipher_xform — bestie, this is the cipher setup struct, and it lives in the DPDK Library Functions Manual 💅

---

✨ 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

Wait, nesting is a whole thing here, so let's lay the structs out exactly how they sit:

struct {
   const uint8_t * data
   uint16_t length
} key

struct {
   uint16_t offset
   uint16_t length
} iv

---

🦋 DESCRIPTION (Detailed Description) 🦋

Symmetric Cipher Setup Data. That's the vibe ✨

This structure contains data relating to Cipher (Encryption and Decryption) use to create a session. That's it, that's the whole job — it's the little info packet you hand over so the session knows what cipher-ing situation it's getting into 🫶

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

Big brain caveat, no cap:</p> 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. Periodt, that's the whole field 👑

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.

Okay so this one field doc literally covers both of those, and we're keeping it exactly like that, no edits, iykyk 😭

• 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 🔐</p>

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. She's asking nicely but she means it 💅

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 consecutively 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. No human hand-typed this, it's just the docs machine doing its thing 🧚

---

And that's the whole page, bestie — you read every single line, which is genuinely main character energy 🌟

This was the rte_crypto_cipher_xform(3) page from DPDK Version 25.11.3 💜 Go build something slay with it. Byeee 🎀💖✨