[GitHub] mkiiskila commented on a change in pull request #1649: [WIP] [RFC] Add initial crypto driver framework

[GitBox <gi...@apache.org>]

mkiiskila commented on a change in pull request #1649: [WIP] [RFC] Add initial crypto driver framework
URL: https://github.com/apache/mynewt-core/pull/1649#discussion_r261518746
 
 

 ##########
 File path: hw/drivers/crypto/include/crypto/crypto.h
 ##########
 @@ -0,0 +1,221 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+#ifndef __CRYPTO_H__
+#define __CRYPTO_H__
+
+#include <inttypes.h>
+#include <stddef.h>
+#include "os/mynewt.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*
+ * AES definitions
+ */
+#define AES_BLOCK_LEN     16
+
+#define AES_128_KEY_LEN   16
+#define AES_192_KEY_LEN   24
+#define AES_256_KEY_LEN   32
+#define AES_MAX_KEY_LEN   AES_256_KEY_LEN
+
+#define CRYPTO_VALID_AES_KEYLEN(x) \
+    (((x) == 128) || ((x) == 192) || ((x) == 256))
+
+/*
+ * Driver capabilities
+ */
+#define CRYPTO_OP_ENCRYPT              0x01
+#define CRYPTO_OP_DECRYPT              0x02
+#define CRYPTO_VALID_OP(x) \
+    (((x) == CRYPTO_OP_ENCRYPT) || ((x) == CRYPTO_OP_DECRYPT))
+
+#define CRYPTO_ALGO_AES                0x0001
+#define CRYPTO_ALGO_DES                0x0002
+#define CRYPTO_ALGO_3DES               0x0004
+#define CRYPTO_ALGO_RSA                0x0010
+
+#define CRYPTO_MODE_ECB                0x0001
+#define CRYPTO_MODE_CBC                0x0002
+#define CRYPTO_MODE_CTR                0x0004
+#define CRYPTO_MODE_CCM                0x0008
+#define CRYPTO_MODE_GCM                0x0010
+
+/*
+ * TODO: this driver need a global lock, only one thread can do
+ * encrypt/decrypt at any time...
+ */
+
+struct crypto_dev;
+
+typedef uint32_t (* crypto_op_func_t)(struct crypto_dev *crypto, uint16_t algo,
+        uint16_t mode, const uint8_t *key, uint16_t keylen, uint8_t *iv,
+        const uint8_t *inbuf, uint8_t *outbuf, uint32_t len);
+typedef bool (* crypto_support_func_t)(struct crypto_dev *crypto, uint8_t op,
+        uint16_t algo, uint16_t mode, uint16_t keylen);
+
+/**
+ * @struct crypto_interface
+ * @brief Provides the interface into a HW crypto driver
+ *
+ * @var crypto_interface::encrypt
+ * encrypt is a crypto_op_func_t pointer to the encryption routine
+ *
+ * @var crypto_interface::decrypt
+ * decrypt is a crypto_op_func_t pointer to the decryption routine
+ *
+ * @var crypto_interface::has_algomode
+ * caps exports the capabilities of the HW driver. see TODO
+ */
+struct crypto_interface {
+    crypto_op_func_t encrypt;
+    crypto_op_func_t decrypt;
 
 Review comment:
   I have few things which I want  here, and probably should phrase these explicitly. Sorry for the late response, I had to gather my thoughts a bit.
   
   1) I want to be able decrypt/encrypt data in-place. I don't want to spend cycles copying data from temporary buffers, when doing crypto. I can see some of the drivers appear to be able to do it, but I did not go through all
   of them. Thanks for addressing so many architectures with this, BTW.
   
   2) I want to be able to use discontiguous buffers. Specifically, I want to be able to add routines which decrypt/encrypt data within mbuf chain without having to move data to a temporary buffer for encryption/decryption, and then having to copy it back. I'd be ok with the interface being even iovec[], although state structure would've been best. The former allows for datagrams carried in mbuf chains, while the latter would allow me to use this with byte streams, like TCP.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services