DPDK patches and discussions
 help / color / mirror / Atom feed
From: Pablo de Lara <pablo.de.lara.guarch@intel.com>
To: pablo.de.lara.guarch@intel.com
Cc: dev@dpdk.org
Subject: [dpdk-dev] [PATCH 20/22] cryptodev: add AEAD parameters in crypto operation
Date: Wed, 21 Jun 2017 08:47:29 +0100	[thread overview]
Message-ID: <20170621074731.45013-20-pablo.de.lara.guarch@intel.com> (raw)
In-Reply-To: <20170621074731.45013-1-pablo.de.lara.guarch@intel.com>

AEAD operation parameters can be set in the new
aead structure, in the crypto operation.
This structure is within an union with the cipher
and authentication parameters, since operations can be:
- AEAD: using the aead structure

- Cipher only: using only the cipher structure

- Auth only: using only the authentication structure

- Cipher-then-auth/Auth-then-cipher: using both cipher
  and authentication structures

Therefore, all three cannot be used at the same time.

Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
 lib/librte_cryptodev/rte_crypto_sym.h | 360 ++++++++++++++++++++--------------
 1 file changed, 218 insertions(+), 142 deletions(-)

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 9d5ab32..fc0d06b 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -524,151 +524,227 @@ struct rte_crypto_sym_op {
 		/**< Session-less API crypto operation parameters */
 	};
 
-	struct {
-		struct {
-			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 SNOW 3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2,
-			  * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
-			  * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
-			  * this field should be in bits.
-			  */
-
-			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 @ref 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.
-			  *
-			  * @note
-			  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
-			  * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
-			  * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
-			  * this field should be in bits.
-			  */
-		} data; /**< Data offsets and length for ciphering */
-
-	} cipher;
-
-	struct {
-		struct {
-			uint32_t offset;
-			 /**< 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 @ref aad field
-			  * should be set instead.
-			  *
-			  * @note
-			  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2,
-			  * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9
-			  * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3,
-			  * this field should be in bits.
-			  */
-
-			uint32_t length;
-			 /**< 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 @ref aad field should be set
-			  * instead.
-			  *
-			  * @note
-			  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2,
-			  * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9
-			  * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3,
-			  * this field should be in bits.
-			  */
-		} data; /**< Data offsets and length for authentication */
-
+	union {
 		struct {
-			uint8_t *data;
-			/**< This points 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 @ref 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 (@ref RTE_CRYPTO_AUTH_AES_GCM), for
-			 * "digest result" read "authentication tag T".
-			 */
-			phys_addr_t phys_addr;
-			/**< Physical address of digest */
-		} digest; /**< Digest parameters */
+			struct {
+				uint32_t offset;
+				 /**< Starting point for AEAD processing, specified as
+				  * number of bytes from start of packet in source
+				  * buffer.
+				  */
+				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
+				  */
+			} data; /**< Data offsets and length for AEAD */
+			struct {
+				uint8_t *data;
+				/**< This points 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 @ref 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 (@ref RTE_CRYPTO_AEAD_AES_GCM), for
+				 * "digest result" read "authentication tag T".
+				 */
+				phys_addr_t phys_addr;
+				/**< Physical address of digest */
+			} digest; /**< Digest parameters */
+			struct {
+				uint8_t *data;
+				/**< Pointer to Additional Authenticated Data (AAD)
+				 * needed for authenticated cipher mechanisms (CCM and
+				 * GCM)
+				 *
+				 * Specifically for CCM (@ref RTE_CRYPTO_AEAD_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 (@ref RTE_CRYPTO_AEAD_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).
+				 *
+				 */
+				phys_addr_t phys_addr;	/**< physical address */
+			} aad;
+			/**< Additional authentication parameters */
+		} aead;
 
 		struct {
-			uint8_t *data;
-			/**< Pointer to Additional Authenticated Data (AAD)
-			 * needed for authenticated cipher mechanisms (CCM and
-			 * GCM).
-			 *
-			 * The length of the data pointed to by this field is
-			 * set up for the session in the @ref
-			 * rte_crypto_auth_xform structure as part of the @ref
-			 * rte_cryptodev_sym_session_create function call.
-			 * This length must not exceed 65535 (2^16-1) bytes.
-			 *
-			 * Specifically for CCM (@ref 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 (@ref 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).
-			 *
-			 */
-			phys_addr_t phys_addr;	/**< physical address */
-		} aad;
-		/**< Additional authentication parameters */
-	} auth;
+			struct {
+				struct {
+					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 SNOW 3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2,
+					  * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
+					  * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
+					  * this field should be in bits.
+					  */
+					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 @ref 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.
+					  *
+					  * @note
+					  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
+					  * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
+					  * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
+					  * this field should be in bits.
+					  */
+				} data; /**< Data offsets and length for ciphering */
+			} cipher;
+
+			struct {
+				struct {
+					uint32_t offset;
+					 /**< 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 @ref aad field
+					  * should be set instead.
+					  *
+					  * @note
+					  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2,
+					  * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9
+					  * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3,
+					  * this field should be in bits.
+					  */
+					uint32_t length;
+					 /**< 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 @ref aad field should be set
+					  * instead.
+					  *
+					  * @note
+					  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2,
+					  * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9
+					  * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3,
+					  * this field should be in bits.
+					  */
+				} data; /**< Data offsets and length for authentication */
+
+				struct {
+					uint8_t *data;
+					/**< This points 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 @ref 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 (@ref RTE_CRYPTO_AUTH_AES_GCM), for
+					 * "digest result" read "authentication tag T".
+					 */
+					phys_addr_t phys_addr;
+					/**< Physical address of digest */
+				} digest; /**< Digest parameters */
+
+				struct {
+					uint8_t *data;
+					/**< Pointer to Additional Authenticated Data (AAD)
+					 * needed for authenticated cipher mechanisms (CCM and
+					 * GCM).
+					 *
+					 * The length of the data pointed to by this field is
+					 * set up for the session in the @ref
+					 * rte_crypto_auth_xform structure as part of the @ref
+					 * rte_cryptodev_sym_session_create function call.
+					 * This length must not exceed 65535 (2^16-1) bytes.
+					 *
+					 * Specifically for CCM (@ref 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 (@ref 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).
+					 *
+					 */
+					phys_addr_t phys_addr;	/**< physical address */
+				} aad;
+				/**< Additional authentication parameters */
+			} auth;
+		};
+	};
 };
 
 
