Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: f0wMwpFiyLGs/1f6T3oB59Ylz7ckoOPz6f1zhY1h98ZXICDjeYpxRZ4LmNcJoXq2YPigx0FRn3
 XD20cT22bMRA==
IronPort-SDR: BQL9JcsWXMeCYIF4OOE6YtIUf/9eZn9LkOgt3rCihTPCOVYyOhMQXjsv0zmkGUkR7qica5y0ix
 ygG9205LNWsA==
From:   "Reshetova, Elena" <elena.reshetova@intel.com>
To:     Daniele Alessandrelli <daniele.alessandrelli@linux.intel.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>
CC:     "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        "Alessandrelli, Daniele" <daniele.alessandrelli@intel.com>,
        Mark Gross <mgross@linux.intel.com>,
        "Khurana, Prabhjot" <prabhjot.khurana@intel.com>
Subject: RE: [RFC PATCH 0/6] Keem Bay OCS ECC crypto driver
Thread-Topic: [RFC PATCH 0/6] Keem Bay OCS ECC crypto driver
Thread-Index: AQHW1JkZ8lMRowq1QUyYZqNdBK9VvaoXNMxw
Date:   Mon, 4 Jan 2021 08:04:15 +0000
Message-ID: <CY4PR1101MB2326ED0E6C23D1D868D53365E7D20@CY4PR1101MB2326.namprd11.prod.outlook.com>
References: <20201217172101.381772-1-daniele.alessandrelli@linux.intel.com>
In-Reply-To: <20201217172101.381772-1-daniele.alessandrelli@linux.intel.com>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.5.1.3
dlp-product: dlpe-windows
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 51eff534-fa24-4b6b-4988-08d8b0875482
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 08:04:15.6483
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XSPcbf4CqIteC8SScgNdFudD181oDLOiMLTzEswR9pcZJxEcPlE5cBjJODyGeZ9BDpA2+ld6keIwK/tcIkcE3sLK7QhmLOVs1WAB809sct8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB0008
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

> 2. The OCS ECC HW does not support the NIST P-192 curve. We were planning=
 to
>    add SW fallback for P-192 in the driver, but the Intel Crypto team
>    (which, internally, has to approve any code involving cryptography)
>    advised against it, because they consider P-192 weak. As a result, the
>    driver is not passing crypto self-tests. Is there any possible solutio=
n
>    to this? Is it reasonable to change the self-tests to only test the
>    curves actually supported by the tested driver? (not fully sure how to=
 do
>    that).

An additional reason against the P-192 SW fallback is the fact that it can=
=20
potentially trigger unsafe behavior which is not even "visible" to the end =
user
of the ECC functionality. If I request (by my developer mistake) a P-192=20
weaker curve from ECC Keem Bay HW driver, it is much safer to return a
"not supported" error that proceed behind my back with a SW code
implementation making me believe that I am actually getting a HW-backed up
functionality (since I don't think there is a way for me to check that I am=
 using
SW fallback).=20

Best Regards,
Elena=20