Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220729165954.991-1-ignat@cloudflare.com> <Yv9dvvy0rK/1T0sU@gondor.apana.org.au>
 <CALrw=nEh7LX3DSCa3FTu8BYr4QWx+W2h3Jei9Qo67+XXH-Vegw@mail.gmail.com> <Yw3Rneo6Ik1QEfbG@gondor.apana.org.au>
In-Reply-To: <Yw3Rneo6Ik1QEfbG@gondor.apana.org.au>
From:   Ignat Korchagin <ignat@cloudflare.com>
Date:   Tue, 30 Aug 2022 11:48:23 +0100
Message-ID: <CALrw=nGJgMACrFVy+FVVCDb4H3wNUN2E-GLZaXzLsm3ReOUeVg@mail.gmail.com>
Subject: Re: [PATCH] crypto: akcipher - default implementations for setting
 private/public keys
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     "David S . Miller" <davem@davemloft.net>,
        linux-crypto <linux-crypto@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        kernel-team <kernel-team@cloudflare.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Aug 30, 2022 at 10:00 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Mon, Aug 29, 2022 at 11:48:23AM +0100, Ignat Korchagin wrote:
> >
> > I can only elaborate here as I didn't encounter any real-world
> > use-cases, but may assume some limited crypto hardware device, which
> > may somehow "encourage" doing public key operations in software and
> > providing only "private-key" operations due to its limited resources.
>
> In general if a hardware is missing a piece of the functinoality
> required by the API then it should implement a software fallback.
>
> The only time such a NULL helper would make sense if an algorithm
> had no public key.

I vaguely remember some initial research in quantum-resistant
signatures, which used HMAC for "signing" thus don't have any public
keys. But it is way beyond my expertise to comment on the practicality
and availability of such schemes.

I'm more concerned here about a buggy "third-party" RSA driver, which
may not implement the callback and which gets prioritised by the
framework, thus giving the ability to trigger a NULL-ptr dereference
from userspace via keyctl(2). I think the Crypto API framework should
be a bit more robust to handle such a case, but I also understand that
there are a lot of "if"s in this scenario and we can say it is up to
crypto driver not to be buggy. Therefore, consider my opinion as not
strong and I can post a v2, which does not provide a default stub for
set_pub_key, if you prefer.

Ignat