Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Horia Geanta <horia.geanta@nxp.com>
To:     Eric Biggers <ebiggers@kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH 6/8] crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN
Thread-Topic: [PATCH 6/8] crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN
Thread-Index: AQHVv4qNwU5qG3JMY0aYyVWztfKm3A==
Date:   Mon, 6 Jan 2020 15:00:12 +0000
Message-ID: <VI1PR0402MB348509941C8A211DBEBE6111983C0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
References: <20191231031938.241705-1-ebiggers@kernel.org>
 <20191231031938.241705-7-ebiggers@kernel.org>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ffbcf84-be04-4294-d735-08d792b921c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 15:00:12.8216
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0wDGQRnr3zHOzREYuXPOjRR2SPdCMJCIOVuXZNLfNGhYwlaUca49EBPR550n5TzqmSCP4GgL82EmkHDtY5IvrQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB3424
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On 12/31/2019 5:29 AM, Eric Biggers wrote:=0A=
> From: Eric Biggers <ebiggers@google.com>=0A=
> =0A=
> The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to=0A=
> make the ->setkey() functions provide more information about errors.=0A=
> =0A=
> However, no one actually checks for this flag, which makes it pointless.=
=0A=
> =0A=
> Also, many algorithms fail to set this flag when given a bad length key.=
=0A=
> Reviewing just the generic implementations, this is the case for=0A=
> aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309,=
=0A=
> rfc7539, rfc7539esp, salsa20, seqiv, and xcbc.  But there are probably=0A=
> many more in arch/*/crypto/ and drivers/crypto/.=0A=
> =0A=
> Some algorithms can even set this flag when the key is the correct=0A=
> length.  For example, authenc and authencesn set it when the key payload=
=0A=
> is malformed in any way (not just a bad length), the atmel-sha and ccree=
=0A=
> drivers can set it if a memory allocation fails, and the chelsio driver=
=0A=
> sets it for bad auth tag lengths, not just bad key lengths.=0A=
> =0A=
> So even if someone actually wanted to start checking this flag (which=0A=
> seems unlikely, since it's been unused for a long time), there would be=
=0A=
> a lot of work needed to get it working correctly.  But it would probably=
=0A=
> be much better to go back to the drawing board and just define different=
=0A=
> return values, like -EINVAL if the key is invalid for the algorithm vs.=
=0A=
> -EKEYREJECTED if the key was rejected by a policy like "no weak keys".=0A=
> That would be much simpler, less error-prone, and easier to test.=0A=
> =0A=
> So just remove this flag.=0A=
> =0A=
> Signed-off-by: Eric Biggers <ebiggers@google.com>=0A=
Reviewed-by: Horia Geant=E3 <horia.geanta@nxp.com>=0A=
=0A=
for caam and talitos drivers.=0A=
=0A=
Thanks,=0A=
Horia=0A=