cryptodev: revert Chacha20-Poly1305 AEAD algorithm
[dpdk.git] / lib / librte_cryptodev / rte_crypto_sym.h
1 /* SPDX-License-Identifier: BSD-3-Clause
2  * Copyright(c) 2016-2019 Intel Corporation
3  */
4
5 #ifndef _RTE_CRYPTO_SYM_H_
6 #define _RTE_CRYPTO_SYM_H_
7
8 /**
9  * @file rte_crypto_sym.h
10  *
11  * RTE Definitions for Symmetric Cryptography
12  *
13  * Defines symmetric cipher and authentication algorithms and modes, as well
14  * as supported symmetric crypto operation combinations.
15  */
16
17 #ifdef __cplusplus
18 extern "C" {
19 #endif
20
21 #include <string.h>
22
23 #include <rte_mbuf.h>
24 #include <rte_memory.h>
25 #include <rte_mempool.h>
26 #include <rte_common.h>
27
28
29 /** Symmetric Cipher Algorithms */
30 enum rte_crypto_cipher_algorithm {
31         RTE_CRYPTO_CIPHER_NULL = 1,
32         /**< NULL cipher algorithm. No mode applies to the NULL algorithm. */
33
34         RTE_CRYPTO_CIPHER_3DES_CBC,
35         /**< Triple DES algorithm in CBC mode */
36         RTE_CRYPTO_CIPHER_3DES_CTR,
37         /**< Triple DES algorithm in CTR mode */
38         RTE_CRYPTO_CIPHER_3DES_ECB,
39         /**< Triple DES algorithm in ECB mode */
40
41         RTE_CRYPTO_CIPHER_AES_CBC,
42         /**< AES algorithm in CBC mode */
43         RTE_CRYPTO_CIPHER_AES_CTR,
44         /**< AES algorithm in Counter mode */
45         RTE_CRYPTO_CIPHER_AES_ECB,
46         /**< AES algorithm in ECB mode */
47         RTE_CRYPTO_CIPHER_AES_F8,
48         /**< AES algorithm in F8 mode */
49         RTE_CRYPTO_CIPHER_AES_XTS,
50         /**< AES algorithm in XTS mode */
51
52         RTE_CRYPTO_CIPHER_ARC4,
53         /**< (A)RC4 cipher algorithm */
54
55         RTE_CRYPTO_CIPHER_KASUMI_F8,
56         /**< KASUMI algorithm in F8 mode */
57
58         RTE_CRYPTO_CIPHER_SNOW3G_UEA2,
59         /**< SNOW 3G algorithm in UEA2 mode */
60
61         RTE_CRYPTO_CIPHER_ZUC_EEA3,
62         /**< ZUC algorithm in EEA3 mode */
63
64         RTE_CRYPTO_CIPHER_DES_CBC,
65         /**< DES algorithm in CBC mode */
66
67         RTE_CRYPTO_CIPHER_AES_DOCSISBPI,
68         /**< AES algorithm using modes required by
69          * DOCSIS Baseline Privacy Plus Spec.
70          * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
71          * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
72          */
73
74         RTE_CRYPTO_CIPHER_DES_DOCSISBPI,
75         /**< DES algorithm using modes required by
76          * DOCSIS Baseline Privacy Plus Spec.
77          * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
78          * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
79          */
80
81         RTE_CRYPTO_CIPHER_LIST_END
82
83 };
84
85 /** Cipher algorithm name strings */
86 extern const char *
87 rte_crypto_cipher_algorithm_strings[];
88
89 /** Symmetric Cipher Direction */
90 enum rte_crypto_cipher_operation {
91         RTE_CRYPTO_CIPHER_OP_ENCRYPT,
92         /**< Encrypt cipher operation */
93         RTE_CRYPTO_CIPHER_OP_DECRYPT
94         /**< Decrypt cipher operation */
95 };
96
97 /** Cipher operation name strings */
98 extern const char *
99 rte_crypto_cipher_operation_strings[];
100
101 /**
102  * Symmetric Cipher Setup Data.
103  *
104  * This structure contains data relating to Cipher (Encryption and Decryption)
105  *  use to create a session.
106  */
107 struct rte_crypto_cipher_xform {
108         enum rte_crypto_cipher_operation op;
109         /**< This parameter determines if the cipher operation is an encrypt or
110          * a decrypt operation. For the RC4 algorithm and the F8/CTR modes,
111          * only encrypt operations are valid.
112          */
113         enum rte_crypto_cipher_algorithm algo;
114         /**< Cipher algorithm */
115
116         struct {
117                 const uint8_t *data;    /**< pointer to key data */
118                 uint16_t length;        /**< key length in bytes */
119         } key;
120         /**< Cipher key
121          *
122          * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data will
123          * point to a concatenation of the AES encryption key followed by a
124          * keymask. As per RFC3711, the keymask should be padded with trailing
125          * bytes to match the length of the encryption key used.
126          *
127          * Cipher key length is in bytes. For AES it can be 128 bits (16 bytes),
128          * 192 bits (24 bytes) or 256 bits (32 bytes).
129          *
130          * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.length
131          * should be set to the combined length of the encryption key and the
132          * keymask. Since the keymask and the encryption key are the same size,
133          * key.length should be set to 2 x the AES encryption key length.
134          *
135          * For the AES-XTS mode of operation:
136          *  - Two keys must be provided and key.length refers to total length of
137          *    the two keys.
138          *  - key.data must point to the two keys concatenated together
139          *    (key1 || key2).
140          *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
141          *  - Both keys must have the same size.
142          **/
143         struct {
144                 uint16_t offset;
145                 /**< Starting point for Initialisation Vector or Counter,
146                  * specified as number of bytes from start of crypto
147                  * operation (rte_crypto_op).
148                  *
149                  * - For block ciphers in CBC or F8 mode, or for KASUMI
150                  * in F8 mode, or for SNOW 3G in UEA2 mode, this is the
151                  * Initialisation Vector (IV) value.
152                  *
153                  * - For block ciphers in CTR mode, this is the counter.
154                  *
155                  * - For CCM mode, the first byte is reserved, and the
156                  * nonce should be written starting at &iv[1] (to allow
157                  * space for the implementation to write in the flags
158                  * in the first byte). Note that a full 16 bytes should
159                  * be allocated, even though the length field will
160                  * have a value less than this. Note that the PMDs may
161                  * modify the memory reserved (the first byte and the
162                  * final padding)
163                  *
164                  * - For AES-XTS, this is the 128bit tweak, i, from
165                  * IEEE Std 1619-2007.
166                  *
167                  * For optimum performance, the data pointed to SHOULD
168                  * be 8-byte aligned.
169                  */
170                 uint16_t length;
171                 /**< Length of valid IV data.
172                  *
173                  * - For block ciphers in CBC or F8 mode, or for KASUMI
174                  * in F8 mode, or for SNOW 3G in UEA2 mode, this is the
175                  * length of the IV (which must be the same as the
176                  * block length of the cipher).
177                  *
178                  * - For block ciphers in CTR mode, this is the length
179                  * of the counter (which must be the same as the block
180                  * length of the cipher).
181                  *
182                  * - For CCM mode, this is the length of the nonce,
183                  * which can be in the range 7 to 13 inclusive.
184                  */
185         } iv;   /**< Initialisation vector parameters */
186 };
187
188 /** Symmetric Authentication / Hash Algorithms */
189 enum rte_crypto_auth_algorithm {
190         RTE_CRYPTO_AUTH_NULL = 1,
191         /**< NULL hash algorithm. */
192
193         RTE_CRYPTO_AUTH_AES_CBC_MAC,
194         /**< AES-CBC-MAC algorithm. Only 128-bit keys are supported. */
195         RTE_CRYPTO_AUTH_AES_CMAC,
196         /**< AES CMAC algorithm. */
197         RTE_CRYPTO_AUTH_AES_GMAC,
198         /**< AES GMAC algorithm. */
199         RTE_CRYPTO_AUTH_AES_XCBC_MAC,
200         /**< AES XCBC algorithm. */
201
202         RTE_CRYPTO_AUTH_KASUMI_F9,
203         /**< KASUMI algorithm in F9 mode. */
204
205         RTE_CRYPTO_AUTH_MD5,
206         /**< MD5 algorithm */
207         RTE_CRYPTO_AUTH_MD5_HMAC,
208         /**< HMAC using MD5 algorithm */
209
210         RTE_CRYPTO_AUTH_SHA1,
211         /**< 128 bit SHA algorithm. */
212         RTE_CRYPTO_AUTH_SHA1_HMAC,
213         /**< HMAC using 128 bit SHA algorithm. */
214         RTE_CRYPTO_AUTH_SHA224,
215         /**< 224 bit SHA algorithm. */
216         RTE_CRYPTO_AUTH_SHA224_HMAC,
217         /**< HMAC using 224 bit SHA algorithm. */
218         RTE_CRYPTO_AUTH_SHA256,
219         /**< 256 bit SHA algorithm. */
220         RTE_CRYPTO_AUTH_SHA256_HMAC,
221         /**< HMAC using 256 bit SHA algorithm. */
222         RTE_CRYPTO_AUTH_SHA384,
223         /**< 384 bit SHA algorithm. */
224         RTE_CRYPTO_AUTH_SHA384_HMAC,
225         /**< HMAC using 384 bit SHA algorithm. */
226         RTE_CRYPTO_AUTH_SHA512,
227         /**< 512 bit SHA algorithm. */
228         RTE_CRYPTO_AUTH_SHA512_HMAC,
229         /**< HMAC using 512 bit SHA algorithm. */
230
231         RTE_CRYPTO_AUTH_SNOW3G_UIA2,
232         /**< SNOW 3G algorithm in UIA2 mode. */
233
234         RTE_CRYPTO_AUTH_ZUC_EIA3,
235         /**< ZUC algorithm in EIA3 mode */
236
237         RTE_CRYPTO_AUTH_SHA3_224,
238         /**< 224 bit SHA3 algorithm. */
239         RTE_CRYPTO_AUTH_SHA3_224_HMAC,
240         /**< HMAC using 224 bit SHA3 algorithm. */
241         RTE_CRYPTO_AUTH_SHA3_256,
242         /**< 256 bit SHA3 algorithm. */
243         RTE_CRYPTO_AUTH_SHA3_256_HMAC,
244         /**< HMAC using 256 bit SHA3 algorithm. */
245         RTE_CRYPTO_AUTH_SHA3_384,
246         /**< 384 bit SHA3 algorithm. */
247         RTE_CRYPTO_AUTH_SHA3_384_HMAC,
248         /**< HMAC using 384 bit SHA3 algorithm. */
249         RTE_CRYPTO_AUTH_SHA3_512,
250         /**< 512 bit SHA3 algorithm. */
251         RTE_CRYPTO_AUTH_SHA3_512_HMAC,
252         /**< HMAC using 512 bit SHA3 algorithm. */
253
254         RTE_CRYPTO_AUTH_LIST_END
255 };
256
257 /** Authentication algorithm name strings */
258 extern const char *
259 rte_crypto_auth_algorithm_strings[];
260
261 /** Symmetric Authentication / Hash Operations */
262 enum rte_crypto_auth_operation {
263         RTE_CRYPTO_AUTH_OP_VERIFY,      /**< Verify authentication digest */
264         RTE_CRYPTO_AUTH_OP_GENERATE     /**< Generate authentication digest */
265 };
266
267 /** Authentication operation name strings */
268 extern const char *
269 rte_crypto_auth_operation_strings[];
270
271 /**
272  * Authentication / Hash transform data.
273  *
274  * This structure contains data relating to an authentication/hash crypto
275  * transforms. The fields op, algo and digest_length are common to all
276  * authentication transforms and MUST be set.
277  */
278 struct rte_crypto_auth_xform {
279         enum rte_crypto_auth_operation op;
280         /**< Authentication operation type */
281         enum rte_crypto_auth_algorithm algo;
282         /**< Authentication algorithm selection */
283
284         struct {
285                 const uint8_t *data;    /**< pointer to key data */
286                 uint16_t length;        /**< key length in bytes */
287         } key;
288         /**< Authentication key data.
289          * The authentication key length MUST be less than or equal to the
290          * block size of the algorithm. It is the callers responsibility to
291          * ensure that the key length is compliant with the standard being used
292          * (for example RFC 2104, FIPS 198a).
293          */
294
295         struct {
296                 uint16_t offset;
297                 /**< Starting point for Initialisation Vector or Counter,
298                  * specified as number of bytes from start of crypto
299                  * operation (rte_crypto_op).
300                  *
301                  * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode
302                  *   this is the authentication Initialisation Vector
303                  *   (IV) value. For AES-GMAC IV description please refer
304                  *   to the field `length` in iv struct.
305                  *
306                  * - For KASUMI in F9 mode and other authentication
307                  *   algorithms, this field is not used.
308                  *
309                  * For optimum performance, the data pointed to SHOULD
310                  * be 8-byte aligned.
311                  */
312                 uint16_t length;
313                 /**< Length of valid IV data.
314                  *
315                  * - For SNOW3G in UIA2 mode, for ZUC in EIA3 mode and
316                  *   for AES-GMAC, this is the length of the IV.
317                  *
318                  * - For KASUMI in F9 mode and other authentication
319                  *   algorithms, this field is not used.
320                  *
321                  * - For GMAC mode, this is either:
322                  * 1) Number greater or equal to one, which means that IV
323                  *    is used and J0 will be computed internally, a minimum
324                  *    of 16 bytes must be allocated.
325                  * 2) Zero, in which case data points to J0. In this case
326                  *    16 bytes of J0 should be passed where J0 is defined
327                  *    by NIST SP800-38D.
328                  *
329                  */
330         } iv;   /**< Initialisation vector parameters */
331
332         uint16_t digest_length;
333         /**< Length of the digest to be returned. If the verify option is set,
334          * this specifies the length of the digest to be compared for the
335          * session.
336          *
337          * It is the caller's responsibility to ensure that the
338          * digest length is compliant with the hash algorithm being used.
339          * If the value is less than the maximum length allowed by the hash,
340          * the result shall be truncated.
341          */
342 };
343
344
345 /** Symmetric AEAD Algorithms */
346 enum rte_crypto_aead_algorithm {
347         RTE_CRYPTO_AEAD_AES_CCM = 1,
348         /**< AES algorithm in CCM mode. */
349         RTE_CRYPTO_AEAD_AES_GCM,
350         /**< AES algorithm in GCM mode. */
351         RTE_CRYPTO_AEAD_LIST_END
352 };
353
354 /** AEAD algorithm name strings */
355 extern const char *
356 rte_crypto_aead_algorithm_strings[];
357
358 /** Symmetric AEAD Operations */
359 enum rte_crypto_aead_operation {
360         RTE_CRYPTO_AEAD_OP_ENCRYPT,
361         /**< Encrypt and generate digest */
362         RTE_CRYPTO_AEAD_OP_DECRYPT
363         /**< Verify digest and decrypt */
364 };
365
366 /** Authentication operation name strings */
367 extern const char *
368 rte_crypto_aead_operation_strings[];
369
370 struct rte_crypto_aead_xform {
371         enum rte_crypto_aead_operation op;
372         /**< AEAD operation type */
373         enum rte_crypto_aead_algorithm algo;
374         /**< AEAD algorithm selection */
375
376         struct {
377                 const uint8_t *data;    /**< pointer to key data */
378                 uint16_t length;        /**< key length in bytes */
379         } key;
380
381         struct {
382                 uint16_t offset;
383                 /**< Starting point for Initialisation Vector or Counter,
384                  * specified as number of bytes from start of crypto
385                  * operation (rte_crypto_op).
386                  *
387                  * - For CCM mode, the first byte is reserved, and the
388                  * nonce should be written starting at &iv[1] (to allow
389                  * space for the implementation to write in the flags
390                  * in the first byte). Note that a full 16 bytes should
391                  * be allocated, even though the length field will
392                  * have a value less than this.
393                  *
394                  * For optimum performance, the data pointed to SHOULD
395                  * be 8-byte aligned.
396                  */
397                 uint16_t length;
398                 /**< Length of valid IV data.
399                  *
400                  * - For GCM mode, this is either:
401                  * 1) Number greater or equal to one, which means that IV
402                  *    is used and J0 will be computed internally, a minimum
403                  *    of 16 bytes must be allocated.
404                  * 2) Zero, in which case data points to J0. In this case
405                  *    16 bytes of J0 should be passed where J0 is defined
406                  *    by NIST SP800-38D.
407                  *
408                  * - For CCM mode, this is the length of the nonce,
409                  * which can be in the range 7 to 13 inclusive.
410                  */
411         } iv;   /**< Initialisation vector parameters */
412
413         uint16_t digest_length;
414
415         uint16_t aad_length;
416         /**< The length of the additional authenticated data (AAD) in bytes.
417          * For CCM mode, this is the length of the actual AAD, even though
418          * it is required to reserve 18 bytes before the AAD and padding
419          * at the end of it, so a multiple of 16 bytes is allocated.
420          */
421 };
422
423 /** Crypto transformation types */
424 enum rte_crypto_sym_xform_type {
425         RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED = 0, /**< No xform specified */
426         RTE_CRYPTO_SYM_XFORM_AUTH,              /**< Authentication xform */
427         RTE_CRYPTO_SYM_XFORM_CIPHER,            /**< Cipher xform  */
428         RTE_CRYPTO_SYM_XFORM_AEAD               /**< AEAD xform  */
429 };
430
431 /**
432  * Symmetric crypto transform structure.
433  *
434  * This is used to specify the crypto transforms required, multiple transforms
435  * can be chained together to specify a chain transforms such as authentication
436  * then cipher, or cipher then authentication. Each transform structure can
437  * hold a single transform, the type field is used to specify which transform
438  * is contained within the union
439  */
440 struct rte_crypto_sym_xform {
441         struct rte_crypto_sym_xform *next;
442         /**< next xform in chain */
443         enum rte_crypto_sym_xform_type type
444         ; /**< xform type */
445         RTE_STD_C11
446         union {
447                 struct rte_crypto_auth_xform auth;
448                 /**< Authentication / hash xform */
449                 struct rte_crypto_cipher_xform cipher;
450                 /**< Cipher xform */
451                 struct rte_crypto_aead_xform aead;
452                 /**< AEAD xform */
453         };
454 };
455
456 struct rte_cryptodev_sym_session;
457
458 /**
459  * Symmetric Cryptographic Operation.
460  *
461  * This structure contains data relating to performing symmetric cryptographic
462  * processing on a referenced mbuf data buffer.
463  *
464  * When a symmetric crypto operation is enqueued with the device for processing
465  * it must have a valid *rte_mbuf* structure attached, via m_src parameter,
466  * which contains the source data which the crypto operation is to be performed
467  * on.
468  * While the mbuf is in use by a crypto operation no part of the mbuf should be
469  * changed by the application as the device may read or write to any part of the
470  * mbuf. In the case of hardware crypto devices some or all of the mbuf
471  * may be DMAed in and out of the device, so writing over the original data,
472  * though only the part specified by the rte_crypto_sym_op for transformation
473  * will be changed.
474  * Out-of-place (OOP) operation, where the source mbuf is different to the
475  * destination mbuf, is a special case. Data will be copied from m_src to m_dst.
476  * The part copied includes all the parts of the source mbuf that will be
477  * operated on, based on the cipher.data.offset+cipher.data.length and
478  * auth.data.offset+auth.data.length values in the rte_crypto_sym_op. The part
479  * indicated by the cipher parameters will be transformed, any extra data around
480  * this indicated by the auth parameters will be copied unchanged from source to
481  * destination mbuf.
482  * Also in OOP operation the cipher.data.offset and auth.data.offset apply to
483  * both source and destination mbufs. As these offsets are relative to the
484  * data_off parameter in each mbuf this can result in the data written to the
485  * destination buffer being at a different alignment, relative to buffer start,
486  * to the data in the source buffer.
487  */
488 struct rte_crypto_sym_op {
489         struct rte_mbuf *m_src; /**< source mbuf */
490         struct rte_mbuf *m_dst; /**< destination mbuf */
491
492         RTE_STD_C11
493         union {
494                 struct rte_cryptodev_sym_session *session;
495                 /**< Handle for the initialised session context */
496                 struct rte_crypto_sym_xform *xform;
497                 /**< Session-less API crypto operation parameters */
498                 struct rte_security_session *sec_session;
499                 /**< Handle for the initialised security session context */
500         };
501
502         RTE_STD_C11
503         union {
504                 struct {
505                         struct {
506                                 uint32_t offset;
507                                  /**< Starting point for AEAD processing, specified as
508                                   * number of bytes from start of packet in source
509                                   * buffer.
510                                   */
511                                 uint32_t length;
512                                  /**< The message length, in bytes, of the source buffer
513                                   * on which the cryptographic operation will be
514                                   * computed. This must be a multiple of the block size
515                                   */
516                         } data; /**< Data offsets and length for AEAD */
517                         struct {
518                                 uint8_t *data;
519                                 /**< This points to the location where the digest result
520                                  * should be inserted (in the case of digest generation)
521                                  * or where the purported digest exists (in the case of
522                                  * digest verification).
523                                  *
524                                  * At session creation time, the client specified the
525                                  * digest result length with the digest_length member
526                                  * of the @ref rte_crypto_auth_xform structure. For
527                                  * physical crypto devices the caller must allocate at
528                                  * least digest_length of physically contiguous memory
529                                  * at this location.
530                                  *
531                                  * For digest generation, the digest result will
532                                  * overwrite any data at this location.
533                                  *
534                                  * @note
535                                  * For GCM (@ref RTE_CRYPTO_AEAD_AES_GCM), for
536                                  * "digest result" read "authentication tag T".
537                                  */
538                                 rte_iova_t phys_addr;
539                                 /**< Physical address of digest */
540                         } digest; /**< Digest parameters */
541                         struct {
542                                 uint8_t *data;
543                                 /**< Pointer to Additional Authenticated Data (AAD)
544                                  * needed for authenticated cipher mechanisms (CCM and
545                                  * GCM)
546                                  *
547                                  * Specifically for CCM (@ref RTE_CRYPTO_AEAD_AES_CCM),
548                                  * the caller should setup this field as follows:
549                                  *
550                                  * - the additional authentication data itself should
551                                  * be written starting at an offset of 18 bytes into
552                                  * the array, leaving room for the first block (16 bytes)
553                                  * and the length encoding in the first two bytes of the
554                                  * second block.
555                                  *
556                                  * - the array should be big enough to hold the above
557                                  * fields, plus any padding to round this up to the
558                                  * nearest multiple of the block size (16 bytes).
559                                  * Padding will be added by the implementation.
560                                  *
561                                  * - Note that PMDs may modify the memory reserved
562                                  * (first 18 bytes and the final padding).
563                                  *
564                                  * Finally, for GCM (@ref RTE_CRYPTO_AEAD_AES_GCM), the
565                                  * caller should setup this field as follows:
566                                  *
567                                  * - the AAD is written in starting at byte 0
568                                  * - the array must be big enough to hold the AAD, plus
569                                  * any space to round this up to the nearest multiple
570                                  * of the block size (16 bytes).
571                                  *
572                                  */
573                                 rte_iova_t phys_addr;   /**< physical address */
574                         } aad;
575                         /**< Additional authentication parameters */
576                 } aead;
577
578                 struct {
579                         struct {
580                                 struct {
581                                         uint32_t offset;
582                                          /**< Starting point for cipher processing,
583                                           * specified as number of bytes from start
584                                           * of data in the source buffer.
585                                           * The result of the cipher operation will be
586                                           * written back into the output buffer
587                                           * starting at this location.
588                                           *
589                                           * @note
590                                           * For SNOW 3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2,
591                                           * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
592                                           * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
593                                           * this field should be in bits. For
594                                           * digest-encrypted cases this must be
595                                           * an 8-bit multiple.
596                                           */
597                                         uint32_t length;
598                                          /**< The message length, in bytes, of the
599                                           * source buffer on which the cryptographic
600                                           * operation will be computed.
601                                           * This must be a multiple of the block size
602                                           * if a block cipher is being used. This is
603                                           * also the same as the result length.
604                                           *
605                                           * @note
606                                           * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
607                                           * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
608                                           * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
609                                           * this field should be in bits. For
610                                           * digest-encrypted cases this must be
611                                           * an 8-bit multiple.
612                                           */
613                                 } data; /**< Data offsets and length for ciphering */
614                         } cipher;
615
616                         struct {
617                                 struct {
618                                         uint32_t offset;
619                                          /**< Starting point for hash processing,
620                                           * specified as number of bytes from start of
621                                           * packet in source buffer.
622                                           *
623                                           * @note
624                                           * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2,
625                                           * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9
626                                           * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3,
627                                           * this field should be in bits. For
628                                           * digest-encrypted cases this must be
629                                           * an 8-bit multiple.
630                                           *
631                                           * @note
632                                           * For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9,
633                                           * this offset should be such that
634                                           * data to authenticate starts at COUNT.
635                                           */
636                                         uint32_t length;
637                                          /**< The message length, in bytes, of the source
638                                           * buffer that the hash will be computed on.
639                                           *
640                                           * @note
641                                           * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2,
642                                           * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9
643                                           * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3,
644                                           * this field should be in bits. For
645                                           * digest-encrypted cases this must be
646                                           * an 8-bit multiple.
647                                           *
648                                           * @note
649                                           * For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9,
650                                           * the length should include the COUNT,
651                                           * FRESH, message, direction bit and padding
652                                           * (to be multiple of 8 bits).
653                                           */
654                                 } data;
655                                 /**< Data offsets and length for authentication */
656
657                                 struct {
658                                         uint8_t *data;
659                                         /**< This points to the location where
660                                          * the digest result should be inserted
661                                          * (in the case of digest generation)
662                                          * or where the purported digest exists
663                                          * (in the case of digest verification).
664                                          *
665                                          * At session creation time, the client
666                                          * specified the digest result length with
667                                          * the digest_length member of the
668                                          * @ref rte_crypto_auth_xform structure.
669                                          * For physical crypto devices the caller
670                                          * must allocate at least digest_length of
671                                          * physically contiguous memory at this
672                                          * location.
673                                          *
674                                          * For digest generation, the digest result
675                                          * will overwrite any data at this location.
676                                          *
677                                          * @note
678                                          * Digest-encrypted case.
679                                          * Digest can be generated, appended to
680                                          * the end of raw data and encrypted
681                                          * together using chained digest
682                                          * generation
683                                          * (@ref RTE_CRYPTO_AUTH_OP_GENERATE)
684                                          * and encryption
685                                          * (@ref RTE_CRYPTO_CIPHER_OP_ENCRYPT)
686                                          * xforms. Similarly, authentication
687                                          * of the raw data against appended,
688                                          * decrypted digest, can be performed
689                                          * using decryption
690                                          * (@ref RTE_CRYPTO_CIPHER_OP_DECRYPT)
691                                          * and digest verification
692                                          * (@ref RTE_CRYPTO_AUTH_OP_VERIFY)
693                                          * chained xforms.
694                                          * To perform those operations, a few
695                                          * additional conditions must be met:
696                                          * - caller must allocate at least
697                                          * digest_length of memory at the end of
698                                          * source and (in case of out-of-place
699                                          * operations) destination buffer; those
700                                          * buffers can be linear or split using
701                                          * scatter-gather lists,
702                                          * - digest data pointer must point to
703                                          * the end of source or (in case of
704                                          * out-of-place operations) destination
705                                          * data, which is pointer to the
706                                          * data buffer + auth.data.offset +
707                                          * auth.data.length,
708                                          * - cipher.data.offset +
709                                          * cipher.data.length must be greater
710                                          * than auth.data.offset +
711                                          * auth.data.length and is typically
712                                          * equal to auth.data.offset +
713                                          * auth.data.length + digest_length.
714                                          * - for wireless algorithms, i.e.
715                                          * SNOW 3G, KASUMI and ZUC, as the
716                                          * cipher.data.length,
717                                          * cipher.data.offset,
718                                          * auth.data.length and
719                                          * auth.data.offset are in bits, they
720                                          * must be 8-bit multiples.
721                                          *
722                                          * Note, that for security reasons, it
723                                          * is PMDs' responsibility to not
724                                          * leave an unencrypted digest in any
725                                          * buffer after performing auth-cipher
726                                          * operations.
727                                          *
728                                          */
729                                         rte_iova_t phys_addr;
730                                         /**< Physical address of digest */
731                                 } digest; /**< Digest parameters */
732                         } auth;
733                 };
734         };
735 };
736
737
738 /**
739  * Reset the fields of a symmetric operation to their default values.
740  *
741  * @param       op      The crypto operation to be reset.
742  */
743 static inline void
744 __rte_crypto_sym_op_reset(struct rte_crypto_sym_op *op)
745 {
746         memset(op, 0, sizeof(*op));
747 }
748
749
750 /**
751  * Allocate space for symmetric crypto xforms in the private data space of the
752  * crypto operation. This also defaults the crypto xform type to
753  * RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED and configures the chaining of the xforms
754  * in the crypto operation
755  *
756  * @return
757  * - On success returns pointer to first crypto xform in crypto operations chain
758  * - On failure returns NULL
759  */
760 static inline struct rte_crypto_sym_xform *
761 __rte_crypto_sym_op_sym_xforms_alloc(struct rte_crypto_sym_op *sym_op,
762                 void *priv_data, uint8_t nb_xforms)
763 {
764         struct rte_crypto_sym_xform *xform;
765
766         sym_op->xform = xform = (struct rte_crypto_sym_xform *)priv_data;
767
768         do {
769                 xform->type = RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED;
770                 xform = xform->next = --nb_xforms > 0 ? xform + 1 : NULL;
771         } while (xform);
772
773         return sym_op->xform;
774 }
775
776
777 /**
778  * Attach a session to a symmetric crypto operation
779  *
780  * @param       sym_op  crypto operation
781  * @param       sess    cryptodev session
782  */
783 static inline int
784 __rte_crypto_sym_op_attach_sym_session(struct rte_crypto_sym_op *sym_op,
785                 struct rte_cryptodev_sym_session *sess)
786 {
787         sym_op->session = sess;
788
789         return 0;
790 }
791
792
793 #ifdef __cplusplus
794 }
795 #endif
796
797 #endif /* _RTE_CRYPTO_SYM_H_ */