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: A9c2mIycfKXDDuefbfshRH/Maa52vH4cr6yx9VnvaM/q9F4fW4J1qnMedQ6k/Vfr6zZ5Ty3mj2
 9sGo6UuiwC5A==
IronPort-SDR: j8VPIfLP3oKZ/eXDnN+v+BuK3KtONSBYnZnfm+9UoXod+nazx5O8NT1CcIeaahm9IpGe9ZZG/c
 zN9iytjfgnpg==
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
Thread-Topic: [RFC PATCH 0/6] Keem Bay OCS ECC crypto driver
Thread-Index: AQHW1JkZ8lMRowq1QUyYZqNdBK9VvaoXNMxwgAA8YgCAADFl8A==
Date:   Mon, 4 Jan 2021 14:40:43 +0000
Message-ID: <CY4PR1101MB23260DF5A317CA05BBA3C2F9E7D20@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>
In-Reply-To: <20210104113148.GA20575@gondor.apana.org.au>
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: 72a044f1-7a59-47e9-5ad9-08d8b0beb705
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 14:40:43.2911
 (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: s8fZf2WCZEMrdDmlPP+di44CGiThBIFC79rs376jVyszusDHgqRbwQWZ3i1O22iCrzypzPCjtJv9Fg5R7jtVKDCXciI7c6pDwf/oWvHYE0s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB0054
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 plan=
ning 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 sol=
ution
> > >    to this? Is it reasonable to change the self-tests to only test th=
e
> > >    curves actually supported by the tested driver? (not fully sure ho=
w 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-19=
2
> > 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
> 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 driv=
ers in future?
As cryptography moves forward (especially for the post quantum era), we wil=
l have
lengths for all existing algorithms increased (in addition to having a bunc=
h of new ones),=20
and we surely should not expect the new generation of HW drivers to impleme=
nt
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, beca=
use it
cannot be part of API to begin with since it is always changing parameter (=
algorithms and attacks
develop all the time).=20

Best Regards,
Elena.