|
DPDK
16.04.0
|
#include <rte_crypto_sym.h>
Data Fields | |
| struct rte_mbuf * | m_src |
| struct rte_mbuf * | m_dst |
| struct rte_cryptodev_sym_session * | session |
| struct rte_crypto_sym_xform * | xform |
| 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 |
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.
| struct rte_mbuf* m_src |
| 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.
Starting point for hash processing, specified as number of bytes from start of packet in source buffer.
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.
The message length, in bytes, of the source buffer that the hash will be computed on.
Definition at line 396 of file rte_crypto_sym.h.
| struct { ... } data |
Data offsets and length for ciphering
| 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.
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:
Finally, for GCM (RTE_CRYPTO_AUTH_AES_GCM), the caller should setup this field as follows:
Definition at line 422 of file rte_crypto_sym.h.
| phys_addr_t phys_addr |
| 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
| struct { ... } data |
Data offsets and length for authentication
| struct { ... } digest |
Digest parameters
| struct { ... } aad |
Additional authentication parameters
1.8.1.2