-- 
2.9.4

  parent reply	other threads:[~2017-06-21 15:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21  7:47 [dpdk-dev] [PATCH 01/22] cryptodev: move session type to generic crypto op Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 02/22] cryptodev: replace enums with 1-byte variables Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 03/22] cryptodev: remove opaque data pointer in crypto op Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 04/22] cryptodev: do not store pointer to op specific params Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 05/22] cryptodev: add crypto op helper macros Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 06/22] crypto/qat: fix auth parameters for KASUMI Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 07/22] test/crypto: move IV to crypto op private data Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 08/22] test/crypto-perf: " Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 09/22] app/crypto-perf: " Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 10/22] examples/l2fwd-crypto: " Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 11/22] examples/ipsec-secgw: " Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 12/22] cryptodev: pass IV as offset Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 13/22] cryptodev: move IV parameters to crypto session Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 14/22] cryptodev: add auth IV Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 15/22] cryptodev: do not use AAD in wireless algorithms Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 16/22] cryptodev: remove AAD length from crypto op Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 17/22] cryptodev: remove digest " Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 18/22] cryptodev: set AES-GMAC as auth-only algo Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 19/22] cryptodev: add AEAD specific data Pablo de Lara
2017-06-21  7:47 ` Pablo de Lara [this message]
2017-06-21  7:47 ` [dpdk-dev] [PATCH 21/22] cryptodev: use AES-GCM/CCM as AEAD algorithms Pablo de Lara
2017-06-21  7:47 ` [dpdk-dev] [PATCH 22/22] cryptodev: remove AAD from authentication structure Pablo de Lara
2017-06-21 16:29 ` [dpdk-dev] [PATCH 01/22] cryptodev: move session type to generic crypto op De Lara Guarch, Pablo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170621074731.45013-20-pablo.de.lara.guarch@intel.com \
    --to=pablo.de.lara.guarch@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).