RE: [RFC PATCH 0/6] Keem Bay OCS ECC crypto driver

From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Daniele Alessandrelli <daniele.alessandrelli@linux.intel.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"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
Date: Mon, 4 Jan 2021 14:40:43 +0000	[thread overview]
Message-ID: <CY4PR1101MB23260DF5A317CA05BBA3C2F9E7D20@CY4PR1101MB2326.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210104113148.GA20575@gondor.apana.org.au>

> On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote:
> > > 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 solution
> > >    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
> > 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
> > 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).
> 
> Sorry, but if you break the Crypto API requirement then your driver
> isn't getting merged.

But should not we think what behavior would make sense for good crypto drivers in future?
As cryptography moves forward (especially for the post quantum era), we will have
lengths for all existing algorithms increased (in addition to having a bunch of new ones), 
and we surely should not expect the new generation of HW drivers to implement
the old/weaker lengths, so why there the requirement to support them? It is not a
part of crypto API definition on what bit lengths should be supported, because it
cannot be part of API to begin with since it is always changing parameter (algorithms and attacks
develop all the time). 

Best Regards,
Elena.