From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 54985A054F; Tue, 16 Mar 2021 07:51:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C58EB4069F; Tue, 16 Mar 2021 07:51:47 +0100 (CET) Received: from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129]) by mails.dpdk.org (Postfix) with ESMTP id 0943040042 for ; Tue, 16 Mar 2021 07:51:45 +0100 (CET) Received: from Internal Mail-Server by MTLPINE1 (envelope-from matan@nvidia.com) with SMTP; 16 Mar 2021 08:51:45 +0200 Received: from pegasus25.mtr.labs.mlnx. (pegasus25.mtr.labs.mlnx [10.210.16.10]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id 12G6pics002224; Tue, 16 Mar 2021 08:51:44 +0200 From: Matan Azrad To: dev@dpdk.org Cc: akhil.goyal@nxp.com, Declan Doherty , Somalapuram Amaranath , Ruifeng Wang , Ajit Khaparde , Anoob Joseph , Fan Zhang , John Griffin , Pablo de Lara , Michael Shamis , Nagadheeraj Rottela , Ankur Dwivedi , Gagandeep Singh , Jay Zhou , ArkadiuszX Kusztal , sashakot@nvidia.com, oren@nvidia.com, Shiri Kuzin Date: Tue, 16 Mar 2021 06:51:41 +0000 Message-Id: <1615877501-164036-1-git-send-email-matan@nvidia.com> X-Mailer: git-send-email 1.8.3.1 Subject: [dpdk-dev] [PATCH] cryptodev: formalize key wrap method in API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" The Key Wrap approach is used by applications in order to protect keys located in untrusted storage or transmitted over untrusted communications networks. The constructions are typically built from standard primitives such as block ciphers and cryptographic hash functions. The Key Wrap method and its parameters are a secret between the keys provider and the device, means that the device is preconfigured for this method using very secured way. The key wrap method may change the key length and layout. Add a description for the cipher transformation key to allow wrapped key to be forwarded by the same API. Signed-off-by: Matan Azrad --- lib/librte_cryptodev/rte_crypto_sym.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h index 5973e31..6aca2c7 100644 --- a/lib/librte_cryptodev/rte_crypto_sym.h +++ b/lib/librte_cryptodev/rte_crypto_sym.h @@ -200,6 +200,13 @@ struct rte_crypto_cipher_xform { uint16_t length; /**< key length in bytes */ } key; /**< Cipher key + * The original key data may be provided wrapped (encrypted) using a key + * wrap algorithm such as AES key wrap (from rfc3394) or other. In such + * case, the wrapping details is a secret between the key provider and + * the device. Such key wrapping may increase the length of the provided + * key beyond the advertised supported key size. Hence it is the + * responsibility of the driver/device to validate the length of the + * provided key. * * 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 -- 1.8.3.1