cryptodev: do not use AAD in wireless algorithms
[dpdk.git] / lib / librte_cryptodev / rte_crypto_sym.h
index 3a40844..56ef0c1 100644 (file)
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2016 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2016-2017 Intel Corporation. All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
  *   modification, are permitted provided that the following conditions
@@ -190,6 +190,55 @@ struct rte_crypto_cipher_xform {
         *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
         *  - Both keys must have the same size.
         **/
+       struct {
+               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.
+                *
+                * - 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.
+                */
+               uint16_t length;
+               /**< 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.
+                */
+       } iv;   /**< Initialisation vector parameters */
 };
 
 /** Symmetric Authentication / Hash Algorithms */
@@ -324,9 +373,6 @@ struct rte_crypto_auth_xform {
         * This field must be specified when the hash algorithm is one of the
         * following:
         *
-        * - For SNOW 3G (@ref RTE_CRYPTO_AUTH_SNOW3G_UIA2), this is the
-        *   length of the IV (which should be 16).
-        *
         * - For GCM (@ref RTE_CRYPTO_AUTH_AES_GCM).  In this case, this is
         *   the length of the Additional Authenticated Data (called A, in NIST
         *   SP800-38D).
@@ -344,6 +390,30 @@ struct rte_crypto_auth_xform {
         *  of the AAD data is specified in additional authentication data
         *  length field of the rte_crypto_sym_op_data structure
         */
+
+       struct {
+               uint16_t offset;
+               /**< Starting point for Initialisation Vector or Counter,
+                * specified as number of bytes from start of crypto
+                * operation (rte_crypto_op).
+                *
+                * - For KASUMI in F9 mode, SNOW 3G in UIA2 mode,
+                *   for ZUC in EIA3 mode and for AES-GMAC, this is the
+                *   authentication Initialisation Vector (IV) value.
+                *
+                *
+                * For optimum performance, the data pointed to SHOULD
+                * be 8-byte aligned.
+                */
+               uint16_t length;
+               /**< Length of valid IV data.
+                *
+                * - For KASUMI in F9 mode, SNOW3G in UIA2 mode, for
+                *   ZUC in EIA3 mode and for AES-GMAC, this is the length
+                *   of the IV.
+                *
+                */
+       } iv;   /**< Initialisation vector parameters */
 };
 
 /** Crypto transformation types */
@@ -376,17 +446,6 @@ struct rte_crypto_sym_xform {
        };
 };
 
-/**
- * Crypto operation session type. This is used to specify whether a crypto
- * operation has session structure attached for immutable parameters or if all
- * operation information is included in the operation data structure.
- */
-enum rte_crypto_sym_op_sess_type {
-       RTE_CRYPTO_SYM_OP_WITH_SESSION, /**< Session based crypto operation */
-       RTE_CRYPTO_SYM_OP_SESSIONLESS   /**< Session-less crypto operation */
-};
-
-
 struct rte_cryptodev_sym_session;
 
 /**
@@ -423,8 +482,6 @@ struct rte_crypto_sym_op {
        struct rte_mbuf *m_src; /**< source mbuf */
        struct rte_mbuf *m_dst; /**< destination mbuf */
 
-       enum rte_crypto_sym_op_sess_type sess_type;
-
        RTE_STD_C11
        union {
                struct rte_cryptodev_sym_session *session;
@@ -476,54 +533,6 @@ struct rte_crypto_sym_op {
                          */
                } data; /**< Data offsets and length for ciphering */
 
-               struct {
-                       uint8_t *data;
-                       /**< Initialisation Vector or Counter.
-                        *
-                        * - 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.
-                        *
-                        * - 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.
-                        */
-                       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 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.
-                        */
-               } iv;   /**< Initialisation vector parameters */
        } cipher;
 
        struct {
@@ -605,9 +614,7 @@ struct rte_crypto_sym_op {
                        uint8_t *data;
                        /**< Pointer to Additional Authenticated Data (AAD)
                         * needed for authenticated cipher mechanisms (CCM and
-                        * GCM), and to the IV for SNOW 3G authentication
-                        * (@ref RTE_CRYPTO_AUTH_SNOW3G_UIA2). For other
-                        * authentication mechanisms this pointer is ignored.
+                        * GCM).
                         *
                         * The length of the data pointed to by this field is
                         * set up for the session in the @ref
@@ -653,7 +660,7 @@ struct rte_crypto_sym_op {
                } aad;
                /**< Additional authentication parameters */
        } auth;
-} __rte_cache_aligned;
+};
 
 
 /**
@@ -665,8 +672,6 @@ static inline void
 __rte_crypto_sym_op_reset(struct rte_crypto_sym_op *op)
 {
        memset(op, 0, sizeof(*op));
-
-       op->sess_type = RTE_CRYPTO_SYM_OP_SESSIONLESS;
 }
 
 
@@ -708,7 +713,6 @@ __rte_crypto_sym_op_attach_sym_session(struct rte_crypto_sym_op *sym_op,
                struct rte_cryptodev_sym_session *sess)
 {
        sym_op->session = sess;
-       sym_op->sess_type = RTE_CRYPTO_SYM_OP_WITH_SESSION;
 
        return 0;
 }