From patchwork Thu Nov 3 00:41:59 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bill Fischofer X-Patchwork-Id: 80572 Delivered-To: patch@linaro.org Received: by 10.140.97.247 with SMTP id m110csp397658qge; Wed, 2 Nov 2016 17:46:25 -0700 (PDT) X-Received: by 10.176.2.145 with SMTP id 17mr4669980uah.38.1478133984972; Wed, 02 Nov 2016 17:46:24 -0700 (PDT) Return-Path: Received: from lists.linaro.org (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTP id 61si1619399uaw.222.2016.11.02.17.46.24; Wed, 02 Nov 2016 17:46:24 -0700 (PDT) Received-SPF: pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) client-ip=54.225.227.206; Authentication-Results: mx.google.com; spf=pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=lng-odp-bounces@lists.linaro.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 6C49F608F8; Thu, 3 Nov 2016 00:46:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ip-10-142-244-252 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2 autolearn=disabled version=3.4.0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.linaro.org (Postfix) with ESMTP id E5D8460D9D; Thu, 3 Nov 2016 00:43:57 +0000 (UTC) X-Original-To: lng-odp@lists.linaro.org Delivered-To: lng-odp@lists.linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id BB02F60F1E; Thu, 3 Nov 2016 00:43:50 +0000 (UTC) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by lists.linaro.org (Postfix) with ESMTPS id 092D260D56 for ; Thu, 3 Nov 2016 00:42:14 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id 62so50080301oif.1 for ; Wed, 02 Nov 2016 17:42:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wtqV4J/ZTmAP5HpW0Teuqy1cXodZuBfIXPMazLqeOrg=; b=G2UR/BXTXN029SJm3/cqP6CJj+YPx7nxIrwhGdBOdmlUWw10Z2gF9+8oYAJjdfiF94 w0olWu0TfN/8CQV+muInbCVUosygAm1DMO2PSd5vpM5cnrIJJQ5OOYHrW3AvhC7jdrCI u9Lvpc5P7k3OLO80b6VibEoh+N3aEDLziMjx3Y3fcOWQ9fYhsynE9WoJtSGzaHFBDNdh 0pfJMO48Z/voGmn770FgLg/BxbLsEESXpBQQlxdkMKn/kYRSaYuY1CYL5qic+t9K99JJ MKiPMgGPXj0MI1JuQb0Wo0PZ3omYDNd+YcZR1MhmxdK2n6dozIn+OO+OSBS5FCjybqSq 4VWQ== X-Gm-Message-State: ABUngvcQXo3Fi/SLIdlsk7YrI4xC7M1tX9NNKAQJc4/jE8BBpUlUPoKfw8oaU7YxfdZq83xISHE= X-Received: by 10.202.213.199 with SMTP id m190mr5704242oig.69.1478133733257; Wed, 02 Nov 2016 17:42:13 -0700 (PDT) Received: from localhost.localdomain (cpe-70-121-83-241.austin.res.rr.com. [70.121.83.241]) by smtp.gmail.com with ESMTPSA id p82sm1352229oia.25.2016.11.02.17.42.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Nov 2016 17:42:12 -0700 (PDT) From: Bill Fischofer To: lng-odp@lists.linaro.org Date: Wed, 2 Nov 2016 19:41:59 -0500 Message-Id: <1478133719-10981-7-git-send-email-bill.fischofer@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1478133719-10981-1-git-send-email-bill.fischofer@linaro.org> References: <1478133719-10981-1-git-send-email-bill.fischofer@linaro.org> MIME-Version: 1.0 X-Topics: crypto patch Subject: [lng-odp] [API-NEXT PATCHv4 7/7] doc: userguide: expand crypto documentation to cover random apis X-BeenThere: lng-odp@lists.linaro.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "The OpenDataPlane \(ODP\) List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lng-odp-bounces@lists.linaro.org Sender: "lng-odp" Clean up the crypto section of the User Guide and expand on the ODP random data APIs and the enhanced odp_crypto_capability() API. Signed-off-by: Bill Fischofer --- doc/users-guide/users-guide-crypto.adoc | 84 +++++++++++++++++++++++++-------- 1 file changed, 65 insertions(+), 19 deletions(-) -- 2.7.4 diff --git a/doc/users-guide/users-guide-crypto.adoc b/doc/users-guide/users-guide-crypto.adoc index 04b3e87..4d0c8f6 100644 --- a/doc/users-guide/users-guide-crypto.adoc +++ b/doc/users-guide/users-guide-crypto.adoc @@ -19,24 +19,26 @@ ODP supports synchronous and asynchronous crypto sessions. For asynchronous sessions, the output of crypto operation is posted in a queue defined as the completion queue in its session parameters. -ODP crypto APIs support chained operation sessions in which hashing and ciphering -both can be achieved using a single session and operation call. The order of -cipher and hashing can be controlled by the `auth_cipher_text` session parameter. +ODP crypto APIs support chained operation sessions in which hashing and +ciphering both can be achieved using a single session and operation call. The +order of cipher and hashing can be controlled by the `auth_cipher_text` +session parameter. Other Session parameters include algorithms, keys, initialization vector -(optional), encode or decode, output queue for async mode and output packet pool -for allocation of an output packet if required. +(optional), encode or decode, output queue for async mode and output packet +pool for allocation of an output packet if required. === Crypto operations After session creation, a cryptographic operation can be applied to a packet using the `odp_crypto_operation()` API. Applications may indicate a preference -for synchronous or asynchronous processing in the session's `pref_mode` parameter. -However crypto operations may complete synchronously even if an asynchronous -preference is indicated, and applications must examine the `posted` output -parameter from `odp_crypto_operation()` to determine whether the operation has -completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is expected. In the case -of an async operation, the `posted` output parameter will be set to true. +for synchronous or asynchronous processing in the session's `pref_mode` +parameter. However crypto operations may complete synchronously even if an +asynchronous preference is indicated, and applications must examine the +`posted` output parameter from `odp_crypto_operation()` to determine whether +the operation has completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is +expected. In the case of an async operation, the `posted` output parameter +will be set to true. The operation arguments specify for each packet the areas that are to be @@ -49,9 +51,9 @@ In case of out-of-place mode output packet is different from input packet as specified by the application, while in new buffer mode implementation allocates a new output buffer from the session’s output pool. -The application can also specify a context associated with a given operation that -will be retained during async operation and can be retrieved via the completion -event. +The application can also specify a context associated with a given operation +that will be retained during async operation and can be retrieved via the +completion event. Results of an asynchronous session will be posted as completion events to the session’s completion queue, which can be accessed directly or via the ODP @@ -60,12 +62,56 @@ result. The application has the responsibility to free the completion event. === Random number Generation -ODP provides an API `odp_random_data()` to generate random data bytes. It has -an argument to specify whether to use system entropy source for random number -generation or not. +ODP provides two APIs to generate various kinds of random data bytes. Random +data is characterized by _kind_, which specifies the "quality" of the +randomness required. ODP support three kinds of random data: + +ODP_RANDOM_BASIC:: No specific requirement other than the data appear to be +uniformly distriuted. Suitable for load-balancing or other non-cryptographic +use. + +ODP_RANDOM_CRYPTO:: Data suitable for cryptographic use. This is a more +stringent requirement that the data pass tests for statistical randomness. + +ODP_RANDOM_TRUE:: Data generated from a hardware entropy source rather than +any software generated pseudo-random data. May not be available on all +platforms. + +The main API for accessing random data is: + +[source,c] +----- +int odp_random_data(uint8_t buf, uint32_t len, odp_random_kind_t kind); +----- + +The expectation is that lesser-quality random is easier and faster to generate +while higher-quality random may take more time. Implementations are always free +to susbstitute a higher kind of random than the one requested if they are able +to do so more efficiently, however calls must return a failure indicator +(rc < 0) if a higher kind of data is requested than the implementation can +provide. This is most likely the case for ODP_RANDOM_TRUE since not all +platforms have access to a true hardware random number generator. + +For testing purposes it is often desirable to generate repeatable sequences +of "random" data. To address this need ODP provides the additional API: + +[source,c] +----- +int odp_random_seeded_data(uint8_t buf, uint32_t len, odp_random_kind_t kind, + uint32_t *seed); +----- + +This operates the same as `odp_random_data()` except that an additional `seed` +parameter is provide that specifies a seed value to use in generating the data. +This value is updated on each call, so repeated calls with the same variable +will generate a sequence of random data starting from the initial specified +seed. If another sequence of calls is made starting with the same initial seed +value, then `odp_random_seeded_data()` will return the same sequence of data +bytes. === Capability inquiries -ODP provides an API interface `odp_crypto_capability()` to inquire implementation’s +ODP provides the API `odp_crypto_capability()` to inquire the implementation’s crypto capabilities. This interface returns a bitmask for supported algorithms -and hardware backed algorithms. +and hardware backed algorithms, as well as the maximum kind of random +supported.