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: Iaemv8UG8BFGgWhLkNoXf4+fU9OhutJSYBXSPHTb0KfjNIJt0N6ru8v7Uy6EVENl6DllN6kyl/
 Fdkh9EOnKmtA==
IronPort-SDR: jCnPvsNkg3N5g3ka/IS5Z0tuKrQSCYllz06thT7ZD/n3aM5LwACydveQYW7GuBEoekW1dQyD9Q
 073XIdARrgfg==
From:   "Reshetova, Elena" <elena.reshetova@intel.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>,
        "ardb@kernel.org" <ardb@kernel.org>
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
Thread-Topic: [RFC PATCH 0/6] Keem Bay OCS ECC crypto driver
Thread-Index: AQHW1JkZ8lMRowq1QUyYZqNdBK9VvaoXNMxwgAA8YgCAADFl8IAPZGXA
Date:   Thu, 14 Jan 2021 10:25:14 +0000
Message-ID: <CY4PR1101MB232696B49BA1A3441E8B335EE7A80@CY4PR1101MB2326.namprd11.prod.outlook.com>
References: <20201217172101.381772-1-daniele.alessandrelli@linux.intel.com>
 <CY4PR1101MB2326ED0E6C23D1D868D53365E7D20@CY4PR1101MB2326.namprd11.prod.outlook.com>
 <20210104113148.GA20575@gondor.apana.org.au>
 <CY4PR1101MB23260DF5A317CA05BBA3C2F9E7D20@CY4PR1101MB2326.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR1101MB23260DF5A317CA05BBA3C2F9E7D20@CY4PR1101MB2326.namprd11.prod.outlook.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: 9f3ce9dc-13bc-4fc9-7b93-08d8b876ae64
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2021 10:25:14.2218
 (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: 6nMnaX0MD9oHq1i95gm9AxHSuQRQ+xUj00ToVCbSZRqPhWsUA9VEiKvQA16zo5HPAjGrRT6XhjXwy0j2U1zU+NCscM4kdpu9a+GfQyUZp2o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2165
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

> > 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 pl=
anning
> to
> > > >    add SW fallback for P-192 in the driver, but the Intel Crypto te=
am
> > > >    (which, internally, has to approve any code involving cryptograp=
hy)
> > > >    advised against it, because they consider P-192 weak. As a resul=
t, the
> > > >    driver is not passing crypto self-tests. Is there any possible s=
olution
> > > >    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 i=
t can
> > > potentially trigger unsafe behavior which is not even "visible" to th=
e 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-back=
ed up
> > > functionality (since I don't think there is a way for me to check tha=
t I am using
> > > SW fallback).
> >
> > Sorry, but if you break the Crypto API requirement then your driver
> > isn't getting merged.
>=20
> But should not we think what behavior would make sense for good crypto dr=
ivers in
> future?
> As cryptography moves forward (especially for the post quantum era), we w=
ill have
> lengths for all existing algorithms increased (in addition to having a bu=
nch of new
> ones),
> and we surely should not expect the new generation of HW drivers to imple=
ment
> 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, be=
cause it
> cannot be part of API to begin with since it is always changing parameter=
 (algorithms
> and attacks
> develop all the time).

I would really appreciate, if someone helps us to understand here. Maybe th=
ere is a
correct way to address this, but we just don't see it. The question is not =
even about
this particular crypto driver and the fact whenever it gests merged or not,=
 but the
logic of the crypto API subsystem.=20

As far as I understand the implementations that are provided by the special=
ized drivers
(like our Keem Bay OCS ECC driver example here) have a higher priority vs. =
generic
Implementations that exists in kernel, which makes sense because we expect =
these drivers
(and the security HW they talk to) to provide both more efficient and more =
secure
implementations than a pure SW implementation in kernel can do (even if it =
utilizes special
instructions, like SIMD, AESNI, etc.). However, naturally these drivers are=
 bound by=20
what security HW can do, and if it does not support a certain size/param of=
 the algorithm
(P-192 curve in our case), it is pointless and wrong for them to reimplemen=
t what SW is
already doing in kernel, so they should not do so and currently they re-dir=
ect to core kernel=20
implementation. So far good.=20

But now comes my biggest worry is that this redirection as far
as I can see is *internal to driver itself*, i.e. it does a callback to the=
se core functions from the driver
code, which again, unless I misunderstand smth, leads to the fact that the =
end user gets
P-192 curve ECC implementation from the core kernel that has been "promoted=
" to a highest
priority (given that ECC KeemBay driver for example got priority 300 to beg=
in with). So, if
we say we have another HW Driver 'Foo', which happens to implement P-192 cu=
rves more securely,
but happens to have a lower priority than ECC KeemBay driver, its implement=
ation would never
be chosen, but core kernel implementation will be used (via SW fallback int=
ernal to ECC Keem
Bay driver). =20

Another problem is that for a user of crypto API I don't see a way (and per=
haps I am wrong here)
to guarantee that all my calls to perform crypto operations will end up bei=
ng performed on a=20
security HW I want (maybe because this is the only thing I trust). It seems=
 to be possible in theory,
but in practice would require careful evaluation of a kernel setup and a sy=
nc between what=20
end user requests and what driver can provide. Let me try to explain a pote=
ntial scenario.=20
Lets say we had an end user that used to ask for both P-192 and P-384 curve=
-based ECC operations
and let's say we had a driver and security HW that implemented it. The end =
user made sure that
this driver implementation is always preferred vs. other existing implement=
ations. Now, time moves, a new=20
security HW comes instead that only supports P-384, and the driver now has =
been updated to
support P-192 via the SW fallback (like we are asked now).=20
Now, how does an end user notice that when it asks for a P-192 based operat=
ions, his operations
are not done in security HW anymore? The only way seems to be
is to know that driver and security HW has been updated, algorithms and siz=
es changed, etc.=20
It might take a while before the end user realizes this and for example sto=
ps using P-192 altogether,
but what if this silent redirect by the driver actually breaks some securit=
y assumptions (side-channel
resistance being one potential example) made by this end user? The conseque=
nces can be very bad.=20
You might say: "this is the end user problem to verify this", but shouldn't=
 we do smth to prevent or
at least indicate such potential issues to them?

Best Regards,
Elena.